Issue with Azure AD configuration in Semarchy 5.3.13
S
Subham Dixit
started a topic
about 2 years ago
We recently upgraded our customer’s Semarchy environments from Semarchy 5.2 to 5.3.13. At the same time we moved from a virtual machine infrastructure to a container-based infrastructure.
After configuring the identity management OpenID Connect to use the customer’s Azure AD, we encountered a new issue. For most users (>90 %) everything works fine, but some users don’t receive all of their authentication roles from the AD provider to Semarchy. For those users we’ve had to maintain the roles manually, which is not ideal.
To us the issue seems random, or at least we haven’t discovered any pattern or root cause why some users can’t get their roles from the provider. We can see from the AD provider that the roles exist, they’re just not coming to Semarchy. Have you seen any such cases after moving to Semarchy 5.3 and would you have some ideas how to find the problem?
Best Answer
S
Subham Dixit
said
about 2 years ago
can you please follow the test Idp steps to send us the right panel results ?
It happens that, when a user has too many groups inside the provider configuration, this provider does not send the actual groups but a link to the groups, like that in the token :
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-active-directory-now-with-group-claims-and-application/ba-p/243862 “To ensure that the token size doesn't exceed HTTP header size limits, Azure AD limits the number of objectIds that it includes in the groups claim. If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), then Azure AD does not emit the groups claim in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Graph API to retrieve the user's group membership.”
We do not support that, but other customers facing this same issue could handle that by sending roles instead of groups on the provider side, and map those roles on our side instead of the groups.
1 Comment
S
Subham Dixit
said
about 2 years ago
Answer
can you please follow the test Idp steps to send us the right panel results ?
It happens that, when a user has too many groups inside the provider configuration, this provider does not send the actual groups but a link to the groups, like that in the token :
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-active-directory-now-with-group-claims-and-application/ba-p/243862 “To ensure that the token size doesn't exceed HTTP header size limits, Azure AD limits the number of objectIds that it includes in the groups claim. If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), then Azure AD does not emit the groups claim in the token. Instead, it includes an overage claim in the token that indicates to the application to query the Graph API to retrieve the user's group membership.”
We do not support that, but other customers facing this same issue could handle that by sending roles instead of groups on the provider side, and map those roles on our side instead of the groups.
Subham Dixit
Subham Dixit
-
Deployment History Date
-
Username in Tomcat Access Logs
-
Is It Possible to Perform Automatic Authentication with The User's Windows Account?
-
Where is the documentation for Version 5.2.5?
-
On Prem Semarchy Authentication using Azure AD?
-
Delete old models
-
Sync production model version with dev
-
Recreate a dev environment. Any side effect?
-
Indexes on xDM database tables
-
What logging technology is used in the Semarchy xDM platform?
See all 60 topics