As with all significant platform changes we recommend that you back up your database before implementing JIT User Provisioning. If you have questions or concerns reach out to us via [email protected].
DivvyCloud is pleased to include support for authentication server synchronizations, or a feature we're calling Just In Time User Provisioning (JIT). DivvyCloud JIT provides the capability to synchronize users and groups from an external Identity Provider (IDP) authentication server such as Okta, LDAP, Ping, and Microsoft's Active Directory. When an authentication server is configured in DivvyCloud, a scheduled sync job runs once an hour and updates can be applied at user login for SAML authentication servers.
This feature, combined with the group-based entitlement feature, enables DivvyCloud Admins to manage DivvyCloud user access from their identity provider without the need to make additional updates for users in DivvyCloud.
DivvyCloud groups are mapped to corresponding groups from the authentication server. DivvyCloud synchronizes the memberships in its mapped groups to those on the authentication server.
- If a user in an authentication server group is not present in DivvyCloud, that user is created.
- If an existing SAML DivvyCloud user is no longer in any of the mapped groups in the authentication server, that user is deactivated in DivvyCloud (but can be reactivated if that user returns to a mapped group later).
- DivvyCloud’s mappings include authentication server groups to specify Domain Admin and Organization Admin users. An example of group mappings is shown below.
- Note: Domain Admin and Organization Admin users are not available under User groups as they are system generated and cannot be modified.
Editing Domain Admin Mappings
Only Domain Admins can edit Domain Admin group mappings.
Before getting started with DivvyCloud's authentication server support using JIT you should have the following:
- A functioning DivvyCloud platform
- Admin permissions for your authentication server
- Note: Only Domain Admins (in DivvyCloud) can edit Domain Admin group mappings
At present JIT is available for:
- SAML at user login, through assertions attributes (Any SAML provider)
- Scheduled updates for SAML with Okta. Refer to SAML - Just In-Time Provisioning
- Scheduled updates for LDAP (Any LDAP provider). Refer to LDAP or LDAP - Just In-Time User Provisioning
- Scheduled updates for Active Directory. Refer to Active Directory or Active Directory - Just In-Time User Provisioning
- Scheduled updates for Azure Active Directory. Refer to Azure Active Directory, Azure AD + SAML, or Azure Active Directory - Just In-Time Provisioning
Within this documentation for LDAP and SAML we use Okta configurations as an example. For specific details on Okta we recommend you refer to their documentation. For other providers, we recommend you refer to the provider's configuration documentation.
As always, if you have questions or issues or want details on implementation using something other than Okta we're here to help, reach out to [email protected].
You must be prepared to complete the setup of your entitlements. Attempting to create group mappings without completing this setup in DivvyCloud will create groups with users that have NO associated permissions.
- Take a look at our documentation around Permissions Entitlements if you still need to prepare these configurations.
- The warning shown below is included in our details steps for the various configuration methods to remind you of the potential issues around the creation of Group Mappings without entitlements.
Before you proceed with Group Mappings for external authentication you must have all of your desired entitlements configured.
If you create a group and enable group mapping BEFORE you establish entitlements the users within your groups will have nothing configured and will not be able to access anything.
Refer to our documentation on Permissions Entitlements for details.
In DivvyCloud, scheduled updates run once an hour. The authentication server gets lists of members of the mapped user groups, and DivvyCloud’s users and group associations are updated to match.
Note: A credential to the authentication server is required to perform the scheduled updates.
- For Okta, this is implemented using a read-only API key.
- For LDAP, DivvyCloud uses the credentials of a user with directory-read privileges.
Note if your issue or concern is not included here or you need assistance with this feature reach out to [email protected].
What happens if an existing DivvyCloud user is moved out of all mapped groups?
DivvyCloud users are marked inactive if they no longer have membership in any mapped groups. The user is reactivated if added to a mapped group later.
What happens if a new user is included in a mapped group in the authentication server?
DivvyCloud creates a user and places this user in the appropriate mapped group(s). Sync hourly job will create the User in next run. To manually sync, click the actions menu and select "Synchronize Users" by going to Authentication server setting in DivvyCloud.
What happens if a user is included in multiple mapped groups?
Admin groups are treated differently than basic user groups. A summary of how group mappings are handled is below.
- If a user is in a Domain Admin group, the user will not be placed in Organization Admin group or any basic user groups in DivvyCloud, regardless of membership in these groups on the authorization server
- Note that if a user is in both Organization and Domain Admin groups, the user will be a Domain Admin (only) in DivvyCloud
- Users who are not Domain Admins (e.g. an Org Admin) can be members of multiple basic user groups.
What happens if a user is not included in any mapped groups?
If a existing user is not mapped to any groups, they are marked as "disabled" within DivvyCloud. Disabled users will do not appear in typical administrative displays (e.g. under "Identity Management --> Users").
User names are unique, so if a disabled user attempts login:
- It won't work and;
- An administrator will not be able to recreate them with the same name
In this case, return to Okta to ensure they're properly configured (add them to the appropriate group) and their credentials will sync through the appropriate mapping (e.g. LDAP or SAML).
- You can force a sync by revisiting the Actions menu for the applicable server once any configuration issues have been resolved.
What are the pros and cons of scheduled sync and sync-at-login?
Note: this is only an option for SAML.
Scheduled sync and sync-at-login can be used independently or together, depending on your requirements and the availability of authentication server credentials.
Scheduled Sync Pros:
- Keeps DivvyCloud fully synced with the authentication server
- Including deactivation of users who no longer have access to DivvyCloud ( which is helpful for audit around account users that have left)
Scheduled Sync Cons
- Updates on the authentication server side can take up to an hour to propagate to DivvyCloud
- DivvyCloud admin has an option to initiate an on-demand sync.
- Requires the DivvyCloud admin to provide an authentication server credential for DivvyCloud to use when fetching updates from the authentication server
- Users see effects of authentication servers immediately when they log in
- Does not require authentication server credentials
- With some SAML providers, will not require any extra configs on SAML provider side
- Authentication server updates are not propagated to DivvyCloud unless a user logs in
- May require configuration for SAML provider to put required attributes in SAML assertions
What happens to existing DivvyCloud user login sessions if the sync changes user entitlements?
For scheduled synchronizations, all of a user’s sessions are terminated if:
- A user loses all access to DivvyCloud as a result of the update, or
- The user has a decrease in admin privileges
For sync-at-login, all existing user sessions are terminated if:
- Any changes are made to the user’s group memberships. Since the user is in the act of logging in, and will get the up-to-date permissions, the UX impact of removing other sessions for the user is minimal.
Updated 2 months ago