Sending SOAP messages in OpenSAML v3

Brent Putman putmanb at georgetown.edu
Mon May 2 13:53:04 EDT 2016



On 5/1/16 2:31 PM, Stefan Rasmusson wrote:
>
> On Sat, Apr 30, 2016 at 8:28 PM, Brent Putman <putmanb at georgetown.edu
> <mailto:putmanb at georgetown.edu>> wrote:
>
>     There's probably a slight bit of more work to do there, as many
>     of the inbound handlers like this one would require things to be
>     populated in the inbound MessageContext, like a
>     SignatureValidationParameters with a TrustEngine, etc.  That sort
>     of thing is likely a bit different on the server- vs client-side,
>     because of the environmental differences, and is one of the
>     things I'm working on right now.  The existing server-side code
>     is implemented as a ProfileAction processing a
>     ProfileRequestContext, which doesn't work for the SOAP client case.
>
>
> Ok, so the SAML context has to be manually populated for the handlers?

If you meant MessageContext, yes.  (There are many "SAML-" contexts.)
The general model is the (in this case inbound) MessageContext must be
populated early on with data that is required before the other relevant
message handlers run.  Typically this means that you will have
MessageHandlers (or as in the IdP, ProfileActions) which run early,
before the "real" message handlers like the signature validation one,
and populate various subcontexts with data.

Looking at the SAMLProtocolMessageXMLSignatureSecurityHandler, it needs:

- SAMLPeerEntityContext: populated with the SAML role QName (the
entityID is usually resolved automatically)

- SAMLProtocolContext: populated with the SAML protocol URI

- SecurityParametersContext: populated with a
SignatureValidationParameters containing at least the TrustEngine


So for the SOAP client you need a MessageHandler that does that.  For
the IdP, the official one will based on injected lookup functions,
which reference IdP configuration, and implicitly SAML metadata.  Your
use case is probably different, so don't know how/where you'd get the
required data.  But the layer of abstraction is the MessageContext
subcontext data - it doesn't matter how the data gets there, only that
it is present.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160502/cf9514de/attachment-0001.html>


More information about the dev mailing list