Federating the identity & access management with 3rd party IdP (race condition issue)

[tobiwunder]

Hi all,

I’ve been working on implementing identity & access management for a subset of our users using Okta IdP federation with JIT, and overall I’m finding it to be a very attractive and lean approach.

I’ve been testing the group sync feature where group memberships from the 3rd party IdP are pushed into the service provider tenant, my Okta tenant in this case, during login. I was glad to see that the group memberships appear to be fully processed before the app sign-in attempt is made.

However, I did notice one minor issue: in some edge cases, the app assignment (which is based on the user’s group membership) seems to complete just after the login attempt, resulting in a temporary unauthorized error. Most of the time everything works seamlessly, but I’ve hit a few cases where the app assignment happens a split second too late.

I’m curious, has anyone else seen this behavior? Is this just a known race condition due to background processing in Okta, or is there a best practice to eliminate the risk entirely?

One improvement we’re considering is to combine SCIM provisioning from the external IdP with federation, but as far as I know, Okta’s Inbound SCIM connector isn’t expected until later this year.

Would love to hear how others have handled this or worked around it.

Thanks!

[tobiwunder]

I will reply to myself:

Just had a good call with an Okta support engineer and he mentioned the “Identity Broker” mode that can be enabled on client application level. It eliminates the need for application assignments completely and the validity of a login attempt needs to be verified through the application sign on policy. Inside the application sign on policy it is possible to check for the presence of group memberships. I will play around with it, but it seems promising.