ADAL incorrectly uses SAML1.1 token for urn:ietf:params:oauth:grant-type:saml2-bearer based grant type

[maweeras-msft]

azure-activedirectory-library-for-dotnet/src/Microsoft.IdentityModel.Clients.ActiveDirectory/Internal/Flows/AcquireTokenNonInteractiveHandler.cs

Line 126 in 3982cb2

this.userAssertion = new UserAssertion(wsTrustResponse.Token, (wsTrustResponse.TokenType == WsTrustResponse.Saml1Assertion) ? OAuthGrantType.Saml11Bearer : OAuthGrantType.Saml20Bearer);

is incorrectly evaluating a SAML1.1 token for the saml2-bearer grant type.

In Azure Information protection (AIP), we see logs like so.

In the AIP logs it reports the following from ADAL
Debug 2017-10-25 09:47:14.6213 MSIP.Auth WINWORD (11972) [AdalLog] 25.10.2017 07:47:14: 3ecf0ca4-981a-4021-a7f4-a85ae0f495f0 - AcquireTokenNonInteractiveHandler.cs: Token of type 'http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1' acquired from WS-Trust endpoint "System.Threading.Tasks.Task.FinishContinuations System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run System.Threading.ExecutionContext.Run System.Threading.ExecutionContext.RunInternal System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.InvokeMoveNext Microsoft.IdentityModel.Clients.ActiveDirectory.AcquireTokenNonInteractiveHandler+d__5.MoveNext Microsoft.IdentityModel.Clients.ActiveDirectory.Logger.Information Microsoft.IdentityModel.Clients.ActiveDirectory.LoggerCallbackHandler.ExecuteCallback Microsoft.InformationProtection.Auth.AdalLogCallback.Log" BBMAG\bojaed01 12

Info 2017-10-25 09:47:15.0270 MSIP.Auth WINWORD (11972) "[AdalLog] 25.10.2017 07:47:15: 3ecf0ca4-981a-4021-a7f4-a85ae0f495f0 - AdalHttpClient.cs: Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: AADSTS75005: The request is not a valid SAML 2.0 protocol message. Trace ID: 82705d59-e9c5-40cd-97e5-5d9b63ea0300 Correlation ID: 3ecf0ca4-981a-4021-a7f4-a85ae0f495f0 Timestamp: 2017-10-25 07:47:14Z

Line 126 checks wsTrustResponse.TokenType == WsTrustResponse.Saml1Assertion

Here wsTrustResponse.TokenType is "http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" as per AIP log extract .

but WsTrustResponse.Saml1Assertion is "urn:oasis:names:tc:SAML:1.0:assertion" as per

azure-activedirectory-library-for-dotnet/src/Microsoft.IdentityModel.Clients.ActiveDirectory/Internal/WsTrust/WsTrustResponse.cs

Line 38 in 3982cb2

public const string Saml1Assertion = "urn:oasis:names:tc:SAML:1.0:assertion";

Therefore, we always end up using urn:ietf:params:oauth:grant-type:saml2-bearer even when we have a SAML1.1 token and should use urn:ietf:params:oauth:grant-type:saml1_1-bearer instead.

This is currently impacting AIP client but will affect anything else that tries to use a SAML1.1 token with Azure AD with the saml2-bearer grant type.

[jmprieur]

Today, the identity provide needs to be configured to support the "urn:oasis:names:tc:SAML:1.0:assertion" claim.
We want to look for 1.0, and then if it's not there, 1.1, and then assume SAML 2.0

[SaeedAkhter-MSFT]

More details on the scenario from the support team - Scenario is that Azure AD is federated to Ping and it's configured to issue back a SAML 1.1 token. The library has string comparison logic to detect SAML 1.0 and SAML 2.0 but not SAML 1.1. Does this issue exist on MSAL.NET?

[henrik-me]

Closing as we are not adding new features to ADAL. If you believe there is an issue which needs to be addressed in ADAL, please don't hesitate to re-open or create a new issue.

Please try out MSAL, the authn library which is part of the Microsoft identity platform.

If you find any issues using MSAL, please open an issue there.