OpenSAML user discussion

[tedzo <>]

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

----- Original Message ----
From: Brent Putman <>
To:
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.

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