SharePoint: SAML auth login error: There are multiple keys on the token
Consider the following scenario:
Your users authenticate to SharePoint using “Trusted Provider” authentication. This is also known as SAML or WS-Fed authentication, typically provided by AD FS, Ping Federate, Okta, SiteMinder, etc.
After SharePoint upgrade or security patching, users are no longer able to authenticate. They may see a “Server Error in ‘/’ Application” error.
In a Fiddler, or other network trace, you see the failure is an HTTP 500 (Internal Server error) on the POST to _trust.
In the SharePoint ULS logs, you see errors like these for the POST to _trust:
w3wp.exe (0x462C) 0x14C4 SharePoint Foundation Claims Authentication 00000 Unexpected There are multiple keys on the token. bbc3f39e-867e-f083-a4fa-218c7d6fdbb7
w3wp.exe (0x462C) 0x14C4 SharePoint Foundation General 8nca Medium Application error when access /_trust/default.aspx, Error=An XML error has occurred. at Microsoft.SharePoint.SPSaml11BaseTokenHandler.ReadAssertion(XmlReader reader) at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ReadToken(XmlReader reader) at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader) at <stack truncated>) bbc3f39e-867e-f083-a4fa-218c7d6fdbb7
w3wp.exe (0x462C) 0x14C4 SharePoint Foundation Runtime aoxsq Medium Sending HTTP response 500 for HTTP request POST to https://test.contoso.com/_trust/default.aspx bbc3f39e-867e-f083-a4fa-218c7d6fdbb7
Cause:
Your SAML assertion contains more than one key. Due to security enhancements made in response to CVE-2019-1006, multiple keys are no longer allowed.
This has been changed for every currently supported version of SharePoint in the July 2019 security updates. Those updates have also been rolled into the July 2019 cumulative updates. I have listed each product, the security update KB, and build number where this change was made. If you are at or above that build number, this security enhancement is in place.
SharePoint 2019
Update: https://support.microsoft.com/en-us/help/4475529
Build: 16.0.10348.12104
SharePoint 2016
Update: https://support.microsoft.com/en-us/help/4475520
Build: 16.0.4873.1000
SharePoint 2013
Update: https://support.microsoft.com/en-us/help/4475522
Build: 15.0.5153.1000
SharePoint 2010
Update: https://support.microsoft.com/en-us/help/4475510
Build: 14.0.7235.5000
Resolution:
This is going to vary depending on which SAML provider (ADFS, Ping Federate, Okta, SiteMinder, etc) you’re using.
You can use a tool like Fiddler to capture the SAML assertion and have a look at the <ds:KeyInfo> tag within it. This will typically be an X509 certificate. For example, this is what it would normally look like:
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIC3jCCAcagAwIBAgIQJSBtez7rhatPMAZOAxK5VjANBgkqhkiG9w…<truncated>…</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
And here’s an example of a problematic SAML assertion with more than one key:
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDeDCCAmCgAwIBAgIGAVmtVNCpMA0GCSqGSIb3DQEBCwUAMH…<truncated>…</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
iW9Q4RvHe/3vD1o9oep5jOIKyJVQe2uT+IiySNNExHG…<truncated>… </ds:Modulus>
</ds:RSAKeyValue>
</ds:KeyValue>
</ds:KeyInfo>
At the time of this writing, I know of only one scenario where this happens with SAML provider “Ping Federate”.
There’s a Ping Federate setting “Include Raw Key in KeyValue“. If that is enabled, it will add a second RSA key to the SAML assertion like you see in the example above.
I’m not sure what purpose that value is supposed to serve, but post-July 2019 security updates, SharePoint will no longer accept it. The only solution is to set it to “false”.