OpenSAML user discussion

[Brent Putman <>]

On 1/20/10 6:12 PM, Tom Delorenzi wrote:
> What I cannot figure out is how to use the Soap objects in saml to build an 
> assertion
> using this artifact. I need to build a soap message and send it to a server 
> using http.
>   

Yes, what you essentially would want is an "artifact resolver"
component, that takes an Artifact object or the Base64-encoded
representation of the artifact, and resolves it into the Assertion (for
SAML 1 artifacts) or the protocol message (for SAML 2 artifacts). 
Unfortunately we don't currently have such a component in OpenSAML.  We
have intentions to, but we were hampered for a long time by not having a
working SOAP client.  We have a simple SOAP client now, but the artifact
resolver component is still on the todo list.


> I read that there is no soap output client built in but I can easily dump 
> the formatted
> text into a connection of my own. I looked at SOAP11Encoder but it needs a 
> context. 
> I looked at BasicSoapContext but I didn't see any way to put my artifact in 
> there.
> I looked at various XMLHelper\builder objects but none that I saw took an
> artifact(or its parent) to generate something usefull.
>   

To resolve the artifact yourself, what you essentially need to do is
this (and here's hoping I'm not forgetting some crucial step):

1) Process the artifact SourceID to determine the IdP endpoint (assuming
SAML 1 artifacts here, SAML 2 could be either direction)  to which to
send the artifact resolution message.  For this we don't have anything
at all that would help you directly at the moment.  SourceID's are often
just a SHA-1 digest of the entityID, but I believe that's a
recommendation, not a requirement.  As the spec says, the IdP's and SP's
generally exchange this information out-of-band in some fashion (e.g.
SAML metadata).  For example, you might process the metadata and build
up an index where the key is the SHA-1 digest of the entityID.

2) Construct the artifact resolution message.  Assuming you're using the
SAML SOAP binding: This is pretty easy, just use the standard OpenSAML
object provider support to construct a SAML 1 protocol Request object
containing an AssertionArtifact.  The latter contains the Base64
representation of the artifact.  This is then encapsulated in the Body
of a SOAP 1.1 Envelope.

3) Send the SOAP Envelope and process the result.  We have a working
simple SOAP client that works now, based on Apache HttpClient, but it's
not documented at all currently other than some Javadocs, nor do we have
any example code, unit tests, etc.  Chad might have some pointers to
real usage examples, since he wrote it for SWITCH to use in some of
their work. 

In the meantime: I had some SOAP client code that I was using for
testing something recently, so I spent a few minutes and worked it into
something that might be useful to people as a skeletal example.  It may
be a little rough, I can't really test it b/c I don't have a responder,
but the starting version was working at least.  Error reports and
improvements are welcome.  It's now in the wiki user's manual here:

https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManJavaSOAPClientExample

As you can see, it specifically illustrates the SAML 1 artifact
resolution case about which you are asking.



> If anyone can point me in the right direction that would be great.
> The only other way I can think of going is just getting a seperate soap
> client and manually building my tags in it.

That's certainly fine too.  Our SOAP client is very simple, and doesn't
directly handle advanced cases, like message level signature (e.g.
WS-Security).  You could code that yourself too pretty easily, but if
you have a SOAP client you like, that certainly might be a better way to go.

Actually, you didn't mention what sort of security requirements the IdP
imposes for authentication the sender of the resolution message.  The
example above assumes client TLS, which is what we typically use by
default in Shibboleth.



>  The only thing that
> feels redundant about that is I will have (say spring) decode the
> message and then I have to pull out the saml payload and put it back
> into saml to have saml parse it and build saml objects.
>   

Yeah, true, but with these SOAP stacks and pluggable modules and their
different ways of handling XML, that's generally true a lot.  If one lib
assumes a DOM structure (e.g. OpenSAML and anything based off of Apache
XML Security), and another part doesn't (e.g. Axis2, with Axiom's
default impl), they you are doing some conversion and re-parsing, unless
special allowances are made for it, e.g. Axiom's DOOM impl.  Welcome to
XML land.  :-)


Hope that helps,
Brent