[OpenSAML] Unable to Decode message encoded by HTTPRedirectDeflateEncoder

552 views
Skip to first unread message

John Gonzales

unread,
Feb 5, 2011, 11:25:32 AM2/5/11
to mace-open...@internet2.edu
Hi there,

I am sending an encoded message across the wire to a Rails application I am
developing. When I try decode this message, I get the an error of
"Zlib::DataError incorrect header check". I have tried many different things
not the Rails-end of this equation, but I'm wondering if there might be
something wrong on the OpenSAML-end via the Java OpenSAML Library.

Here is my Java code that encodes the message:

HttpServletResponseAdapter responseAdapter = new
HttpServletResponseAdapter(response, false);

responseAdapter.setStatusCode(HttpServletResponse.SC_MOVED_TEMPORARILY);

SingleSignOnService ssoService = new
SingleSignOnServiceBuilder().buildObject();
ssoService.setLocation(identityProviderSSOServiceURL);

AuthnRequest authnRequest = Saml2Util.createAuthnRequest();
BasicSAMLMessageContext messageContext = new
BasicSAMLMessageContext();
messageContext.setOutboundMessage(authnRequest);
messageContext.setOutboundSAMLMessage(authnRequest);
messageContext.setOutboundMessageTransport(responseAdapter);
messageContext.setPeerEntityEndpoint(ssoService);

HTTPRedirectDeflateEncoder encoder = new
HTTPRedirectDeflateEncoder();
encoder.encode(messageContext);

On the Rails-end, all GET parameters are automatically URL-decoded. So all I
need to do is Base64 Decode, then INFLATE. Here is my code that does this
latter piece:

Zlib::Inflate.inflate(Base64.decode64(message)

message is the URL-decoded SAMLRequest GET parameter.

Fairly simple, but then again, I'm not sure if I implemented the Java-end
correctly. In any case, when my Ruby/Rails code executes, I get the error I
mentioned above. For good measure, here it is once again:

Zlib::DataError (incorrect header check):
mylib/codecs.rb:19:in `inflate'

As the stack trace reports, the error is happening while trying to inflate the
message. I've searched and tried many alternatives to get this message to
decode on the Rails-end, but nothing has worked so far. My searches are
suggesting that perhaps the message itself is corrupt, which is why I'm taking
a look at the Java-end.

I've been scratching my head for the two-hours on the Rails-end, and the past
hour on the Java-end. Needless to say, any help would be greatly appreciated!

Thanks in advance!

Chris Card

unread,
Feb 5, 2011, 11:34:17 AM2/5/11
to mace-open...@internet2.edu


> To: mace-open...@internet2.edu
> From: johnn...@gmail.com
> Date: Sat, 5 Feb 2011 11:25:32 -0500
> Subject: [OpenSAML] Unable to Decode message encoded by HTTPRedirectDeflateEncoder
Do you have to do something like
Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(Base64.decode64(message)
?
(see e.g. http://www.agileweboperations.com/how-inflate-and-deflate-data-ruby-and-php)

Chris

John Gonzales

unread,
Feb 5, 2011, 11:40:30 AM2/5/11
to mace-open...@internet2.edu, Chris Card
Wow. Thank you, Chris! I wish I would have asked sooner -- I would have saved myself 3 hours!

I thought I gave the OpenSAML API and other SAML documentation (i.e., bindings, profiles, core, etc.) a good read, but I clearly missed something. So I am very curious, should/would I have been able to pick this information up from either the two resources I just mentioned?

-jg.

Chris Card

unread,
Feb 5, 2011, 11:52:25 AM2/5/11
to mace-open...@internet2.edu
          >>> On the Rails-end, all GET parameters are automatically URL-decoded. So all I
>>> need to do is Base64 Decode, then INFLATE. Here is my code that does this
>>> latter piece:
>>>
>>> Zlib::Inflate.inflate(Base64.decode64(message)
>>>
>>> message is the URL-decoded SAMLRequest GET parameter.
>>>
>>> Fairly simple, but then again, I'm not sure if I implemented the Java-end
>>> correctly. In any case, when my Ruby/Rails code executes, I get the error I
>>> mentioned above. For good measure, here it is once again:
>>>
>>> Zlib::DataError (incorrect header check):
>>> mylib/codecs.rb:19:in `inflate'
>>>
>>Do you have to do something like
>>Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(Base64.decode64(message)
>>?
>>(see e.g. http://www.agileweboperations.com/how-inflate-and-deflate-data-ruby-and-php)

>>Chris
>Wow. Thank you, Chris! I wish I would have asked sooner -- I would have saved myself 3 hours!

>I thought I gave the OpenSAML API and other SAML documentation (i.e., bindings, profiles, core, etc.) a good read, but I clearly missed something. So I am very curious, should/would I >have been able to pick this information up from either the two resources I just mentioned?
I doubt if it says anything in the SAML docs. The only reason I knew what to look for was that I've hit the same kind of problem myself before (in C++ using Boost, rather than ruby) so
I knew you needed to give Zlib some parameter to make it not expect headers.
Chris

John Gonzales

unread,
Feb 5, 2011, 11:54:05 AM2/5/11
to mace-open...@internet2.edu, Chris Card
I just read that link you included. It seems like its completely implementation specific.

"The -Zlib::MAX_WBITS is necessary because PHP uses a raw deflate algorithm in the gzdeflate method but ruby defaults to either gzip or zlib (but NOT the raw deflate format)."

However, the Ruby documentation of the Zlib::Inflate library is pretty poor in this regard and doesn't mention this at all.

"Creates a new inflate stream for decompression. See zlib.h for details of the argument. If window_bits is nil, the default value is used. "

(Source: http://www.ruby-doc.org/stdlib/libdoc/zlib/rdoc/classes/Zlib/Inflate.html#M010147)

There's nothing more and no description of the default value that is used. Anyway, thanks again Chris!




John Gonzales

unread,
Feb 5, 2011, 11:56:31 AM2/5/11
to mace-open...@internet2.edu, Chris Card
Ah, well that makes sense then. I just sent another e-mail about it being implementation specific. And this furthers that point because Ruby's Zlib library is actually just calling the C library.

Well, thanks again! I'm glad you were around to point this out. I don't think I would have been able to find this out on my own, not in a reasonable amount of time at least.

Chris Card

unread,
Feb 5, 2011, 12:13:21 PM2/5/11
to mace-open...@internet2.edu
>>>Wow. Thank you, Chris! I wish I would have asked sooner -- I would have saved myself 3 hours!
>>>I thought I gave the OpenSAML API and other SAML documentation (i.e., bindings, profiles, core, etc.) a good read, but I clearly missed something. So I am very curious, should/would I >>>have been able to pick this information up from either the two resources I just mentioned?
>>I doubt if it says anything in the SAML docs. The only reason I knew what to look for was that I've hit the same kind of problem myself before (in C++ using Boost, rather than ruby) so
>>I knew you needed to give Zlib some parameter to make it not expect headers
>> Chris
>Ah, well that makes sense then. I just sent another e-mail about it being implementation specific. And this furthers that point because Ruby's Zlib library is actually just calling the C library.

>Well, thanks again! I'm glad you were around to point this out. I don't think I would have been able to find this out on my own, not in a reasonable amount of time at least.

Cantor, Scott E.

unread,
Feb 5, 2011, 1:09:45 PM2/5/11
to mace-open...@internet2.edu
> I thought I gave the OpenSAML API and other SAML documentation (i.e.,
> bindings, profiles, core, etc.) a good read, but I clearly missed something. So I
> am very curious, should/would I have been able to pick this information up
> from either the two resources I just mentioned?

Maybe I'm not following...obviously issues with Ruby have nothing to do with OpenSAML or SAML itself, but if you're saying that you weren't clear on the format itself, that would be an issue for the SAML bindings specification. Is there something you think wasn't clarified adequately?

-- Scott

John Gonzales

unread,
Feb 5, 2011, 1:16:15 PM2/5/11
to mace-open...@internet2.edu, Cantor, Scott E.
Hi Scott,

Thanks for the response. I'm not sure if you're able to see my responses
to the mailing list. Chris Card was able to resolve this issue for me.
It had nothing to do with OpenSAML but rather the implementation of the
ZLib C Library. By default, if you do not specify the appropriate bit
size, then it Zlib::Inflate will use either GZip or ZLib, and not the
raw DEFLATE format.

Documentation was poor on Zlib::Inflate. Chris Card was able to point
this out to me because he had experienced the same issue before.

-jg.

Cantor, Scott E.

unread,
Feb 5, 2011, 1:17:51 PM2/5/11
to John Gonzales, mace-open...@internet2.edu
> Thanks for the response. I'm not sure if you're able to see my responses
> to the mailing list. Chris Card was able to resolve this issue for me.
> It had nothing to do with OpenSAML but rather the implementation of the
> ZLib C Library. By default, if you do not specify the appropriate bit
> size, then it Zlib::Inflate will use either GZip or ZLib, and not the
> raw DEFLATE format.

Yes, I thought you were asking whether you should have been able to determine that from our (limited) documentation, and it didn't seem like that would be likely if it was a Ruby API problem.

-- Scott

Reply all
Reply to author
Forward
0 new messages