CODEWITHSUNDEEP
samljitprovisioningoneloginscim
Nathan Neulinger
Nathan Neulinger

Reputation: 261

OneLogin SCIM provisioning - proactive or on-demand?

Looking into capabilities of OneLogin provisioning with SCIM - would be a custom application for SCIM support wrapping around a third party app (JIRA/Confluence DC if it matters). The actual setup of provisioning looks like it will be straightforward, but I've been having a hard time finding any clarity on the behavior.

Does OneLogin perform the provisioning operation in advance - based on permission assignments of users to applications, or does it perform it on-demand/JIT at the time the user attempts to log into an application?

Use case is that I have an application with limited license seats, that I'd like to be "open to anyone in company". I'd like the licenses to only be handed out upon access, but without the user having to take any special action.

If the normal "provisioning" capability is all proactive - is there any way to set up any sort of on-demand mode?

Upvotes: 0

Views: 136

Answers (2)

Mayur Dighe
Mayur Dighe

Reputation: 419

I have been using OneLogin for 5-6 years now. SCIM Provisioning in OneLogin happens when the User is assigned to the app via a role or manually.

You can configure how data is passed to the application on the configuration page.

Upvotes: 0

Zollnerd
Zollnerd

Reputation: 912

I don't know anything about OneLogin specifically, but broadly speaking, provisioning between identity providers and applications happens proactively. Just-in-time provisioning at the time of sign-in is typically done by consuming data available in the SAML/OIDC tokens provided to the application at time of sign-in.

Besides complaining to the application vendor to introduce the concept of an unlicensed user, the other likely flow I can identify that would help here would be to have that JIT provisioning flow based on SSO usage, but then something in the identity provider would pick up that the user has accessed the application and include them in scope for SCIM provisioning from that point forward. That would potentially provide richer data beyond what could be included in the SSO token, and would also cover updates and deactivations/deletions even if the user did not(or could not) sign in again after the update was made.

Upvotes: 0

Related Questions