Forum Discussion

DanielNiccoli's avatar
DanielNiccoli
Steel Contributor
Oct 14, 2020

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 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?

Resources