-
Suggestion
-
Resolution: Unresolved
-
95
-
Problem Definition
Currently, the SAML integration available for Atlassian Access only syncs the users' first name and last name into Atlassian's side.
Since the user can configure other attributes at id.atlassian like Job title, Department and Organization it would be nice if those could be passed through SAML.
Most IdP can pass those at the SAML response but with the current implementation, they are just ignored.
Suggested Solution
Enhance the attributes mapping for Atlassian Access SAML integration so more attributes can be passed/synced from the IdP into Atlassian.
Workaround
The Atlassian Access user-provisioning does sync those attributes so it can be used as a workaround.
[ACCESS-638] Support more attributes on SAML integration.
We would greatly benefit from being able to use the Group Membership attribute.
This Kind of Attributes we would like to use:
- phoneNumber;
- extensionAttributes1-9
- Office
- Team
Department - Group Membership
This would let us more flexibility in controling ticket flow based on the team the customer is for example.
Please add "Based in" for mapping with Azure AD / SCIM provisioning.
Hi, does anyone know if Scenario #2 in Dave's comment above has been addressed?
Further to this, after discussion with support under PCS-75020, we are adding our feedback. There are two scenarios we try and cover with our service-providers
- Identification of users should be based on an immutable value (such as objectGUID in an ActiveDirectory environment).If the e-mail address of an account in the IdP changes, the immutable ID remains the same. The next time the user authenticates via SSO the application identifies that it’s the same user and transparently updates the details if holds for the account. This helps reduce administrative effort and prevent SSO-enabled applications breaking when someone gets married/divorced etc.
- If a user leaves the company, their account in the iDP is deleted. If after some time a new account is created in the iDP with the same e-mail address, but different immutable identifier. Where a user attempts to authenticate and and the immutable identifier isn't a match, access should not be granted;
Scenario #1 works fine, providing upn is set correctly.
Scenario #2 does not. If the authentication flow can't be addressed, a mitigation might be:
- If a user logs in with a different immutable ID but the same e-mail as another user, the later user to authenticate should be treated as the active user and the old one disabled;
- Expose the ImmutableID in some API, so that we can periodically query and de-provision users where the ImmutableID doesn't match internally.
+1 would be nice to be able to have the Atlassian organization attribute coming in from saml for our external customers ( which are Entra / azure ad guests)