Thursday, March 31, 2016

ADFS - Native Client and Web API on Server 2016 TP4 ADFS 4.0

This follows on from my previous post concerning Web App and Web API.

This is for Active Directory Federation Services on Server 2016 Technical Preview 4.

The code is based on the Azure AD sample: Active directory .NET native desktop.

Just ignore all the Azure AD comments. There is no Azure in this solution.

In the solution, I've set the the web API to be at localhost:44324.

The native desktop client is built on WPF.

Just to re-iterate - the ADFS has to be Server 2016 - TP4 and above. This will not work on Server 2012 R2 - ADFS 3.0. 

As before, the changes are all in a gist here.

On to the ADFS configuration:

You need to create a new Application Group.


Create the Native Client


The Client Id needs to be copied over into "ida:ClientId" in the app.config.

Create the web API.


The rest of the configuration is exactly the same as the previous post.

Exactly the same claims rules are required.

You end up with a new application group.


Note in the gist that the code around scope has been commented out. I couldn't get the scope to be passed over.

I raised this in the TP4 forum.

Run up the sample, click "Sign In" in the WPF application and you should be redirected to ADFS for authentication.

Then you should be able to add items to the to-do list.

Enjoy!

1 comment:

Anonymous said...

There is a typo (that was posted by mcdaniel in the comments section) that is most likely causing your issue. I added a longer comment in reply to mcdaniel's comment, and I also copied it below in case anyone arrives at this page first.


The typo found by mcdaniel will cause the request to get an OAuth access token using the On Behalf Of flow to fail because AD FS 2016 looks for the user_impersonation scope in the "scp" attribute of the access token. And the "scp" attribute is only populated when the claim issuance rule issues a claims of type "http://schemas.microsoft.com/identity/claims/scope".


If a claim is issued with the HTTPS prefix, then AD FS 2016 issues a token with an attribute of "https://schemas.microsoft.com/identity/claims/scope" instead of an attribute of "scp".


So, if anyone is receiving an AdalServiceException of MSIS9650 or if anyone is seeing an OAuthInvalidOBOAssertionException in the AD FS event log of type MSIS9386, then verify that your claims issuance rule in AD FS is using "http://schemas.microsoft.com/identity/claims/scope" without the HTTPS.


P.S. The full error message from ADAL is as follows: Error while attempting to get token. Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: MSIS9650: Received invalid OAuth request. Access token in the 'assertion' parameter value doesn't contain required scope claim with value 'user_impersonation'. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (BadRequest). ---> System.Exception: {"error":"invalid_request","error_description":"MSIS9650: Received invalid OAuth request. Access token in the \u0027assertion\u0027 parameter value doesn\u0027t contain required scope claim with value \u0027user_impersonation\u0027."}


P.P.S. The full error message logged by AD FS is as follows: Microsoft.IdentityServer.Web.Protocols.OAuth.Exceptions.OAuthInvalidOBOAssertionException: MSIS9386: Received invalid OAuth request. Access token in the 'assertion' parameter value doesn't contain scope claim with value 'user_impersonation'.