OpenSAML user discussion

[Brent Putman <>]

You really shouldn't have to do anything.  I believe what's happening is
that the URL you are being sent is malformed.

I wasn't sure whether you were getting the error with HTTP-Redirect or
the Post SimpleSign binding. With Post-SimpleSign there's several bits
of data that are Base64-decoded in the rule. However, if it's
HTTP-Redirect, then that's simple, there is only 1 thing that is
Base64-encoded, and that is the 'Signature' query parameter.  That is
obtained from the HttpServletRequest like so:

protected byte[] getSignature(HttpServletRequest request) throws
SecurityPolicyException {
    String signature = request.getParameter("Signature");
    if (DatatypeHelper.isEmpty(signature)) {
        return null;
    }
    return Base64.decode(signature);
}


The HttpServletRequest getParameter() method automatically URL-decodes
the data for you.  So if a % is showing up in the data returned from
that call, then I believe it must have been malformed in the first
place, and therefore didn't URL decode successfully, leaving the literal
% sign.  That's just a guess, you should examine the raw request to see
what you are actually receiving.


On 10/5/10 3:45 PM, rangeli nepal wrote:
>  I am using HTTP-redirect binding and  able to construct AuthnRequest
> from wire.  is it advisable to check for Base64 encoding(After URL
> decode) of Signature and SigAlg before really doing Signature
> verification?
> 
> 
> 
> On Mon, Oct 4, 2010 at 8:05 PM, Brent Putman 
> <>
>  wrote:
>>
>>
>> On 10/3/10 9:41 PM, rangeli nepal wrote:
>>>
>>>
>>> Some time I see Bad Base64 input character at 11:
>>> 37(decimal)on cosole. I think this error is coming from Base64 class
>>> from encode method.
>>>
>>
>>
>> It's coming from our org.opensaml.xml.util.Base64 class, the method
>> public static byte[] decode(byte[] source, int off, int len).
>>
>> It literally means that the 11th character of the Base64 encoded data
>> that's trying to decode is not a valid Base64 character, which are: A-Z,
>> a-z, 0-9 , + and /.   The invalid character's ASCII value is decimal 37,
>> which looks to be the % sign.  So probably something in the signed data
>> has not been URL-decoded properly before being passed to the rule.
>> Perhaps the % sign is part of an invalid attempt to URL-encode
>> something, and then doesn't get correctly decoded as it should be,
>> leaving the literal % sign in place in the data.
>>
>>
>>
>> I could not understand the significance/impact of it. Does it mean
>>> signature is invalid?
>>>
>>
>>
>> I doubt it, it means that the data isn't being transported properly to
>> your system in the right format, or else there's a decoding bug
>> somewhere in our rule.  But the latter is unlikely, since this code has
>> been heavily used in Shibboleth for a couple of years now, we probably
>> would have heard about it.
>>