Deep Link (RelayState) is not Working

Products

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

Issue/Introduction

Customer has set up CA Clarity as an SP application, allowing federated users to access it via deep link (RelayState).  When a user is already authenticated at the IDP, the application is working as expected, however, when the user is not already authenticated at the IDP the user receives an error when arriving at the application.  Customer can change the URL encoding of the initial request so that unauthenticated users would no longer receive an error, however, this was merely toggling the problem to already authenticated users.  The SP was unable to find an initial URL that works for all users.

Environment

Release : ALL

Component : SITEMINDER - FEDERATION

Cause

The IDP's authentication scheme was attempting to encode the URL in such a way that the RelayState was being altered to an invalid value during authentication.  Thus, when the user posts the assertion to the SP, the RelayState URL to which the user is redirected is invalid.  Any encoding done during authentication must be done with great care such that any query string parameter values that were submitted prior to authentication have equivalent values after authentication.

Resolution

Since the IDP did not have the ability to alter or use a different auth scheme, the SP decided to work around the problem by switching from IDP-initiated to SP-initiated and include 'ForceAuthn=yes' in the request.  This forces all users to pass through the IDP's authentication scheme and thus allows the SP to configure an initial URL that works for all users, regardless of their authentication status.  For the SP to make this change, they only needed to update the URL that users were clicking to access the application to something like the following:

https://clarity-host.com/affwebservices/public/saml2authnrequest?ProviderID=xxxxx&RelayState=https%3A%2F%2Frelaystate.com%2Fabc%2F123&ForceAuthn=yes

Additional Information

Since the IDP in this case was also running Siteminder, another effective solution to this would have been for the IDP to protect the IDP-initiated URL with an equivalent auth scheme that omits the encoding.  For instance, they would create a new Siteminder realm that protects the following:

/affwebservices/public/saml2sso?SPID=XXXXXXX

Assign an appropriate auth scheme to the realm (here the IDP could make a copy of the customized HTML login form and remove the encoding functionality from it, creating a new auth scheme with this file as the Target).  This would assure any unauthenticated users who request this federation application pass through this non-encoding auth scheme rather than the auth scheme protecting the Authentication URL that has been assigned to the partnership.  

The high-level behavior of the saml2sso URL is simple.  If the user is already authenticated, saml2sso will process the request.  If the user is not already authenticated, saml2sso will determine which partnership the unauthenticated user is requesting and redirect the user to the configured Authentication URL.