Bac Hoang [MSFT]

Customers can get the following error when authenticating to Azure Active Directory with a federated account using MSAL (or now deprecated ADAL) Authentication library.

{
     error: "invalid_request",
     error_description: "AADSTS7500514: A supported type of SAML response was not found. The supported response types are 'Response' (in XML namespace 'urn:oasis:names:tc:SAML:2.0:protocol') or 'Assertion' (in XML namespace 'urn:oasis:names:tc:SAML:2.0:assertion').
     ....
     error_uri: "https://login.microsoftonline.com/error?code=7500514"
}

The error is typically seen in the following environment:

  • A federated account using PingFederate as the Identity Provider (IDP) is used for authentication
  • The IDP is configured to issue a SAML 1.1 token (via WS-Trust protocol).
  • The application uses one of the following API:
    • MSAL’s AcquireTokenByUserNamePassword
    • ADAL’s AcquireToken(string resource, string clientId, UserCredential userCredential) overload method is used
    • any PowerShell module that uses ADAL or MSAL’s above methods for authentication

Why is this error happening when I am using ADAL or MSAL’s API?

In order to understand this error, we need to understand a little bit about how the API works when passing in a username (User Principal Name (UPN)) and password. Since ADAL library is becoming deprecated, we will discuss this in terms of MSAL library (the recommended authentication library over ADAL). The above MSAL API has an internal heuristics to determine if the user account is managed (cloud account) or federated and will take different code paths (OAuth2 grant flows) to authenticate silently to Azure AD. For managed accounts, MSAL uses Resource Owner Password Credentials Grant (ROPC) flow, while for federated accounts, it uses SAML Assertion Grant flow for authentication. If you notice, there are two steps involved in the SAML Assertion Grant flow:

  1. The client application authenticates to the federated IDP (typically using WS-Trust protocol) to obtain a SAML token
  2. the client then uses the obtained SAML token to get an OAuth2 JWT token from Azure AD

The problem typically happens in step 1 where the client application (MSAL in this case) needs to parse the SAML response from the IDP to determine the SAML version. Historically, both ADAL and MSAL were developed to support how ADFS works in conjunction with Azure AD for federated accounts, so it expects certain attribute values present in the SAML response to determine the version of the SAML token. The SAML token version shows up in a couple of places: <saml:Assertion> node and <TokenType> node. Below is ADFS Response from the usernamemixed endpoint:

  1. SAML Assertion: major version = 1 and minor version = 1
  2. TokenType: urn:oasis:names:tc:SAML:1.0:assertion

Compare the same request when PingFederate is an IDP:

Note that Ping returns a different TokenType value: http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 for the same SAML 1.1 token.

For SAML 1.1 token, MSAL does not support any TokenType value other than urn:oasis:names:tc:SAML:1.0:assertion (what ADFS uses), so when an IDP returns a different value, MSAL incorrectly thinks the SAML token version is 2.0. See https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1871 for more info.

In step 2 of the SAML Assertion Grant flow, the value of the ‘grant_type’ parameter are different for different SAML versions. They are listed below:

urn:ietf:params:oauth:grant-type:saml2-bearer – for SAML2.0 token

urn:ietf:params:oauth:grant-type:saml1_1-bearer – for SAML1.1 token

In this case with PingFederate account, MSAL uses the wrong ‘grant_type’ parameter due to the above logic, leading to the error since there is a version mismatch between the ‘grant_type’ parameter and the assertion (containing the actual SAML token) parameter:

For comparison, here is the same token request when ADFS is the IDP:

Ok so I understand the problem. What should I do to resolve this?

The problem is typically due to a misconfiguration on the PingFederate side for Azure AD and Office 365 apps. PingFederate has the following recommended documentation for creating a connection to Azure AD:

Creating a connection to Azure Active Directory
Configuring WS-Trust STS

Pay close attention to step 2d from the first doc for configuring WS-Trust setting:

And from the second documentation, select SAML 1.1 for Office 365 as the Default Token Type

Note: setting the above value for Default Token Type ensures Ping sends back the same TokenType value as ADFS (aka urn:oasis:names:tc:SAML:1.0:assertion)

Consider opening a support case with PingFederate should you require more guidance on the above documentation.

Reference

For information on how to use PostMan to perform SAML Assertion Grant flow, refer to this blog.

Leave a Comment