CODEWITHSUNDEEP
oauth-2.0openid-connectadfs4.0
Tim Dean
Tim Dean

Reputation: 8292

ADFS 2016 support for OIDC's `profile` scope?

I am trying to implement a web application using OIDC and the Authorization Code flow. I am using the OIDC Core 1.0 specification as a reference for how things should be working. I am trying to get this working against a Microsoft ADFS 2016 server, which generally claims support for OIDC.

I have managed to get the workflow working for the most part, with one exception. When I call the token endpoint to exchange my authorization code for an access_token and an id_token, I am hoping to get the user's displayable name via the name claim. But that claim is not present in the tokens I receive from ADFS.

When I redirect to the ADFS server's authorization endpoint, I pass it scope values of openid profile. According to section 5.4 of the OIDC specification, the profile scope should cause the name claim to be requested. But I don't receive that claim. I do get a few other claims I could consider using (i.e. upn or unique_name) but I am trying to be as closely aligned with the standards as I can be.

Does this mean that ADFS 2016 is out of compliance with the OIDC specification in this particular area? Or am I mis-reading the sections of the specification that I referenced here?

Upvotes: 1

Views: 1595

Answers (2)

Rob Traynere
Rob Traynere

Reputation: 704

While everything I see points to ADFS 4 on Server 2016 supporting standard OIDC scopes / claims such as email & profile, in practice I was not able to get this to work.

I did find a work-around:

  1. Make sure you are using the token endpoint (not the userinfo endpoint) in your application. (if you're setting up a federation from another platform, make sure the userinfo endpoint is not set)
  2. Open the Web API Properties for your app in ADFS by opening the ADFS Management tool > Select "Application Groups" from the navigation pane > Double-click the name of your app > double-click the name of the associated Web API.
  3. Select the "Client Permissions" tab, then check the "allatclaims" checkbox in the "Permitted scopes:" section.
  4. Select the "Issuance Transform Rules" tab, then the "Add Rule..." button (if you have existing rules you can modify them or delete).
  5. Select "Send LDAP Attributes as Claims" from the drop-down list, then click the "Next >" button.
  6. Give the rule any name.
  7. Select your Active Directory from the "Attribute store:" drop-down list.
  8. Add the attributes you'd like sent with the claims in the "Mapping of LDAP attributes to outgoing claim types:" section... enter the name of the AD attribute you want to send in the left box (you can type to quick-find), then he name you want the outgoing claim to be sent as in the right box.

For instance: type "mail" in the left box to select the "Email Address" AD attribute, then type "email" in the right box to send the attribute out as an "email".

  1. When you are finished adding any attributes you would like added click the "Finish" button.
  2. Next click the "OK" button on the Web API Properties window for your app to save the changes.
  3. Finally, click the "OK" button on your application group properties.

I'm still not sure WHY this doesn't work as intended for me, all of my settings seem correct. I have seen many people asking this question though, so I hope this helps someone else down the line.

If anyone has any idea why ADFS 4.0 on Server 2016 isn't working as intended for this, PLEASE let me know in the comments!

Upvotes: 0

Gary Archer
Gary Archer

Reputation: 29218

The standard claims related to name are typically given_name and family_name as covered in Section 18 and I always try to code apps in terms of these values, so your concerns are correct.

As a consumer you should also be able to choose where these claims are issued. It is common for providers to not meet standards exactly though, so you may have to adapt your code slightly.

Here is an MS Article on customizing ADFS claims, though it may not give you a clear sense of how claims should work.

FURTHER INFO

At a high level, here is how OAuth systems are meant to issue claims:

  • User authenticates (and may also grant consent)
  • Authorization Server records this 'delegation' in its database, along with the associated claims and scopes
  • Apps can control how and where the claims are exposed, eg which tokens or endpoints include them

For further info see this article on Personally Identifiable Information (PII) - and see how Claims Mappers work in the Curity system.

It may be that your ADFS provider doesn't give you full control, but it is worth being aware of the design patterns, and to reduce user info in tokens where you can.

Upvotes: 1

Related Questions