[OpenSAML] Bad Base64 input character at

[rangeli nepal]

Greetings Everybody,

Currently for both HTTP-redirect binding and Http Post bnding I use
BaseSAMLSimpleSignatureSecurityPolicyRule for signature verification
( evaluate ( BasicSAMLMessageContex) )

I build signatureRule ( instance of
BaseSAMLSimpleSignatureSecurityPolicyRule) as shown below: It works
most of the time. 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.
I could not understand the significance/impact of it. Does it mean
signature is invalid?

Any light on this topic will be highly appreciated.
Thank you.
rn

.........

BaseSAMLSimpleSignatureSecurityPolicyRule signatureRule;

MetadataCredentialResolver mdCredResolver = new
MetadataCredentialResolver(pMetaDataProvider.getFilesystemMetadataProvider());
KeyInfoCredentialResolver keyInfoCredResolver =
Configuration.getGlobalSecurityConfiguration().getDefaultKeyInfoCredentialResolver();
signatureTrustEngine = new
ExplicitKeySignatureTrustEngine(mdCredResolver, keyInfoCredResolver);
if(postORget==true){
signatureRule=new
SAML2HTTPRedirectDeflateSignatureRule(this.getSignatureTrustEngine());
}else{
parser=new BasicParserPool();
signatureRule=new
SAML2HTTPPostSimpleSignRule(this.getSignatureTrustEngine(),parser,keyInfoCredResolver);
}

[Brent Putman]

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.

[rangeli nepal]

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?

[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.

[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

[Brent Putman]

On 10/5/10 5:31 PM, rangeli nepal wrote:
> I thought http post will be easier that redirect

I'm not sure what you mean by "easier". In any case, you have to
process what you are sent by the sender. If they use the redirect
binding, you have to use the redirect rule. If they use the post
binding, you use the post rule. No ambiguity.

Those particular rules do have logic to detect whether they should
attempt to run, based on the HTTP method, and bail out if the method is
not appropriate to the rule.

> as message is not
> divided in parts ( request,relay,signature,sigalg)

Actually HTTP-Post SimpleSign has all of those parameters (as form
params, not query paramrs) and as well as an additional one for key
material that redirect does not have.

> and they are not
> deflated either. am I wrong?

Correct, in HTTP-Post, it's not deflated.

If you are using the OpenSAML decoders, you shouldn't have to worry
about any of that, though. They take care of all of that for you. The
security rules do also - you just use them, you don't have to worry
about those implementation details.

--Brent