Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] PAOS binding

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] PAOS binding


Chronological Thread 
  • From: Jonathan Tellier <>
  • To:
  • Subject: Re: [OpenSAML] PAOS binding
  • Date: Wed, 1 Dec 2010 17:26:08 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RbwuUC/s5x4ze4uSAaVQDv/WIU5OT9nTsAYq6Weh2FCKacr+yZHJ4cnJXPXHfjicf0 Uvgeyae66WiPQxYi2XXVVdr7GSKrjAnt3NeiDt3HPkQQlvpfsItaVWMfSHjq9oJDyks5 QnQlZNXj5zt1NT46l0mAcxaS2eK72eunX7t6s=

> 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.

That's a really good point...

> 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.

Thanks for the pointer. I'm going to take a closer look at that
project to see how they handle ECP even though the client part is not
my major concern right now. For that, I've got other references like
the delegated-saml-authentication client and the SWITCH one. It might
nevertheless be of some use for my work on the SP part, for which ECP
implementations seem nonexistent, except for the native Shibboleth SP.

> 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.

That sounds good to me. Since I really need all of this ready and
working at around February of next year, I'll go ahead and code it up.
The SP on which I'm basing my work is the Spring one and my git branch
can be found on [1]. When it will be ready, I'll ping this mailing
list again.

Thanks,
Jonathan

[1] http://git.springsource.org/~jtellier/spring-security/se-security-saml-ecp



Archive powered by MHonArc 2.6.16.

Top of Page