Azure AD – Add Custom claims for WS-Federation applications

Disclaimer: The information in this weblog is provided “AS IS” with no warranties and confers no rights.

Most guides using Azure AD as IDP focus at OAuth and OAuth2/w OIDC flows for API access, and for enterprise SSO SAML. Not much endorsement for WS-Federation, and that’s understandable because the two previous options cover pretty much every scenario you would ideally have. But what if you have a app that is using explicitly WS-Federation? For example Microsoft OWIN based application?

There aren’t good support articles on using WS-Federation and custom claims in Azure AD when Azure AD is IDP, but WS-Federation is definitely supported when Azure AD is acting as IDP .

The only article I found covering custom claims and mentioning WS-Federation was the one I’ve used to write my previous article on preview of custom claims (how to get sAMAccountName into JWT tokens)

Since Azure AD App’s are largely protocol agnostic I figured that maybe the claims mappings are somewhat ambiguous also, just as long you understand how custom claims, and federations work

Guide to testing

The order here is important. While SAML endpoint is enabled by default in any Azure AD App, any specific settings, especially one’s for configuring Service Provider aren’t directly available in the ”non-SAML” app you create – Unless you play around with the App Registration Manifest. But there are other features that require spawning app initially as SAML app (For example using custom token sign-in cert, using token encryption and so on)

• Configure new SAML federation at Azure AD

• Add the custom claims for the federation

• Set Single-Sign On mode to disabled
  • If you’re planning to use this in production, you have get the Metadata from SAML federation settings, I will do some further investigation later to update this blog

• For metadata replace the metadata URL with tenant and AppID details
  • https://login.microsoftonline.com/yourtenantID/federationmetadata/2007-06/federationmetadata.xml?youreAppid

Test the federation.

I have handy NodeJS Express App I use pretty much for testing and debugging any authorization related stuff, with very simple purpose of catching different inbound calls.

About the code… The code itself is epitome of laziness, so I am too embarrassed to share it :)…

• Invoke the call
  • Use AppID or any Identifier you’ve defined in the manifest
  • If you have multiple reply URL’s define the ’wreply’ param

https://login.microsoftonline.com/common/wsfed?
 wtrealm=1de8c976-fe00-4008-91d5-e5a2381d40a6
 &wctx=WSfedState
 &wa=wsignin1.0

• Confirm the emitted claims
  • In this particular case its user.displayname +(join) user.dnsdomain

There are many questions and details that I could add here, but since I am just fooling around with a feature, I am not devoting any more time until there is actual production need for such scenario.