Intermittent 403 error on an SSO Federation with samlRequest ForceAuthn="true"
search cancel

Intermittent 403 error on an SSO Federation with samlRequest ForceAuthn="true"

book

Article ID: 247402

calendar_today

Updated On:

Products

SITEMINDER CA Single Sign On Federation (SiteMinder) CA Single Sign On Secure Proxy Server (SiteMinder)

Issue/Introduction

Users are seeing an intermittent 403 error when trying to use the Federation partnership with samlRequest ForceAuthn="true".

In this setup, SP is MS Azure, IDP is SiteMinder.  SP initiated request fails, but IDP initiated request runs fine.

ForceAuthn="true" in samlRequest, but the use case flow itself does not require Step-up Authentication,  as smsession cookie authentication level remains the same. 

In the logs, this is what is shown:

FWS trace log:

[07/05/2022][15:14:22][3192][139705115543296][e7fc3a6b-63de4479-d59b5d64-0d0fb16a-bc7366f1-9][SSO.java][getAuthnRequestData][AuthnRequest: <samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_c296a87c-526a-4a7a-a991-67a2678a82d3" Version="2.0" IssueInstant="2022-07-05T15:14:22.2786029Z" Destination="https://host.domain.com/affwebservices/public/saml2sso" ForceAuthn="true" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://assertionconsumerhost.domain.com/samlp/sso/assertionconsumer" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://....IDP</saml:Issuer></samlp:AuthnRequest>]

...

[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processRequest][logout() has been called. Session Id: s7AR7UvKuhqL9vy+6v1+6k81CYE= and the Result: 1]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processRequest][Current status of user's identity check is: 2]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processRequest][About to validate User's identity for current zone.]

....

[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][FWSBase.java][isValidSession][Attribute ID: 255 , value: AuthLevel=5]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][FWSBase.java][isValidSession][ AuthLevel value retrieved: 5]

...

[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Calling authorizeEx to invoke SAML2 assertion generator.]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Request to policy server for generating saml2 assertion/artifact based on selected profile. [CHECKPOINT = SSOSAML2_GENERATEASSERTIONORARTIFACT_REQ]]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Transient IP check: false]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Result of authorizeEx call is: 2.]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Received the assertion/artifact response based on profile selected. [CHECKPOINT = SSOSAML2_RECEIVEDASSERTION_RSP]]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Transaction with ID: ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a failed. Reason: FAILED_AUTHEX]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Denying request due to authorizeEx call failure.]
[06/29/2022][14:46:30][3192][139705113437952][ce7e971c-a6dfa2b9-da81d69f-677e2686-40a7ea21-5a][SSO.java][processAssertionGeneration][Sending 403 error]

Policy server side smtracedefault.log:

[06/29/2022][09:46:30][09:46:30.651][][][][][][1101][140585286674176][][][][][][][][][][LdapStore.cpp:1557][QueryObject][][][][][][][][][][][][][][][][][][][][][][][][][][][Querying for object 'smSessionId=s7AR7UvKuhqL9vy\+6v1\+6k81CYE\=,o=SSOSessionStore', (filter:" <n/a> ")][][][][][][][][]
[06/29/2022][09:46:30][09:46:30.651][][][][][][1101][140585286674176][][][][][][][][][][LdapStore.cpp:1895][CLdapStore][][][][][][][][][][][][][][][][][][][][][][][][][][][Trying to query an object, LDAP returned an error message: No such object, (ldap_search_s returned LDAP err=0x20][][][][][][][][]
[06/29/2022][09:46:30][09:46:30.651][][][][][][1101][140585286674176][][][][][][][][][][SmSSInLDAPStore.cpp:815][DoGetSession][][][][][][][][][][][][][][][][][][][][][][][][][][][Unable to read object 'smSessionId=s7AR7UvKuhqL9vy\+6v1\+6k81CYE\=,o=SSOSessionStore' ErrorCode='32'][][][][][][][][]

Environment

Release : 12.8.04

Component : SiteMinder Federation

Cause

Based on ForceAuthn flow use case scenario, this one does not require Step-up Authentication. The auth level remain at level 5.

Then SiteMinder should use old smsession cookie to generate assertion, however, FWS logs out old smsession, creates new smsession, but still uses old smSessionId to generate assertion.

When policy server tries to search the old smSessionId before generating assertion, it is no longer there.

That's why generating assertion failed.

Resolution

Per SAML specification, ForceAuthn is optional, customer could have switched ForceAuthn="false" from SP side in azure to avoid this problem.

When ForceAuthn="false", the code flow will be different from IDP side.

When ForceAuthn="true", the code flow can be very complicated depending upon a lot of factors.

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/configuring/partnership-federation/set-the-user-authentication-context-required-by-the-sp/how-forceauthn-works-in-different-authentication-modes.html

What discovered later is that:

There are two access gateways (12.8.0400.2278) involved in the setup.

access gateway host    does not set cookie by itself.        ACO cookiedomain not set.      Agent Config Object "accessGatewayaco"
access gateway host1  (cookieprovider)                           ACO cookiedomain not set.      Agent Config Object "accessGatewayaco1"
 
The error seems only happening if this is SP initiated request, forceAuthn=true, and using cookie provider at the same time, then problem occurs.

Broadcom engineering has concluded that Cookie Provider is not supported for federated configurations. Cookie provider will confuse the agent on which cookie to keep and which cookie to logout.

When looking at documentation, it specified that "Federation using Web Agent Option Pack or Access Gateway does not support the use of the Cookie Provider for federated configurations."  

https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/release-notes/known-issues/known-issues-for-federation.html

Additional Information

DE540226