search cancel

Siteminder encoding issue


Article ID: 201492


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER



We're running a Web Agent and when url has already %5E character, then the
backend server application receives it double encoded as %255E. To
illustrate :

  The Web Agent receives the URL :^ItemNumber/

  and the Web Agent sends it as

How can we fix that ?





  Web Agent 12.52SP1CR07 64bit on Apache 2.2.34 64bit on RedHat 6;
  Policy Server 12.52SP1CR00 on RedHat 6;




You shouldn't use caret ^ character in URL as this is unsafe character :

  Uniform Resource Locators (URL)

   In most URL schemes, the sequences of characters in different parts
   of a URL are used to represent sequences of octets used in Internet
   protocols. For example, in the ftp scheme, the host name, directory
   name and file names are such sequences of octets, represented by
   parts of the URL.  Within those parts, an octet may be represented by

   the chararacter which has that octet as its code within the US-ASCII
   [20] coded character set.

   In addition, octets may be encoded by a character triplet consisting
   of the character "%" followed by the two hexadecimal digits (from
   "0123456789ABCDEF") which forming the hexadecimal value of the octet.
   (The characters "abcdef" may also be used in hexadecimal encodings.)
   The character "%" is unsafe because it is used for
   encodings of other characters.

   Other characters are unsafe because
   gateways and other transport agents are known to sometimes modify
   such characters. These characters are "{", "}", "|", "\", "^", "~",
   "[", "]", and "`".

   All unsafe characters must always be encoded within a URL.,the%20octet%20must%20be%20encoded.

So the application should encode it first to %5E.


The first request is sent correctly with myapplicationpage%5EItemNumber
encoded as the RFC requests :

Line 3 :


  HTTP/1.1 302 Found
  Date: Fri, 18 Sep 2020 10:59:55 GMT
and the Web Agent keeps that encoding in the TARGET value :
  TARGET=-SM- [...] myapplicationpage-%5EItemNumber
Line 4 :


  HTTP/1.1 200 OK
  Date: Fri, 18 Sep 2020 10:59:56 GMT
  Server: Apache

  Welcome to Our Page 

But when POSTing, the mycustomlogin.fcc sends the value double encoded :

  target=https [...] myapplicationpage%255EItemNumber [...]

So the code of the mycustomlogin.fcc should be reviewed in order to
not double encode that character.




Correct the Custom Authentication Scheme in order to not double encode
characters :


to solve the issue.