Forum Discussion
How To Work Around The Azure SAML Group Claim Limitations?
We recently implemented a model in which our users can create Office 365 groups, which then can be used in all our SAML-connected third-party cloud applications to grant access to resources withing t...
So you are ADFS as the IDP for these clouds apps or Azure AD? Also have you investigated claims mapping.... I'm very rusty on it but I vaguely remember being able to use it to make Azure AD supply group names in the token...
Although I suspect app roles are the longer term approach
As Lavanya already said, names are only available for groups synced from on-premises AD. We are using Office 365 groups for permission management. We also use 365-group sync-back to have the Office 365 groups as universal security groups in our AD. Unfortunately that does not make them eligible for "groups synced from on-premises AD" for group names.
Status quo is that we are using ADFS. We add all security groups that start with "gpm__" to the SAML claim. In addition to not having names, such filtering is another thing that is not available in Azure AD.
Goal is to move to Azure AD.
The problem with roles is, that it requires static assignment on the Enterprise App level. And that is something we move away from. It makes no sense that someone manages roles who is not involved in the access management. And those people who manage access are project managers with no knowledge about Azure AD.
Besides, "These are human readable, no group IDs and token bloat" is wrong. The claim holds ids not readable names. The statement is wrong.
Status quo is that we are using ADFS. We add all security groups that start with "gpm__" to the SAML claim. In addition to not having names, such filtering is another thing that is not available in Azure AD.
Goal is to move to Azure AD.
The problem with roles is, that it requires static assignment on the Enterprise App level. And that is something we move away from. It makes no sense that someone manages roles who is not involved in the access management. And those people who manage access are project managers with no knowledge about Azure AD.
Besides, "These are human readable, no group IDs and token bloat" is wrong. The claim holds ids not readable names. The statement is wrong.