Allowing customer signup in Microsoft Entra ID and login to Jira and Confluence
- Steinar Line
- Mari Fuglem
The challenge
Our large enterprise customer wanted to offer their partner users to a self-service signup portal in Microsoft Entra, see: https://learn.microsoft.com/en-us/entra/external-id/self-service-sign-up-user-flow . After signup in Entra they wanted the partner user that had just now created in Entra ID to be able to log directly into Confluence and Jira.
Background
Our customer had earlier set up cloud user provisioning of users and their groups from Entra ID into Jira and Confluence as described here: https://kantega-sso.atlassian.net/wiki/x/OYEc.
SCIM was used since the number of users being synced from Entra ID was 100.000+. They chose not to usehttps://kantega-sso.atlassian.net/wiki/x/owEbwhich is primarily optimized for smaller groups (up to 10,000 users),
When SCIM is configured in Kantega SSO, users from Entra ID will be present inside Confluence and Jira as if they were local users:
All the users from SCIM will be synced into its own user directory, see:
SCIM operates by facilitating synchronization of changes to users, groups, and memberships from the identity provider—such as Entra ID, Okta, (or other SCIM-compliant systems) to all SCIM subscribers. Kantega SSO supports being a SCIM subscriber and will be able to receive SCIM events keeping a mirror of the users in the Identity Provider as a user directory in Confluence, Jira and Bitbucket.
See more about the SCIM standard here: https://scim.cloud/ .
The problem
The customer encountered a significant challenge when using SCIM with Entra ID, specifically related to the synchronization delay for newly created users. There could be a delay of up to 40 minutes before a newly registered user’s account was propagated to Confluence and Jira. As a result, when the newly signed-up partner users attempted to access Confluence or Jira immediately after registration, their accounts were not yet available, causing frustration and access issues.
The solution
The issue was resolved using a feature in Kantega SSO known as Just-in-Time (JiT) provisioning. This functionality allows user accounts to be created on-the-fly during the login process whenever they are needed. Previously, the customer had configured login access from Entra ID to Confluence and Jira utilizing OIDC (OpenID Connect) technology.
Both OIDC and the alternative login standards supported by Kantega SSO facilitate JiT provisioning.
To get a clean architecture of where users were created when using JiT the customer enabled “Link users upon created” for their SCIM directory, see:
This allows the SCIM user directory to be used as a place to save JiT users.
Then in the JiT setup of their OIDC login configuration they selected the SCIM directory, see:
This gave the behavior that whenever a user came through the OIDC-based login from Entra ID and was not found in Confluence or Jira an account was created for them. To give them application access they had configured giving confluence-users and jira-software-users by default when logging in configured in Group memberships page.
And then after on the most 40 minutes the SCIM sync would sync the new user from Entra ID with the same username as the user previously created via JiT. Kantega SSO will then combine these two user accounts into one.
This again would prepare for clean user management. When the user some time later is disabled in Entra ID it would also be disabled in the SCIM directory in Confluence and Jira even though the user previously was created using JiT. And if you gave the user some groups in Entra ID these groups would also be given to the user account in the SCIM directory in Confluence and Jira.