Signature validation errors when using SAML Authentication with Azure SSO
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Users are unable to login in Confluence when using SAML configuration against Azure SSO
Please, review carefully our KB How to integrate Confluence Data Center with Azure for SAML 2.0 SSO to ensure the configuration is correct before moving further with this document
Environment
Confluence 7.19.X or Confluence 8.X
Diagnosis
When enabled DEBUG level for the classes below:
- com.onelogin.saml2
- com.atlassian.plugins.authentication
The following signature validation errors can be found in the atlassian-confluence.log files:
2023-11-21 16:00:54,050 ERROR [http-nio-8090-exec-4 url: /plugins/servlet/saml/auth] [microsoft.saml.operations.SAMLResponseProcessor] processSAMLResponse MS_DEBUG LOG : samlResponse in Xml String format :<samlp:Response ID=\"_b40ee515-dafb-4f98-b9d1-0c3cd7669dc3\" Version=\"2.0\" IssueInstant=\"2023-11-21T13:00:53.880Z\" Destination=\"https://CONFLUENCE_URL/plugins/servlet/saml/auth\" InResponseTo=\"MSSSO_fd1ee8e3-a3c0-4bbc-a0a5-49f282c93382\" xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\"><Issuer xmlns=\"urn:oasis:names:tc:SAML:2.0:assertion\">https://sts.windows.net/1a578556-a789-4135-ac78-506d6b3abe05/</Issuer><samlp:Status><samlp:StatusCode Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\"/></samlp:Status><Assertion ID=\"_11e6e716-acf1-46f1-8e65-40b5eab8ff00\" IssueInstant=\"2023-11-21T13:00:53.877Z\" Version=\"2.0\" xmlns=\"urn:oasis:names:tc:SAML:2.0:assertion\"><Issuer>https://sts.windows.net/1a578556-a789-4135-ac78-506d6b3abe05/</Issuer>...
...
...
..
2023-11-21 16:00:54,051 ERROR [http-nio-8090-exec-4 url: /plugins/servlet/saml/auth] [microsoft.saml.operations.SAMLResponseProcessor] validateResponseExpiry MS_ERROR : nbAttribute: NotBefore=\"2023-11-21T13:00:53.880Z\"
-- url: /plugins/servlet/saml/auth | userName: anonymous | referer: https://login.microsoftonline.com/ | traceId: cef0346862151876
2023-11-21 16:00:54,064 ERROR [http-nio-8090-exec-4 url: /plugins/servlet/saml/auth] [microsoft.saml.util.SignatureValidator] validate MS_INFO : SignatureValidator started to validate signature tags
-- url: /plugins/servlet/saml/auth | userName: anonymous | referer: https://login.microsoftonline.com/ | traceId: cef0346862151876
2023-11-21 16:00:54,066 ERROR [http-nio-8090-exec-4 url: /plugins/servlet/saml/auth] [microsoft.saml.util.SignatureValidator] validate MS_INFO : SignatureValidator Completed validation of signature tagsIf you captured the SAML response with the SAML Chrome Panel, you can observe that indeed the NotBefore and NotOnOrAfter attributes are in an interval 3 hours behind the actual request in the Confluence side:
...
<Conditions NotBefore="2023-11-21T13:00:53.880Z" NotOnOrAfter="2023-11-21T14:05:53.880Z">
<AudienceRestriction>
<Audience>https://CONFLUENCE_URL/</Audience>
</AudienceRestriction>
</Conditions>
...Cause
When the IdP (Azure SSO) creates a request with a specific timestamp and the SP servers (Confluence) clock is slower or faster than the IdP clock, the response will contain a NotBefore or NotOnOrAfter time stamp that will fit into the SP clock. Hence, when the assertion occurs in the SP with the SAML response, it will check if it did not expired and it is valid.
From Microsoft documentation "Single sign-on SAML protocol", it seems this is set as follows:
The NotBefore and NotOnOrAfter attributes specify the interval during which the assertion is valid.
- The value of the NotBefore attribute is equal to or slightly (less than a second) later than the value of IssueInstant attribute of the Assertion element. Microsoft Entra ID does not account for any time difference between itself and the cloud service (service provider), and does not add any buffer to this time.
- The value of the NotOnOrAfter attribute is 70 minutes later than the value of the NotBefore attribute.
Solution
If Microsoft does not allow to tune these attributes (NotBefore and NotOnOrAfter), please check other alternatives such as:
- Ensure that IdP (Microsoft) is in the same timezone as your Confluence instance.
- If yourAzure and Confluence servers are not in sync, when they should, please check your NTP servers and related configuration.
- Consider to configure an additional parameter called NotBeforeSkew that allows a little clock skew to account for small clock drifts.
- Please, review the official Microsoft documentation for further details: ADFS > Set-AdfsRelyingPartyTrust.