Unable to login to integrator app using third party identity provider

I created a new integrator org https://integrator-2672173.okta.com/ and set up third party IdP as login provider.

I added third party IdP under “Security → Identity Providers” and also configured a “routing rule” to redirect user login to my IdP.

When a tries to login and provides email, Okta successfully redirects user to the IdP. User logs in at IdP and is redirected back to Okta with saml assertion. Assertion is verified by Okta. Assertion contains firstName/LastName/email in addition to NameID.

After login, user sees below error:

Looking at developer tools, I believe this is related to MFA configuration. Here is the text in developer tools:

“intent”: “LOGIN”,
“messages”: {
“type”: “array”,
“value”: [
{
“message”: “Unable to sign in. Contact support for assistance.”,
“i18n”: {
“key”: “api.policy.okta.account.management.insufficient.authenticators.unable.to.sign.in”
},
“class”: “ERROR”
}
]
},

I tried disabling MFA for 3rd party users since IdP already enforces MFA. But, my attempts are not successful.

I am using latest Okta identity engine. Legacy engine had MFA rule that could be disabled for certain users and that used to work. In the latest identity engine, I’m unable to do so.

I tried tweaking “Security → Authentication Policies → App Sign-In policies” in vain.

You are on the right track. The issue is that the user has just been created in JIT and they are not enrolled in any authenticators. This has to be a requirement in the global session policy or authentication policy for the app you are trying to log into.

The GSP and AP work together in parallel. GSPs are assigned by group, so make sure the GSP for the user does not require MFA (there is a checkbox). Unless you configure the IdP JIT to assign the user to a group on creation, that will be the default GSP. Your AP rule is good, but make sure the AP you are looking at is the one linked to the app the user is logging into?

And one last way around that: if you want you can set up an MFA enrollment policy for the group if you assigned it, or look to the default enrollment policy. If you allow the user to enroll in required MFAs when they are created that will happen before the MFA requirement kicks in and they will be OK.

One last thought: SAML and OIDC have no mechanism to indicate if the IdP did MFA. And could we trust the IdP even if it said it did? So MFA requirements are configured and met on the Okta side of the authentication so we can ensure it is correct before the user is authorized to get to an application.

Unfortunately some more attempts didn’t resolve the issue either. I adjusted IDP settings, GSP and AP.

Btw, I’m logging into the dashboard - https://integrator-2672173.okta.com/. I’m assuming this is the dashboard app.

Here are more details:

  1. Identity Providers Settings:

A. Account link policy: Enable automatic linking is selected

B. If no match is found: I tried both “Create new user (JIT)” and “Redirect to Okta sign-in page“. For the former, I configured “Group Assignments” to “specific group” called “OIN-Managers”. User is part of that group.

C. IDP usage is set to “SSO Only”

D. “Match Against” is set to “Email”

  1. Global session Policy

Disabled MFA in global session policy. Tried this with/without JIT mentioned above in IDP settings.

This is a new with higher priority than the default rule:

  1. Authentication Policies

Modified the default policy as below:

This is bound to “Okta Dashboard” app.

Btw, I already have MFA Enrollment policy. That did not kick-in for 3P users. Here’s the policy:

Interestingly, MFA enrollment kicked-in for a non-3P user (based on routing rule).

Good stuff. The GSP looks OK to me. If the rule linkage is correct the LoginRule looks good to me. Note that the dashboard is usually by itself in the “Okta Dashboard” policy. Did you change it? The reason is that the default policy is where new app integrations land, and those rules may be different than the requirements the org has for the user dashboard.

The enrollment policy is forcing enrollment for all users. So there is a potential issue there because sometimes JIT doesn’t get the user into the group before the policy is evaluated, requiring a double login to trigger MFA. But you say enrollment is not triggered. So let’s do two things:

  1. Check the system log after attempting the login and get all the messages related to the attempt. That will tell us what is really happening. If you filter them by the user you can export them to a CSV if you want.
  2. Let’s look closer at the IdP configuration and the routing rules, maybe something is going on there. But the most obvious one you say is turned on: automatic linking.

I tried modifying the “default” policy and “Okta Dashboard” policy in AP section. I tried again modifying just the “Okta Dashboard” policy. No luck.

Looking at logs, it feels like this is related to GSP.

Error seems to start from GSP.

But the policy seems to be okay.

Btw, I locked myself (admin) out while playing around with stuff. I was troubleshooting by disabling MFA enrollment. This disabled previously configured Okta-Verify and Google-Authenticators. I see below error

Can you please help reset this so that I can login?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.