[Shib-Users] HTTP methods not supported in SAML2 decoder

[Russell Beall]

Hi,

I have seen a surge of errors in our logs of the following form:

11:24:27.375 ERROR
[edu
.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:
318] - Error decoding authentication request message
org.opensaml.ws.message.decoder.MessageDecodingException: This
message deocoder only supports the HTTP GET method
at
org
.opensaml
.saml2
.binding
.decoding
.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:88)
11:24:27.376 ERROR
[edu
.internet2
.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet:
85] - Error processing profile request
edu.internet2.middleware.shibboleth.common.profile.ProfileException:
Error decoding authentication request message
at
edu
.internet2
.middleware
.shibboleth
.idp
.profile.saml2.SSOProfileHandler.decodeRequest(SSOProfileHandler.java:
319)

This error appears to occur every time a HTTP HEAD or OPTIONS method
call is made against this path:

128.125.253.76 - - [24/Mar/2009:04:06:20 -0700] "HEAD /idp/profile/
SAML2/Redirect/SSO?SAMLRequest=...

There are occurrences of HEAD or OPTIONS being made against the SAML1
SSO link, but these do not cause errors:
128.125.253.76 - - [24/Mar/2009:03:32:26 -0700] "HEAD /idp/profile/
Shibboleth/SSO?shire=

For unknown reasons, these errors hit in a large surge for a week,
during February 13-17 and then stopped. Now, starting March 14 they
have started showing up again. I think it is connected to one of our
high traffic SPs which has been slowly converting to a 2.x SP, but the
SAML seems to be encrypted, rather than just base64 encoded, and so I
can't see which SP it is coming from...

Is this just a bug that the SAML2 decoder doesn't take the other HTTP
methods even though the old decoder does?

Thanks,
Russ.

[Scott Cantor]

Russell Beall wrote on 2009-03-24:
> For unknown reasons, these errors hit in a large surge for a week,
> during February 13-17 and then stopped. Now, starting March 14 they
> have started showing up again. I think it is connected to one of our
> high traffic SPs which has been slowly converting to a 2.x SP, but the
> SAML seems to be encrypted, rather than just base64 encoded, and so I
> can't see which SP it is coming from...

It's a deflate, not base64. I think FEIDE had a page up somewhere that would
actually decode a redirect binding message.

> Is this just a bug that the SAML2 decoder doesn't take the other HTTP
> methods even though the old decoder does?

The old decoder isn't a decoder, I suspect, it's just using a query string
and isn't a SAML binding at all. The other bindings are more formalized.

I believe Chad fixed the decoders to allow for other methods in a recent
check-in, because of the WebDAV work going on there. I would have to assume
in your case that it's also some kind of non-browser client, because I don't
think anything else would do that.

-- Scott

[Brent Putman]

Scott Cantor wrote:

It's a deflate, not base64.

Actually, isn't it both?  It's DEFLATE-d, then base64 encoded, then URL-encoded, according to the bindings spec.

 I think FEIDE had a page up somewhere that would
actually decode a redirect binding message.
 
  

Yeah, their intro page is here:

http://rnd.feide.no/saml2debug

Is this just a bug that the SAML2 decoder doesn't take the other HTTP
methods even though the old decoder does?
    

Technically the SAML 2 Redirect binding requires GET, so limiting it to that method is not a bug, it's just being strict.  But as Scott notes below, recently it was decided to relax that strictness, to accomplish some work that will allow WebDAV to work.

I believe Chad fixed the decoders to allow for other methods in a recent
check-in, because of the WebDAV work going on there. I would have to assume
in your case that it's also some kind of non-browser client, because I don't
think anything else would do that.
  

Yes, that was checked in on March 2.  Should be in the next OpenSAML and IdP releases.