[OpenSAML] HTTPRedirectDeflateEncoder/Decoder

[tedzo]

Hello,

I am trying to use opensaml-2.1 (Redirect-Post binding) and I am little lost-

 

I assumed that I could use HTTPRedirectDeflateEncoder to base64 encode and deflate the saml string and then use HTTPRedirectDeflateDecoder to undo it on the other end. However I don't see any methods to help me do this. The two useful methods - encode() and decode() takes a MessageContext as a parameter and I am not sure how to get a context. What am I missing?

 

Thanks for your time.

[Brent Putman]

tedzo wrote:

Hello,

I am trying to use opensaml-2.1 (Redirect-Post binding) and I am little lost-

 

I assumed that I could use HTTPRedirectDeflateEncoder to base64 encode and deflate the saml string and then use HTTPRedirectDeflateDecoder to undo it on the other end.

Yes, that's right, except that the encode/decode and deflate processes operate on a SAMLObject representing the SAML message in question, not a "saml string".

However I don't see any methods to help me do this. The two useful methods - encode() and decode() takes a MessageContext as a parameter and I am not sure how to get a context. What am I missing?

 

Right, the unit of operation here is a MessageContext (actually a SAMLMessageContext subclass), which holds various pieces of information that are inputs to the encoding/decoding process (all decoders/encoders, not just this one).  You create the type of context you want.  This could be a context subclass specifically for a particular profile, the idea being that your profile handler class instantiates that specific type of context and this then serves as the unit of profile processing.  But if you don't have things coded that way, there is a BasicSAMLMessageContext in java-opensaml2 you can use.

Take a look at the unit tests for those 2 encoder and decoder classes, and you should get a sense of what you need to minimally set on the MessageContext to use this encoder/decoder pair.  Those are in like-named packages under the src/test/java tree in SVN.

For the encoder basically an oubound SAML message (obviously), a peer entity Endpoint, and the outbound Transport, which will almost certainly just be adapter around your HttpServletResponse. Optionally also a signing Credential, if you want the message signed under the rules for that encoder.

For the decoder, input is just the inbound message transport, which will be an adapter around your HttpServletRequest.  Then after calling decode, various data elements on the context will be decoded and populated.

--Brent

[tedzo]

Yep, got it. Thanks for the input.

 

For some reason HttpServletRequestAdapter is not documented and that threw me off. I am using the BasicSAMLMessageContext. I couldn't figure out the exact type of message context based on the profile (you said "You create the type of context you want.  This could be a context subclass specifically for a particular profile,...."). Do you mean I can create a context for the type of profile I am interested in- Redirect-Post?

 

Thanks again

[Brent Putman]

 

For some reason HttpServletRequestAdapter is not documented and that threw me off.

Yeah, that class is actually in java-openws.  The 3 Java libs which comprise the OpenSAML stack (opensaml2, openws, xmltooling) have pretty good API docs, but depending on how you build the Javadoc they are not necessarily integrated into 1 set.  Here for example they are 3 separate Javadoc collections:

http://www.opensaml.org/docs/

I am using the BasicSAMLMessageContext. I couldn't figure out the exact type of message context based on the profile (you said "You create the type of context you want.  This could be a context subclass specifically for a particular profile,...."). Do you mean I can create a context for the type of profile I am interested in- Redirect-Post?

Well, not exactly, "Redirect-Post" isn't a profile.  HTTP-Redirect and HTTP-POST are bindings.   Profiles encompass a broader spectrum on requirements, constraints etc for a particular use case, e.g. Web SSO.  You can see the distinction if you take a look at the OASIS SAML 2 Bindings and Profiles spec docs.

One approach is to create different subclasses of SAMLMessageContext that are used for processing requests according to a particular profile - e.g SSO, AttributeQuery, Artifact resolution - and perhaps also the relevant role within that profile, e.g. IdP or SP.

If you want to see full-blown examples for some common SAML profiles, see the Shibboleth IdP project, which is built on (and drove the development of) Java OpenSAML.  Here are for example the SAML 2 IdP profile handlers:


http://svn.middleware.georgetown.edu/view/java-idp/branches/REL_2/src/main/java/edu/internet2/middleware/shibboleth/idp/profile/saml2/


The IdP, and the Shibboleth common library on which it is built, have a component/interface called a ProfileHandler, which represents the requirements for processing for a particular profile (for any supported binding).  The ProfileHandler impl classses typically have profile-specific context classes that are implemented as inner classes of the corresponding profile handlers.

You don't have to get that formal if you don't want to.  OpenSAML in fact consciously doesn't have notions of profiles, being rather a toolkit for higher level apps to use in building support for profiles.  Just using a BasicSAMLMessageContext is fine.  Or you can extend it to conform to your own processing model, ala the Shib profile handlers.


--Brent

[tedzo]

Thank you for the pointers and your time. Greatly appreciated.

----- Original Message ----
From: Brent Putman <put...@georgetown.edu>
To: mace-open...@internet2.edu
Sent: Wednesday, August 27, 2008 7:04:27 PM
Subject: Re: [OpenSAML] HTTPRedirectDeflateEncoder/Decoder

 

For some reason HttpServletRequestAdapter is not documented and that threw me off.