locked
ADFS TP4 issue with missing scope on native client sample RRS feed

  • Question

  • I've taken this AAD sample - https://github.com/Azure-Samples/active-directory-dotnet-native-desktop.

    "This sample demonstrates a .Net WPF application calling a web API that is secured using Azure AD. The .Net application uses the Active Directory Authentication Library (ADAL) to obtain a JWT access token through the OAuth 2.0 protocol. The access token is sent to the web API to authenticate the user."

    I've converted it to use the "Native Application and Web API" Application Group with ADFS on TP4.

    Scope is not being returned so the application fails on:

    /*if (ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/scope").Value != "user_impersonation")
                {
                    throw new HttpResponseException(new HttpResponseMessage { StatusCode = HttpStatusCode.Unauthorized, ReasonPhrase = "The Scope claim does not contain 'user_impersonation' or scope claim not found" });
                }*/

    If I comment out the code as above, it works.

    I have "user-impersonation" ticked in the "Client Permissions" section.

    Does this ring any bells?


    • Edited by nzpcmad1 Wednesday, March 30, 2016 1:08 AM Expand
    Wednesday, March 30, 2016 1:04 AM

Answers

  • 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'.
    • Proposed as answer by Toby Artisan Monday, November 27, 2017 7:31 PM
    • Marked as answer by nzpcmad1 Monday, November 27, 2017 7:43 PM
    Monday, November 27, 2017 7:30 PM

All replies

  • Hi,

    Thanks for your post.

    Since the query is more related to ADFS, it is better for you to visit the dedicated ADFS support Forum. It is also appreciated that the other members in our forum can share their experience with us about this scenario.

    ADFS forum

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=ADFS&filter=alltypes&sort=lastpostdesc

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us.  Thank you for your understanding.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Alvwan Wednesday, March 30, 2016 6:56 AM
    • Unproposed as answer by Amy Wang_ Tuesday, April 5, 2016 8:48 AM
    Wednesday, March 30, 2016 5:56 AM
  • Thanks for your reply.

    I am active on the ADFS forums but to date there has been very little Server 2016 discussion.

    This question is TP4 specific since earlier versions of ADFS do not offer this functionality.

    More details : ADFS - Native Client and Web API on Server 2016 TP4 ADFS 4.0.

    • Edited by nzpcmad1 Wednesday, March 30, 2016 9:32 PM Expand
    Wednesday, March 30, 2016 8:16 PM
  • Hi,

    Thanks for your reply.

    I do understand the inconvenience the issue brought but I am afraid to tell that ADFS forum is a better place to discuss this issue.

    Thanks for your understanding.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, April 1, 2016 1:52 AM
  • 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'.
    • Proposed as answer by Toby Artisan Monday, November 27, 2017 7:31 PM
    • Marked as answer by nzpcmad1 Monday, November 27, 2017 7:43 PM
    Monday, November 27, 2017 7:30 PM