When you want to configure MFA on oracle Cloud Infrastructure (OCI), using ICDS, there is a good starting point in the OCI documentation. This document contains a warning (prerequisite number 5), but could have been a little more emphasized:
"If you don’t register this client application and a Sign-On Policy configuration restricts access to everyone, then all users are locked out of the identity domain until you contact Oracle Support."
I recently had myself locked out of OCI and IDCS (and everyone else along with me), and this prerequisite step helped me through it. There were two challenges, though. The document does not tell you how to actually solve the problem of locking yourself out and it doesn't really explain why I locked myself out in the first place. Here, I will focus on the first part: how to solve the problem once you locked yourself out. It is nice to have this Emergency Access, but how do you use it?
Please note: if you skipped "prerequisite 5" (and did not create an OAuth2 application), this blog does not in fact really help. You will probably need Oracle Support in that case...
Prerequisite - Register a Client Application
So, very important step. Can't repeat it enough: if you want to enable MFA on IDCS, make sure this prerequisite is met. As mentioned in the documentation, use this link to Oracle by Example to set up your Emergency Access application. That's what I call it, as that is what it is for me. Should you lock yourself (and everyone else) out of OCI/IDCS, use this setup to get back in.
The Oracle by Example instructions are pretty clear on how to configure and use Postman. Due to some newer versions, some instructions may be a bit outdated, but all in all it works pretty well. Step 1 is done in IDCS and works as described, that is where you configure the Emergency Access application. Note the client ID and secret and store them in a safe location.
Step 2 and 3 are about getting Postman configured with a (full) Environment and Collection to work with IDCS. Step 4 is all about getting an actual OAuth2 token. Very important, make sure that that part works. In my version of Postman config, I needed to use "On the Collections tab, expand OAuth, then Tokens and select Obtain access_token (client credentials)" and then press "Send" to get the actual token.
Even more important: make sure that with this token, you can access your IDCS environment. I like to do that with "On the Collections tab, expand Users, then Search and select List all users" and after pressing "Send", you should see all your users as a result. If not: don't proceed, but troubleshoot first! Make sure you have the access working, as this might be your last resort at some point.
How does this save you?
Now we know we can access IDCS, even if our MFA policy would happen to shut us out with the message: "Sign-on policy denies access". If that happens, the steps to solve this are quite easy if you know what to do. First of all: I assume you will have created a separate policy in IDCS for this, and not re-use the default one. As a matter of fact: I highly recommend not messing with the default one.
Even if you are locked out, you can retrieve the list of policies in IDCS with Postman. The value for this policy can be obtained from "Collections tab, expand Policies, then Search and select List all policies". All policies have an id. Find the one for your MFA policy and either note it down somewhere, or better yet: store it in a new custom variable in your Postman Environment. I used "MFA_Policy_id" for this.
With the Policy ID, you can go to "On the Collections tab, expand Policies, then Policy, Modify and choose to duplicate Patch Update a Policy". Rename the duplicate to (for example) "Disable MFA Policy".
Replace the "{{id}}" in the URI with "{{MFA_Policy_id}}" (or just paste the id itself, if you didn't create a variable).
In the body of this new entry, paste:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "active",
"value": false }
]
}
Executing this request disables your new policy (literally setting "active" to "false"), allowing you to log in once again. That is why I leave the default policy as it is. It will now be the only one in effect and allows access to verified users.
Now, reconfigure the MFA policy, enable it again and see if it works this time. If not: disable the policy and try again. And remember: as long as you stay signed in to IDCS, you can disable the policy from the console as long as your connections stays valid. And should you get locked out (again), you will always have a plan B!
