URL Encoding Issue : HTTP 400 Bad Request

[K.Anurag]

Hi All,

 

We are facing an issue recently, where upon redirect from the login page (after POST login.fcc), the CA SPS IDP authentication URL (redirect.jsp), with SAML Request in the query string has no encoding.

As a result of which the plus '+' character in SAML Request is converted into a space and it results in a Bad 400 Request.

 

This only happens after a POST from login.fcc. The target URL in login.fcc has the proper encoding.

It is only not encoded in this URL (302 issued from login.fcc),

https://SpsAuthenticationUrl/redirect.jsp?SAMLRequest=StringNotEncoded 

 

Manually replacing the '+' character with its ASCII value %2B in the same browser session results in a successful transaction.

 

Why the SAMLRequest string is not being encoded in the IDP authentication URL? Please suggest.

 

Note:

The same authentication URL has encoded SAML Request before it is redirected to the custom login page.

Login.fcc target also has proper URL encoding.

server.log:

[ERROR] - Exception while decoding base64 string: com.rsa.jsafe.JSAFE_InputException: Unexpected padding chars

[ERROR] - Inflation failed due to exception:

FWSTrace.log:

[SSO.java][doGet][Transaction with ID:  failed. Reason: BAD_SAML_REQUEST_ENCODING]

[SSO.java][doGet][The SAMLRequest parameter was not encoded properly.]
[SSO.java][doGet][Ending SAML2 Single Sign-On Service request processing with HTTP error 400]

affwebserv.log

[SSO.java][ERROR][sm-FedClient-02370] The SAMLRequest parameter was not encoded properly. ()

[SSO.java][ERROR][sm-FedClient-02890] Transaction with ID:  failed. Reason: BAD_SAML_REQUEST_ENCODING (, , )

[Manjari Gangwar-Warty]

Hello Kumar,

 

We have not seen any encoding issues with the SAMLRequest encoding. I would suggest opening a support case. Also, if there is a custom login page, please try using the OOTB login.fcc page. In the support case, please upload the fiddler trace, webagent trace, and fws trace. 

 

Thanks,

Manjari

[Lalitha Lakshmi]

Hey Anurag,

This is the issue we will face when we use a custom login page. We can fix this by handling the encoding in the custom login page. 

 

The below function should take care of the issue. We can call this function on the "TARGET" variable.

<%!
/**
* Fixes a problem with SiteMinder handling of a twice-url-encoded string
* @param str
* @return
*/
public static String fixSiteMinderEncoding(String str) {
// Fix SiteMinder target encoding strangeness

if (str.indexOf("-SM-")!=-1)
{
str = str.substring(4);
str = str.replace("-&", "%26");
str = str.replace("-+", "%2B");
str = str.replace("-%", "%25");
str = str.replace("-$", "%24");
str = str.replace("-.", ".");
str = str.replace("-/", "%2F");
str = str.replace("-:", "%3A");
str = str.replace("-;", "%3B");
str = str.replace("--", "-");
str = str.replace("-=", "%3D");
str = str.replace("-#", "%23");
str = str.replace("-?", "%3F");
str = str.replace("-\n","%0A");

}
else if (str.indexOf("$SM$")!=-1)
{
str = str.substring(4);
str = str.replace("$+", "%2B");
str = str.replace("$&", "%26");
str = str.replace("$%", "%25");
str = str.replace("$$", "%24");
str = str.replace("$.", ".");
str = str.replace("$/", "%2F");
str = str.replace("$:", "%3A");
str = str.replace("$;", "%3B");
str = str.replace("$-", "-");
str = str.replace("$=", "%3D");
str = str.replace("$#", "%23");
str = str.replace("$?", "%3F");
str = str.replace("$\n","%0A");
}

return str;

}
%>

 

Thanks,

Lalitha

[Tiago Comassetto]

Hi Lalitha,

 

I'm having the same problem with encoded SAMLRequests and I'm trying to test this function, but I didn't understand how I can call this function inside the login.fcc file? Can give an example?

 

Thanks in advance

[Mark ODonohue]

Here is link to "Idea" that would make smencode more urlencode compatable.

 

There is also sample java code for smencode/smdecode. 

 

The problems come about when the target is smencoded more than once, through redirects, and then run back through multiple smdecode through more redirects.  This often occurs in some nested situation that often happens with SAML assertions or cookie providers.   

 

Now if it is just SSO agent doing the multiple smencode/decode it - usually that is fine - but often if you have custom .jsp page in there and maybe it does a urlencode or urldecode on top of the smencode - or maybe incomplete implementation of the decode - that is where problems happen - particularly where the url is multibly encoded / decoded.

 

But the following link has sample code that does the smencode/smdecode.  

 

SMEncode method should change to be more compatible with URLDecode 

It also has my idea/plea to make smencode more urlencode comparable.

(The core problem is smencode encodes a '%' as '-%', if it encoded it as '%25' then it would interact *much* better with normal url encoding -and smdecode would not need to change)

 

Cheers - Mark