KetanS.89652 (Customer) asked a question.
Please refer to this question, https://support.okta.com/help/s/question/0D51Y00009mSKhiSAG/disable-mfa-on-okta-org-1-when-authenticating-from-okta-org-2?language=en_US
In case of Org2Org, MFA happens twice on both Okta side (IDP and SP). To suppress MFA on one of Okta org, there is only one way - Write MFA policy based of the group to don't prompt MFA.
Issue? Okta has two login pages. One at <company>.okta.com and another <company>.okta.com/signin/.
The look of these 2 pages are same but /signin/ page does not route users through IDP flow. Meaning, Users can directly login to SP Okta org (and It won't redirect users to IDP Okta org). And guess what, MFA was suppressed so it leaves users on one factor (password only)
Has anyone tested or faced this?
If you do "View Source" on both Okta login pages, you will see the difference.
/signin/ page does not have the following piece of code (that <company>.okta.com page has)
idpDiscovery = true;
if (stateTokenAllFlows && stateToken) {
idpDiscoveryRequestContext = stateToken;
} else {
idpDiscoveryRequestContext = fromUri; }
Hi and Thank you for reaching out to the Okta Community!
While I understand your use-case and the desire to improve the end-user's experience (i.e. no double MFA prompts) , in the case of an ORG2ORG implementation we're dealing with two distinct tenants, each with their own security policies.
So in essence, the end-user's comfort will have to be sacrificed for the sake of security.
As for the "/signin/" endpoint, that is there to allow an alternative login in case of DSSO or IDP routing failures (misconfiguration/outages).
Hope this helps!
Thanks Mihai. So let me understand in terms of our use case.
We have business Partner who uses Okta too. We want our partners to manage their user's authentication. That's why we chose Org2Org so that we don't manage their password and MFA on our side.
But you are saying that Org2Org is meant to prompt twice. IDP and SP both would have to manage MFA? In that case, why would someone use Org2Org and not provision partners users directly in Org (at least they will manage MFA only once).
If authentication is delegated to third party, why would Okta trigger its own authentication policy checks?
Thanks
Ketan
This depends of the use-cases and requirements, but the ORG2ORG implementation would be leveraged for the Provisioning functions and the convenience of a centralized resource management.
As for why Okta would trigger it's own authentication policy, this is by design. Some customers integrate Okta for the explicit purpose of leveraging the MFA options.
This type of implementation is not uncommon. If I'm not mistaking, Microsoft does this as well with their Conditional Access - for example, you have the Office 365 domain federated with Okta where all respective sign on policies would apply, if not disabled - the end-user would also have to pass through the Azure policies.
Depending on your specific requirements, you might want to consider App Level policy configuration. For example:
This would allow the users access to the Okta Dashboard without being prompted by MFA again and if they need to access a particularly sensitive resource/app, that would be the one triggering an additional layer of MFA.
More info about App level policies can be found here:
https://help.okta.com/en/prod/Content/Topics/Security/policies/about-app-signon-policies.htm
https://help.okta.com/en/prod/Content/Topics/Security/policies/configure-app-signon-policies.htm
https://help.okta.com/en/prod/Content/Topics/Security/MFA_App_Level.htm
Hope this clarifies things!