OpenSAML user discussion

[Brent Putman <>]

On 12/1/10 12:10 PM, Jonathan Tellier wrote:
>
> So, since my SP needs to create and manipulate those PAOS elements, I
> was thinking that maybe the opensaml library could benefit of the
> enhancement I'll have to code anyway. What I'm thinking about is to
> create an org.open.saml2.paos and an org.open.saml2.paos package,
> modelled after the org.open.saml2.ecp and org.open.saml2.ecp.impl
> packages. In fact, my code would look a lot like what is already
> present for ECP, but instead of handling ecp:Request/Response, it
> would handle paos:Request/Response.


One thing to note is that PAOS is not part of the SAML spec, it's part
of the Liberty suite of specs.  Which means that if we did eventually
include it in OpenSAML, the package would probably be something like
org.opensaml.liberty.paos, or similar.  Just wanted to make sure you
realized that.

When we did the IdP side of the delegation work that uses the ECP
profile, we did need to use pieces from various Liberty schemas, and so
needed the relevant XMLObject providers.  But rather than writing the
code, we just reused what they had from the OpenLiberty project[1],
specifically the Wakame subproject, which has ID-WSF consumer
functionality.  It's built on top of our xmltooling library, so it works
the same way as OpenSAML.  The IdP never sees the PAOS headers
obviously, and I never noticed whether they had the PAOS schema stuff
implemented.  In looking at it just now, I can't seem to find it, so I'm
guessing probably not (but I'm not 100% familiar with the library).  The
logical place for this support to go would be there or somewhere at
OpenLiberty, I would think.  However, as far as I can tell that project
hasn't been updated in a long time, so I'm not sure what the status is. 
I believe the Wakame developer used to be on this list, so maybe he can
chime in.


> Does all of this make sense?
>
> I guess that creating a Jira issue and including my patch (once it's
> done) would be the best way to go, but I wanted to have advices from
> people who know opensaml better than I do first before blindly coding
> away.


One logistical point is that 2.4 is/was planned to be the last minor
release of OpenSAML 2.x.  Based on our stated API and versioning scheme,
we wouldn't be able to include this in OpenSAML until 3.0, which would
be coming out sometime next year, probably at least mid-year.  So it
would be awhile...

In any case, this is only a couple of schema elements, so not that long
to code up.  I'd say if you need it urgently, just go ahead and code
it.  And then if it winds up in OpenSAML or OpenLiberty eventually, all
the better.  Another option is that we might be able to host as an
extension project in our repository.

--Brent


[1]  http://openliberty.org/