OpenSAML user discussion

[rangeli nepal <>]

I thought http post will be easier that redirect as message is not
divided in parts ( request,relay,signature,sigalg) and they are not
deflated either. am I wrong?
rn

On Tue, Oct 5, 2010 at 4:12 PM, Brent Putman 
<>
 wrote:
> 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.
>>>
>