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'][][][][][][][][]
Release : 12.8.04
Component : SiteMinder Federation
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.
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.
What discovered later is that:
There are two access gateways (12.8.0400.2278) involved in the setup.
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."
DE540226