Start a new topic
Answered

Issue with Azure AD configuration in Semarchy 5.3.13

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
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 : 
_claim_names={"groups":"src1"} 
_claim_sources={"src1":{"endpoint":"https:\\/\\/graph.windows.net\\/5xxxxd-fe83df4f9e4d\\/users\\/a41470xxx-09d6addc5091\\/getMemberObjects"}}

Here is Azure doc for your reference:
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

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 : 
_claim_names={"groups":"src1"} 
_claim_sources={"src1":{"endpoint":"https:\\/\\/graph.windows.net\\/5xxxxd-fe83df4f9e4d\\/users\\/a41470xxx-09d6addc5091\\/getMemberObjects"}}

Here is Azure doc for your reference:
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.
Login to post a comment