The SSO on the website stopped working. The SSO uses R12.52 CA Access Gateway (SPS) server in the DMZ and the R12.52 Policy Server as the back end server.
When the issue occurred, a reboot of the CA Access Gateway (SPS) server only and then SSOs work again.
From the Policy Server, the smtracedefault log shows:
[09/03/2016][08:34:12.961][08:34:12][2236][736][AssertionHandlerSAML20.java][postProcess][][][][][][][][][][][][][][][][][][][][][Start to wrap-up the SAML2.0 response.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][logAuditData][][][][][][][][][][][][][][][][][][][][][Error getting filling assertion audit data.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][closeupProcess][][][][][][][][][][][][][][][][][][][][][POST signing option: 0][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][closeupProcess][][][][][][][][][][][][][][][][][][][][][The Response can not be parsed to XML document. Exception Message: The ID '_6d1 [...]a7c' is not unique in this XML document][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
[09/03/2016][08:34:12.961][08:34:12][2236][736][AssertionGenerator.java][invoke][][][][][][][][][][][][][][][][][][][][][AssertionHandler postProcess() failed. Leaving AssertionGenerator.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
Also, from affwebserv log from CA Access Gateway (SPS) server shows the following errors:
"Transaction with ID: 12[...]fb8b failed"
Why is transaction ID is not unique? When rebooting the CA Access Gateway (SPS) server again fixed the issue.
12.52 SP1 Secure Proxy Server
12.52 SP1 Policy Server
<Response Destination="https://_host.example.com/EmployeePortal/SSO" ID="_6d1 [...]a7c" IssueInstant="2016-09-03T13:07:04Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://_host.example.net</saml:Issuer>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<ns2:Assertion ID="_6d1 [...]a7c" IssueInstant="2016-09-03T13:07:04Z" Version="2.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion">
The Assertion ID="_6d1 [...]a7c" at the very bottom matches what is being passed in the Response Destination ID at the very top of this snippet.
A little further down in the logs the following message is found:
[The Response can not be parsed to XML document. Exception Message: The ID '_6d1 [...]a7c' is not unique in this XML document]
This is the message that shows that the Policy Server is complaining about the duplicate IDs. The XML Response Data cannot have the same ID, or else the Assertion gets rejected.
In the following file:
<install-home>\CA\siteminder\config\properties\xsw.properties
In that file, the following code shows:
# Disables XSW checking
DisableXSWCheck=false
When changing the DisableXSWCheck to "true", then the error message should not appear, as the XML will not compare the two ID strings, and should not cause any SSO failure going forward.