SSO stopped working on HR website
search cancel

SSO stopped working on HR website

book

Article ID: 5065

calendar_today

Updated On:

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On

Issue/Introduction

The SSOs on our HR website stopped working in the morning of Sept. 3. The SSO uses R12.52 SPS server in DMZ and the R12.52 policy server as the back end server. When the issue occurred, we rebooted the SPS server only and then SSOs work again. 

I am uploading the logs for your the check. The error I found on policy server  smtracedefault log is: 

 

[09/03/2016][08:34:12.961][08:34:12][2236][736][AssertionHandlerSAML20.java][postProcess][139957d9-9577ef13-371cdb48-06d3a404-255d77cc-8ac][][][][][][][][][][][][][][][][][][][][Start to wrap-up the SAML2.0 response.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][logAuditData][139957d9-9577ef13-371cdb48-06d3a404-255d77cc-8ac][][][][][][][][][][][][][][][][][][][][Error getting filling assertion audit data.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][closeupProcess][139957d9-9577ef13-371cdb48-06d3a404-255d77cc-8ac][][][][][][][][][][][][][][][][][][][][POST signing option: 0][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[09/03/2016][08:34:12.961][08:34:12][2236][736][AuthnRequestProtocol.java][closeupProcess][139957d9-9577ef13-371cdb48-06d3a404-255d77cc-8ac][][][][][][][][][][][][][][][][][][][][The Response can not be parsed to XML document. Exception Message: The ID '_6d1107235ac34ad9ea4e242fecda21e52a7c' is not unique in this XML document][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

[09/03/2016][08:34:12.961][08:34:12][2236][736][AssertionGenerator.java][invoke][139957d9-9577ef13-371cdb48-06d3a404-255d77cc-8ac][][][][][][][][][][][][][][][][][][][][AssertionHandler postProcess() failed. Leaving AssertionGenerator.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

 

 

Also from affwebserv log in SPS server, I found following errors :

“Transaction with ID: 12eac848-fb750d7d-3db699a7-8de80982-f83b5fb1-fb8b failed”

 

Please let me know what caused the SSO errors and why transaction ID is not unique. Again reboot of SPS server fixed the issue and we did not do anything to policy server at that time.

Environment

12.52 SP1 Secure Proxy Server12.52 SP1 Policy Server

Cause

<Response Destination="https://www-us.computershare.com/EmployeePortal/SSO" ID="_6abedd677697be22f5e396af1bfc8db7e8fb" 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://www.primericaonline.com</saml:Issuer> 
<Status> 
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> 
</Status> 
<ns2:Assertion ID="_6abedd677697be22f5e396af1bfc8db7e8fb" IssueInstant="2016-09-03T13:07:04Z" Version="2.0" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion"> 

The Assertion ID="_6abedd677697be22f5e396af1bfc8db7e8fb" 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 you'll find: 

[The Response can not be parsed to XML document. Exception Message: The ID '_6abedd677697be22f5e396af1bfc8db7e8fb' 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. 

Resolution

In the following file:

<install-home>\CA\siteminder\config\properties\xsw.properties 

In that file, the following code shows: 

# Disables XSW checking 
DisableXSWCheck=false 

If you change 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.