[OpenSAML] PAOS binding
Jonathan Tellier
I am using opensaml to develop an SP that will support the ECP profile
and a client that will interact with it. I currently have a very
crude, basic client and was looking around for some Java library that
could help me create and respond to PAOS requests. I then came across
this PAOS client that used to be included in opensaml:
However, this class is not part of opensaml anymore. I've also checked
java-xmltooling and java-openws, but it's not there either.
I've though of simply using this class even though it's not part of
the project anymore, but it probably has been removed for a reason. So
what I was wondering why has it been removed? Is there some problem
with it or is it safe to use?
I'm also open to suggestions regarding the PAOS implementation on the
SP side. It would not be that hard to do by hand, but if there's
something out there that could help me, why not use it?
Thanks,
Jonathan
Scott Cantor
> SP side. It would not be that hard to do by hand, but if there's
> something out there that could help me, why not use it?
Well, the client half is here:
https://wiki.jasig.org/display/UPM31/Delegated+Authentication+Integration+Li
brary
-- Scott
Brent Putman
On 10/13/2010 12:00 PM, Jonathan Tellier wrote:
> Hello,
> I then came across
> this PAOS client that used to be included in opensaml:
>
> http://svn.middleware.georgetown.edu/view/java-opensaml2/trunk/src/org/opensaml/saml2/binding/PAOS/PAOSSynchronousClient.java?revision=688&view=markup&pathrev=756
>
> However, this class is not part of opensaml anymore. I've also checked
> java-xmltooling and java-openws, but it's not there either.
>
> I've though of simply using this class even though it's not part of
> the project anymore, but it probably has been removed for a reason. So
> what I was wondering why has it been removed? Is there some problem
> with it or is it safe to use?
>
AFAIK, it wasn't really removed, but rather never released in the first
place. It was I believe something experimental very early on in the
project that didn't make it into the 2.0. Just glancing through it,
there's other code that changed such that this class wouldn't even
compile. You could use it as inspiration to write something, but not
usable as-is. As Scott said, there's a more full-fledged client that
was done as a part of the Shibboleth delegation work. That's probably a
better starting point.
Valery Tschopp
> I'm also open to suggestions regarding the PAOS implementation on the
> SP side. It would not be that hard to do by hand, but if there's
> something out there that could help me, why not use it?
Here at SWITCH we also have implemented a Java ID-WSF ECP SSO web
service client library based on the OpenSAML library:
https://forge.switch.ch/redmine/projects/idwsfecp
Cheers,
Valery
--
SWITCH
Serving Swiss Universities
--------------------------
Valery Tschopp, Software Engineer, Middleware
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
email: valery....@switch.ch phone: +41 44 268 1544
Scott Cantor
version 2.0 ECP profile:
http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile
The main addition in this draft is support for channel bindings, which
allows the client to authenticate the web service through the IdP without
relying on what passes for authentication in the SSL world today.
I'll also be adding holder of key support in a later draft, which is
particularly useful for "SPs as clients" since they generally have keys.
This should give us something more like a Kerberos level of security instead
of passing around bearer tokens.
-- Scott
Tom Scavo
> It's probably semi-relevant that I just submitted a new proposal for a
> version 2.0 ECP profile:
>
> http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile
Scott, the documents linked on that page are password protected.
Tom
Scott Cantor
Oops, fixed. Die Kavi die.
-- Scott
Jonathan Tellier
look at those shortly.
> It's probably semi-relevant that I just submitted a new proposal for a
> version 2.0 ECP profile:
The HoK part will actually be quite relevant and useful to me actually...
Jonathan
Jonathan Tellier
I've had to put my work on the ECP SP/client on hold for a while, but
now I'm back working on it and I've got a question.
Unless I've missed something, I could not seen any way to create,
marshal and unmarshal PAOS elements, namely the paos:Request and
paos:Response. From what I could understand by looking at code and
docs, the delegated-saml-authentication client manipulates those
elements by using classes from the org.w3c.dom packages. As for the
SWITCH client, I might be wrong but it does not seem to create the
paos:Response xml element. From my understanding, it sends the correct
message, but without that header. As for the paos:Request, since it's
simply stripped from the message, there's no need for fancy
manipulation code.
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.
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.
Thanks,
Jonathan
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
Jonathan Tellier
> 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
Tom Scavo
>
> One thing to note is that PAOS is not part of the SAML spec, it's part
> of the Liberty suite of specs.
Hmm, PAOS *is* a SAML V2.0 binding so I must be missing something...
Tom
Brent Putman
True, yes there is a PAOS binding specified in SAML 2. However, it's
really just an "extension" of the Liberty PAOS binding, and just scopes
down some details and variability allowed by the parent Liberty one.
Most or all the really important info defining the binding is in the
Liberty spec. And in particular, all the XML schema is defined in the
Liberty spec and defined in a Liberty namespace, which is really what my
comment was about.
Jonathan Tellier
Just a quick note that might be of interest. I've realized that my
PAOS related changes to opensaml cannot all be contained inside my
SP's code tree [1]. I am therefore now directly modifying the opensaml
library. My work, which is based on v.2.4.1, is hosted on
http://gitorious.org/java-opensaml-paos
Right now, I've implemented a PAOS encoder, decoder and paos:Request handling.
Jonathan
[1] http://git.springsource.org/~jtellier/spring-security/se-security-saml-ecp
Cantor, Scott E.
> PAOS related changes to opensaml cannot all be contained inside my
> SP's code tree [1]. I am therefore now directly modifying the opensaml
> library. My work, which is based on v.2.4.1, is hosted on
> http://gitorious.org/java-opensaml-paos
I can't think of any reason you'd need to do that, so that might be a sign of a problem.
-- Scott
Jonathan Tellier
Well, here are my major reasons.
- To configure ObjectProviders. This can be achieved programatically,
but isn't cleaner to have them configured in XML files alongside the
other ObjectProviders?
- To define XML schemes.
- There's also this small thing that I corrected in this commit
regarding the HTTPSOAP11Decoder:
http://gitorious.org/java-opensaml-paos/java-opensaml-paos/commit/179353c6788e58eb3f5b696119e5c1df03cab46b.
However, if those reasons are not valid, I'd be happy to be explained
why. That would relieve me of having to maintain a separate opensaml
branch.
Jonathan
Cantor, Scott E.
>
>- To configure ObjectProviders. This can be achieved programatically,
>but isn't cleaner to have them configured in XML files alongside the
>other ObjectProviders?
I'm fairly certain you can load as many as you need with XML files (how
does openws do it for all the SOAP bits?), but no, I would say it's
cleaner to have a separate jar than not, no matter what else is involved.
I'm not saying the PAOS bits shouldn't be in the code we distribute, but
if there's some resistance to that for some reason, you would want to, for
now, have a separate jar, not a hacked opensaml jar.
>- To define XML schemes.
I don't follow. Schemas should be pluggable, I can't think how they
wouldn't be. It's just up to an entity resolver in the parser to find them.
>- There's also this small thing that I corrected in this commit
>regarding the HTTPSOAP11Decoder:
>http://gitorious.org/java-opensaml-paos/java-opensaml-paos/commit/179353c6
>788e58eb3f5b696119e5c1df03cab46b.
Bugs are bugs of course, different story.
>However, if those reasons are not valid, I'd be happy to be explained
>why. That would relieve me of having to maintain a separate opensaml
>branch.
Apart from bug fixes, I don't think they're valid. And bug-wise, I think
you can just create your own version of the decoder for now, and
Spring-inject it anyplace you need the fixed version until the official
one is fixed. At least I assume so.
I'm just hand waving, I'm only partially familiar with the Java code, but
you would certainly not have to do this with the C++ version, and it would
be rather bizarre if the Java was somehow less extensible in that regard.
-- Scott
Jonathan Tellier
> does openws do it for all the SOAP bits?), but no, I would say it's
> cleaner to have a separate jar than not, no matter what else is involved.
That's exactly what I'm trying to do: load the PAOS related
ObjectProviders by using XML file, just like it's done for the other
ObjectProviders. Now, maybe I'm missing something, but from what I've
understood, the only way opensaml can be informed about a new config
file is to modify its bootstrapping process. I know that in my
application, I could extend the DefaultBootstrap class to add a
reference to my new file, but I initially thought that it would be
better to modify the original bootstrapping process. However, since
you're suggesting otherwise, I could fall back to extending the
bootstrapping process.
In fact, one of the reasons that led me into branching opensaml is
that I though that if and when you guys would want in incorporate my
changes, it would be easier to just diff my branch with the official
one instead of looking at opensaml related changes included in my SP.
Or maybe I'm just getting used with the git way of doing things in
which branching is quite common.
Anyway, I guess it's not really harder to take the PAOS related code
in my SP and incorporate it in the official code tree...
> Bugs are bugs of course, different story.
You're totally right. I should have opened an issue on Jira from the
beginning. I've done it now.
(https://bugs.internet2.edu/jira/browse/JOST-140)
> I'm just hand waving, I'm only partially familiar with the Java code, but
> you would certainly not have to do this with the C++ version, and it would
> be rather bizarre if the Java was somehow less extensible in that regard.
OK, so since everything I'm trying to do is achievable in my SP, I'll
extend opensaml in it instead of maintaining a separate branch.
Thanks,
Jonathan
Cantor, Scott E.
> ObjectProviders by using XML file, just like it's done for the other
> ObjectProviders. Now, maybe I'm missing something, but from what I've
> understood, the only way opensaml can be informed about a new config
> file is to modify its bootstrapping process. I know that in my
> application, I could extend the DefaultBootstrap class to add a
> reference to my new file, but I initially thought that it would be
> better to modify the original bootstrapping process. However, since
> you're suggesting otherwise, I could fall back to extending the
> bootstrapping process.
That would be my impression, but Brent and Chad would know better than me.
> In fact, one of the reasons that led me into branching opensaml is
> that I though that if and when you guys would want in incorporate my
> changes, it would be easier to just diff my branch with the official
> one instead of looking at opensaml related changes included in my SP.
The object providers tend to be pretty self-contained.
> Or maybe I'm just getting used with the git way of doing things in
> which branching is quite common.
I don't understand git at all, so maybe you should ignore me.
-- Scott
Chad La Joie
On 12/17/10 12:49 PM, Cantor, Scott E. wrote:
>> That's exactly what I'm trying to do: load the PAOS related
>> ObjectProviders by using XML file, just like it's done for the other
>> ObjectProviders. Now, maybe I'm missing something, but from what I've
>> understood, the only way opensaml can be informed about a new config
>> file is to modify its bootstrapping process. I know that in my
>> application, I could extend the DefaultBootstrap class to add a
>> reference to my new file, but I initially thought that it would be
>> better to modify the original bootstrapping process. However, since
>> you're suggesting otherwise, I could fall back to extending the
>> bootstrapping process.
>
> That would be my impression, but Brent and Chad would know better than me.
The bootstrapping class for the opensaml library is for initializing
those things with come with that library. If you want to add things to
the bootstrapping process you need to extend the class.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Jonathan Tellier
I'm reviving this old discussion to inform you that my work on an SP
supporting ECP has been merged into the main Spring SP [1]. So if and
when you'll want to incorporate the things I've added to OpenSAML for
it to support the PAOS binding, you should pull it from there. It's
not much, but it's complete with unit tests.
--jtellier
[1] http://git.springsource.org/spring-security/se-security