Loss of encoding RelayState value after authentication as relying party
search cancel

Loss of encoding RelayState value after authentication as relying party

book

Article ID: 374522

calendar_today

Updated On:

Products

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

Issue/Introduction


Running Web Agent Option Pack, this one doesn't preserve the encoded character from the RelayState value.

The RelayState value has a SAMLRequest as URI.

 

Cause


When the Federation Service redirect the browser to the target, it takes it from the SMFED_TEMPORARY_STATE, and its URL-decodes it to make the URL used by the browser.

The problem is not with the decoding process. The issue is that there's already an URL-encoded value embedded before URL-encoding the RelayState value.

The SAMLRequest value should be first URL-encoded, before being inserted in the RelayState value. That is ok from the flow.

But after that, the URL-encoding process of the entire RelayState value should URL-encode again the already URL-encoded characters from the SAMLRequest value.

This is not the case in the flow.

  • Sending the following request from a browser to test, it contains a query with encoded parameters since in fact it is a SAML request:

    https://server.example.com/app/requests?SAMLRequest=fZJ...&RelayState=H4s [...omitted for brevity...] adas

  • This request is intercepted to craft a request targeting CA Siteminder Federation Service, query is still encoded:

    https://otherserver.example.net/affwebservices/public/saml2authnrequest?ProviderID=https%3A%2F%2Fhost&RelayState=HTTPS%3A%2F%2Fserver.example.com%2Fapp%2Fexternals%3FSAMLRequest%3DfZJbT8MgGIbv%2FRUN97SFdQfJWrNoTIwzJla98MbQghtJOchHN%2FX ... nR0...%26RelayState%3dH4s ... adas

So, above, the craft is not completely done:

  https://server.example.com/app/requests?SAMLRequest=

  becomes

  HTTPS%3A%2F%2Fserver.example.com%2Fapp%2Frequests%3FSAMLRequest%3D

and that's ok.

But the SAMLRequest value keeps being the same:

  fZJbT8MgGIbv%2FRUN97SFdQfJWrNoTIwzJla98MbQghtJOchHN%2F [...omitted for brevity...]

  keeps being

  fZJbT8MgGIbv%2FRUN97SFdQfJWrNoTIwzJla98MbQghtJOchHN%2F [...omitted for brevity...]

The process to URL-encode the RelayState value should URL-encode again the %2F, so, the value will be  

  fZJbT8MgGIbv%252FRUN97SFdQfJWrNoTIwzJla98MbQghtJOchHN%252F [...omitted for brevity...]

So, when this value gets URL-decoded just before the redirection, the SAMLRequest original value  

  fZJbT8MgGIbv%2FRUN97SFdQfJWrNoTIwzJla98MbQghtJOchHN%2F [...omitted for brevity...]

Will be kept, and thus consumed by the Federation Service.

 

Resolution


To solve this issue, when setting the RelayState value, encode again all the already encoded characters.

  %2F should be %252F
  %2B should be %252B