[Bug] MSAL.Net incorrectly detects SAML1.1 token leading to error "AADSTS7500514: A supported type of SAML response was not found" (Ping Federation)

[bachoang]

Which Version of MSAL are you using ?
Note that to get help, you need to run the latest version. Preview version are also ok.
For ADAL, please log issues to https://github.com/AzureAD/azure-activedirectory-library-for-dotnet

This problem exists in all version of MSAL including the latest version v4.14.0
Platform

What authentication flow has the issue?

• Desktop / Mobile
  • Interactive
  • Integrated Windows Auth
  • [ x] Username Password
  • Device code flow (browserless)
• Web App
  • Authorization code
  • OBO
• Web API
  • OBO

Other? - please describe;

Is this a new or existing app?

Repro
This is the same problem that ADAL.Net has for Federated scenario, see the following github issues for background info:

AzureAD/azure-activedirectory-library-for-dotnet#893
AzureAD/azure-activedirectory-library-for-dotnet#420

Environment:
Azure AD is federated with another IDP like ADFS, PingFederate, etc...

When authenticating with a UserName and Password, MSAL (and ADAL) uses SAML Assertion Grant flow (https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-saml-bearer-assertion) to request a SAML token from the IDP and then exchange that SAML token for an JWT OAuth2 token. The problem is typically seen with PingFederate since Ping issues a SAML v1.1 token. MSAL incorrectly detects the SAML token version as V2.0 token and hence sends the v2 token bearer with a v1.1 token payload to Azure AD, which causes the above AADSTS error.

Below is the code snippet that causes the problem:

            var pcaOptions = new PublicClientApplicationOptions
            {
                ClientId = "app id",
                TenantId = "Directory ID"
            };

            var pca = PublicClientApplicationBuilder
                .CreateWithApplicationOptions(pcaOptions).Build();

            var ewsScope = new string[] { "https://graph.microsoft.com/.default };

            var s = new System.Security.SecureString();
             s.AppendChar('p');
             s.AppendChar('a');
             s.AppendChar('a');
             s.AppendChar('s');
             s.AppendChar('s');
             s.AppendChar('w');
             s.AppendChar('o');
             s.AppendChar('r');
             s.AppendChar('d');

             var authResult = await pca.AcquireTokenByUsernamePassword(ewsScope, "user@contoso.com", s).ExecuteAsync();  // contoso.com is a federated domain

Expected behavior
AAD returns a successful JWT access token

Actual behavior
AAD returns error : 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').

Possible Solution

Additional context/ Logs / Screenshots
Fiddler trace analysis:

1. MSAL (after performing a home realm discovery) sends a POST request to the IDP (PingFederate in this case) to get a SAML token using WS-Trust protocol:

POST https://pingfedactive..com/idp/sts.wst?TokenProcessorId=O365Token

Body:
WS Trust XML Payload containing username and password

response:
HTTP/1.1 200 OK
...
Content-Type: application/soap+xml; charset=utf-8

payload:
<s:Body>
<wst13:RequestSecurityTokenResponseCollection xmlns:wst13="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
....
wst13:RequestSecurityTokenResponse
wst13:TokenTypehttp://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst13:TokenType>
wst13:RequestedSecurityToken
<s:Body>
<wst13:RequestSecurityTokenResponseCollection xmlns:wst13="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
wst13:RequestSecurityTokenResponse
wst13:TokenTypehttp://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst13:TokenType>
wst13:RequestedSecurityToken

*** Note in the above response, the IDP returns the following TokenType (Token version) and that's what leads to the problem.
wst13:TokenTypehttp://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst13:TokenType>
wst13:RequestedSecurityToken

MSAL's detection logic parses the token type above and thinks this is a SAML V2 token so it sends the following POST request to AAD to exchange for the JWT token:

POST https://login.microsoftonline.com/Directory ID/oauth2/v2.0/token
body:
client_id=xxx
&client_info=1
&scope=openid offline_access profile https://graph.microsoft.com/.default
&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer
&assertion=SAML1.1 Assertion

response:
400 Bad 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

**** MSAL should send the following grant_type for a V1.1 token:
urn:ietf:params:oauth:grant-type:saml1_1-bearer

The bug is in the following file detecting the SAML Token version:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/1cef43d185bb0a1dcc013d2ec232ae9d4c6c053a/src/client/Microsoft.Identity.Client/WsTrust/WsTrustResponse.cs
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/20f633ac1ceea4cbb9dd3f1fa7ea9236be4322ac/src/client/Microsoft.Identity.Client/Internal/Requests/UsernamePasswordRequest.cs

Basically MSAL just looks at the WS Trust response to look for the following TokenType node:
"urn:oasis:names:tc:SAML:1.0:assertion"
If the above TokenType value exists then it's a SAML 1.1 token, everything else must be SAML 2.0 token. This is the wrong logic. The above tokentype is what ADFS uses but that may not be the correct version based on the Token Version specification.

Based on the following specification, the SAML token version value should be the following:

http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SAMLTokenProfile-v1.1.1-os.html

Section 3.4:

Assertion Version
Value

V1.1 <================
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1

V2.0
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

This bug has been around long enough and we need to fix this so MSAL can support other federated IDPs, and not just ADFS.

Summary:
MSAL should correctly detect the SAML1.1 token if the TokenType is one of the following:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1 or
urn:oasis:names:tc:SAML:1.0:assertion

grant_type=urn:ietf:params:oauth:grant-type:saml1_1-bearer

and use the following grant_type for SAML2.0 TokenType:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer

[jmprieur]

@bachoang could it be a configuration issue with the federation server? or are you sure this is a bug in MSAL.NET (and ADAL.NET)?

[bachoang]

@jmprieur based on everything I am seeing and comparing it to the specification. I don't see anything the IDP is doing incorrectly. The IDP is sending back a SAML 1.1 token in their Assertion element below:

saml:Assertion [ AssertionID=NX1Mbx7WnPnhbLgAf8t2JQS1c7W IssueInstant=2020-05-11T15:53:24.967Z Issuer=MerckPingIDPWSFedPROD MajorVersion=1 MinorVersion=1 xmlns:saml=urn:oasis:names:tc:SAML:1.0:assertion ]

Based on the token profile specification (section 3.4 Table 3) at https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

specifying the TokenType element to be "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" is the correct value for a SAML 1.1 token.

Unfortunately ADFS does not adhere to the standards. I have asked this question on the ADFS engineering team but no one can give me a straight answer. ADFS has been around for 15 years so it might have carried a lot of legacy behavior forward (perhaps even before the standards was defined).

MSAL should be able to detect the correct SAML token version for any IDP (and not just geared for ADFS).

[bgavrilMS]

P1 because it is a blocker for migration of v1 to v2

[neha-bhargava]

Fixed in MSAL 4.17.0 release

[bgavrilMS]

Not fixed.

[jennyf19]

@bgavrilMS @neha-bhargava What's the status on this?

[bgavrilMS]

Parsing the MEX document and understanding SAML is very difficult and I do not have enough expertise or test resources to make meaningful progress. I am marking this item as blocked until we can find better guidance (C++ or WAM?)

@jmprieur @henrik-me

[bgavrilMS]

For an example SAML response that can be used for Integrated Windows Auth, please see

microsoft-authentication-library-for-dotnet/tests/Microsoft.Identity.Test.Unit.net45/Resources/TestMex2005.xml

Line 785 in cd4ebe0

https://sts.usystech.net/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256

[henrik-me]

@jmprieur for evaluating priority

[jmprieur]

Closing a duplicate of #2152 which is better explained.
and moving to 4.24.0