SAML Partnership is resulting in duplicate authentication prompts
Article ID: 261495
Updated On:
Products
Issue/Introduction
Customer is using Access Gateway Federation Gateway and unauthenticated users are getting challenged twice before they're redirected to the target application. This does not occur for users who are already authenticated when they request the application. The following is seen in the FWSTrace.log:
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][processRequest][Session exists and there is no old Fed cookie. This is the first pass. Old federation session cookie SMFED_OLD_SESSION is not present. Need to challenge user.]
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][processRequest][Renaming session cookie SMSESSION. Issuing SMFED_OLD_SESSION]
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][processRequest][Setting session SMSESSION to logout state in order to produce a challenge.]
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][validateDynamicAuthentication][Dynamic Authentication is not configured]
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][processRequest][Session cookie does not exists. redirecting to authentication url [CHECKPOINT = SSOSAML2_AUTHENTICATIONURL_REDIRECT]]
[02/27/2023][21:40:42][3171][139991369336576][263ebefb-0efa5798-fd63a3b5-7e221983-0fd10b3e-523][SSO.java][getLocalServiceURL][Enter getLocalServiceURL]
Environment
Release : ALL
Cause
The cause of the unexpected extra prompt for authentication when an unauthenticated user requests an SP-initiated SAML app and ForceAuthn=True is the saml2sso URL being a protected URL in the environment where this problem occurred. Because this URL is protected, the unauthenticated user cannot access the saml2sso URL until they authenticate. Once authenticated the user may access the saml2sso URL, but because ForceAuthn=True and the user has an existing session, Siteminder believes it needs to force the user to re-authenticate prior to generating an assertion for that user.
In essence, the ForceAuthn=True use case is not compatible with a protected saml2sso URL. Do note that this only affects an unauthenticated user who requests the application and would not affect an authenticated user who will only be challenged once before an assertion is generated.
Resolution
The most obvious solution is to have the SP stop settingg ForceAuthn=True in the authn request. Depending on the sensitivity of the application, this may not be possible.
Another solution would be to not protect the saml2sso URL and thus allow unauthenticated users to access the URL. This URL will not process a request nor reveal any information to an unauthenticated user; the only action it will take for an unauthenticated user who requests a valid configuration is redirect them to the Authentication URL configured within the Partnership (user will receive a 400 error if requesting an invalid config). Thus, unprotecting this URL does not open a security hole (from the client perspective it behaves exactly like a protected URL when not protected - this URL was designed to be unprotected since protection is built into this URL's functionaliy).
It's not possible to shut off Siteminder's enforcement of ForceAuthn=True, else this would be the most obvious solution.
Feedback
