How To Work Around The Azure SAML Group Claim Limitations?

%3CLINGO-SUB%20id%3D%22lingo-sub-1778199%22%20slang%3D%22en-US%22%3EHow%20To%20Work%20Around%20The%20Azure%20SAML%20Group%20Claim%20Limitations%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1778199%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20recently%20implemented%20a%20model%20in%20which%20our%20users%20can%20create%20Office%20365%20groups%2C%20which%20then%20can%20be%20used%20in%20all%20our%20%3CSTRONG%3ESAML-connected%3C%2FSTRONG%3E%20third-party%20cloud%20applications%20to%20grant%20access%20to%20resources%20withing%20the%20cloud%20app.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20way%20this%20works%20is%20that%20is%20this%3A%3C%2FP%3E%3CUL%3E%3CLI%3EThe%20Office%20365%20groups%20are%20synced%20back%20to%20our%20on-premises%20AD.%3C%2FLI%3E%3CLI%3EThe%20Office%20365%20groups%20must%20have%20the%20prefix%20365sec_%20in%20their%20CN%20and%20SamAccountName.%3C%2FLI%3E%3CLI%3EThe%20cloud%20application%20must%20support%20group%20membership%20claims%20and%20the%20groups%20must%20be%20created%20in%20the%20app%20with%20the%20same%20name.%3C%2FLI%3E%3CLI%3EWhen%20the%20user%20authenticates%2C%20ADFS%20adds%20all%20groups%20to%20the%20token%2C%20that%20have%20the%20prefix%20%22365sec_%22%20and%20the%20user%20is%20a%20member%20of.%3C%2FLI%3E%3CLI%3EThe%20user%20is%20now%20able%20to%20access%20all%20resources%20within%20the%20cloud%20app%20that%20grant%20him%20access%20based%20on%20group%20name%20and%20membership.%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAs%20an%20example%2C%20a%20SAML%20token%20for%20user%20Jon%20Doe%20would%20look%20like%20this%3A%3C%2FP%3E%3CUL%3E%3CLI%3E%3CSTRONG%3EName-ID%3C%2FSTRONG%3E%3A%20%3CA%20href%3D%22mailto%3Ajon.doe%40exmaple.com%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ejon.doe%40exmaple.com%3C%2FA%3E%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EE-Mail%3C%2FSTRONG%3E%3A%20%3CA%20href%3D%22mailto%3Ajon.doe%40exmaple.com%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ejon.doe%40exmaple.com%3C%2FA%3E%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EGivenName%3C%2FSTRONG%3E%3A%20Jon%3C%2FLI%3E%3CLI%3E%3CSTRONG%3ESurname%3C%2FSTRONG%3E%3A%20Doe%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EGroups%3C%2FSTRONG%3E%3A%20365sec_Account-SeeShell%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EGroups%3C%2FSTRONG%3E%3A%20365sec_Account-Wayland%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EGroups%3C%2FSTRONG%3E%3A%20365sec_Project-Samson%3C%2FLI%3E%3CLI%3E%3CSTRONG%3EGroups%3C%2FSTRONG%3E%3A%20365sec_Project-VisION%3C%2FLI%3E%3C%2FUL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20planned%20to%20move%20to%20Azure%20SAML%2C%20but%20I%20learned%20that%20Azure%20does%20not%20support%20adding%20the%20group%20CN%20or%20SamAccountName%20to%20the%20token%2C%20but%20only%20the%20objectId.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAll%20of%20our%20cloud%20apps%20only%20support%20adding%20groups%20by%20Name.%20This%20seems%20to%20be%20the%20de-facto%20standard.%20It%20is%20not%20possible%20in%20the%20cloud%20apps%20to%20create%20groups%20with%20an%20ID%20and%20a%20canonical%20name.%20Consequently%2C%20the%20admins%20would%20need%20to%20know%20the%20objectId%20of%20the%20groups%20and%20the%20users%20would%20only%20be%20able%20to%20assign%20permissions%20on%20%22cryptic%22%20objectIds.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20is%20not%20user%20friendly%20and%20blocks%20us%20from%20moving%20our%20SAML%20authentication%20to%20Azure.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ECan%20you%20recommend%20a%20way%20that%20enables%20to%20migrate%20to%20Azure%20while%20keeping%20group%20%3CU%3Enames%3C%2FU%3E%26nbsp%3B(CN%2FSamAccountName)%20in%20the%20SAML%20token%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1778199%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Esaml%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1784607%22%20slang%3D%22en-US%22%3ERe%3A%20How%20To%20Work%20Around%20The%20Azure%20SAML%20Group%20Claim%20Limitations%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1784607%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F65328%22%20target%3D%22_blank%22%3E%40Daniel%20Niccoli%3C%2FA%3E%26nbsp%3B%20-%20Use%20app%20roles.%20These%20are%20human%20readable%2C%20no%20group%20IDs%20and%20token%20bloat%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fhowto-add-app-roles-in-azure-ad-apps%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fdevelop%2Fhowto-add-app-roles-in-azure-ad-apps%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1795366%22%20slang%3D%22en-US%22%3ERe%3A%20How%20To%20Work%20Around%20The%20Azure%20SAML%20Group%20Claim%20Limitations%3F%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1795366%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F8188%22%20target%3D%22_blank%22%3E%40Lavanya%20Murthy%3C%2FA%3E%26nbsp%3B%20That's%20not%20feasible.%20Users%20are%20creating%20new%20groups%20on%20a%20weekly%20basis.%20We%20need%20something%20that%20works%20out%20of%20the%20box%20and%20is%20scalable.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Regular Contributor

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 the cloud app.

 

The way this works is that is this:

  • The Office 365 groups are synced back to our on-premises AD.
  • The Office 365 groups must have the prefix 365sec_ in their CN and SamAccountName.
  • The cloud application must support group membership claims and the groups must be created in the app with the same name.
  • When the user authenticates, ADFS adds all groups to the token, that have the prefix "365sec_" and the user is a member of.
  • The user is now able to access all resources within the cloud app that grant him access based on group name and membership.

 

As an example, a SAML token for user Jon Doe would look like this:

  • Name-ID: jon.doe@exmaple.com
  • E-Mail: jon.doe@exmaple.com
  • GivenName: Jon
  • Surname: Doe
  • Groups: 365sec_Account-SeeShell
  • Groups: 365sec_Account-Wayland
  • Groups: 365sec_Project-Samson
  • Groups: 365sec_Project-VisION

 

We planned to move to Azure SAML, but I learned that Azure does not support adding the group CN or SamAccountName to the token, but only the objectId.

 

All of our cloud apps only support adding groups by Name. This seems to be the de-facto standard. It is not possible in the cloud apps to create groups with an ID and a canonical name. Consequently, the admins would need to know the objectId of the groups and the users would only be able to assign permissions on "cryptic" objectIds.

 

That is not user friendly and blocks us from moving our SAML authentication to Azure.

 

Can you recommend a way that enables to migrate to Azure while keeping group names (CN/SamAccountName) in the SAML token?

6 Replies
Highlighted
Highlighted

@Lavanya Murthy  That's not feasible. Users are creating new groups on a weekly basis. We need something that works out of the box and is scalable.

@Daniel Niccoli 

 

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

Highlighted

Optional claims are only supported for groups synced from AD.

so, your options are to use groups syned from AD instaed of O365 groups or use app roles

 

See the link below 

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims?WT.mc...

 

 

Highlighted

Optional claims are only supported for groups synced from AD.

so, your options are to use groups synced from AD instead of O365 groups or use app roles

 

See the link below 

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims?WT.mc...

 

 

Highlighted
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.