Passing Additional Attributes during Authentication?

[Chad Carlton]

SAML2, and OIDC both support transporting additional attributes during authentication. This is very useful to setup Just in Time (JIT) provisioning.  

What is the recommended way to store additional attributes in AAD, and how can I configure the AAD application authentication entry to send these additional attributes to the application during authentication?

Hypothetical example: my guest users fall into 3 categories; Bronze, Silver, and Gold.  Each of my 4 SaaS applications react differently for users depending on this category.  I would like to not have to setup a user 4 seperate times, specifying their category level for each application. (and when that category increases decreases, have to visit each application to change it).  

These 4 SaaS applications support SAML2 or OIDC, and understand how to read (even custom) attributes out of those authentications.  These applications are not Azure Gallery apps/do not understand Graph API, and are not setup to use remote user lookup capabilities like the Userinfo endpoint from OIDC.

I thought it would be possible to add a "category" to my guest users in my Azure Active Directory, and then configure the application entries in AAD to send/push 'category' along with the other basic profile attributes and authentication. 

How do I do this? 

[#2]

It seems like open extensions (https://developer.microsoft.com/en-us/graph/docs/concepts/extensibility_open_users) or schemaExtensions(https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/schemaextension) are good ways to store this sort of information.

If I do store something like category as an openExtension attribute, how do I specify an openExtensionID.attribute as a value in an outbound SAML claim or an OIDC attribute?

[#3]

Or If I am using SCIM, how do I map a custom attribute (hypothetically speaking a Open, or even schema extension attribute) to a SCIM attribute configuration entry?

https://github.com/Microsoft/azure-docs/blob/master/articles/active-directory/active-directory-saas-...

[#4 · Accepted solution]

After some more research, and digging through documentation, I think this is the process that needs to be followed for the 'category' = { Bronze,Silver,Gold} example above

1. Decide to use either Roles or Groups for this. (I think I can get the business to accept using groups)
2. Goto each Applications entry in the AAD application Registration list, and download the Manifest.
3. Edit the manifest, looking for: "groupMembershipClaims=null,"
4. change this to: groupMembershipClaims="SecurityGroup"
5. upload/save the application manifest

The application should now be recieving a claim called groups, that contains the users groups.

This post describes this more: 

https://blogs.technet.microsoft.com/enterprisemobility/2014/12/18/azure-active-directory-now-with-gr...

For more complex data exchange, I also was able to get a hold of this page, describing a way to extend the directory schema to store additional attributes for an application. (https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/application_post_extensionpr...)

I believe attributes that are added this way can then be used during SAML2/OIDC claims mapping/transformation, and also in SCIM mapping.