The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
LibertyWSFSOAPBinding
SAML 2.0 has something called the "SAML SOAP Binding", which often gets confused with things like the WS-Security SAML Token Profile, which one might describe as a standard for "binding SAML to SOAP", but is really a different thing entirely. The SOAP Binding in SAML is a set of rules for using SOAP to carry SAML protocol messages in the SOAP body. Because the SAML protocol is supposed to work outside of SOAP, there are a lot of things inside the SAML messages related to message identification, timestamps, etc.
The Liberty SOAP Binding is similar to the SAML SOAP Binding, but it's much more general because it isn't tied to a single kind of application protocol, and it doesn't rely on the application to carry a lot of the data. Instead it defines SOAP Headers (or references other standards like WS-Addressing) for carrying important information.
All of the ID-WSF services are defined on top of this layer, so it's common to all of the other specs, which makes it a good starting point. The other important feature is that it's designed to work together with the LibertyWSFSecurity spec, which means applications that conform to the SOAP Binding can support all the options in that spec, including using SAML assertions to secure the messages, transiting multiple servers, etc.
Highlights
Most of the SOAP Binding amounts to a bunch of SOAP Header blocks and some rules for which are mandatory and which are optional. Basically, if you follow those rules, your message conforms to the spec, so it's not very complicated (though supporting some of the Headers themselves can be). Section 5.11 of the spec is where the rules for what's required are spelled out.
Most of the basic Header blocks come directly from the WS-Addressing spec. One interesting requirement is that you always include a <wsse:Security> header (the one that carries WS-Security information, signatures, SAML tokens, etc.), if only to include a timestamp for the message.
Some other interesting headers of note:
$ <CredentialsContext> : A SOAP service can use this in an "Access Denied" fault response to tell the client that it needs to supply some other kind of security credentials to access the service, and can even tell it what mechanism it has to use.
$ <EndpointUpdate> : This is an interesting and powerful Header. You can use it "redirect" the client to some other location, but you can also use it to "replace" the security credentials that the client used originally with something new. This is analagous to dropping a cookie in a browser. You might initially rely on a strong mechanism like a signed SAML assertion, but then switch to something more lightweight to improve performance across subsequent calls.
There's a lot of cool stuff in here, actually, it's well worth reading.
Shibboleth Project Relevance
There's an obvious factor here and a non-obvious one. The obvious one is that right now if you want to do SOAP applications and use SAML assertions with them, there is nothing else to start with. When we started looking at the problem, one of the mini-profiles was labeled "SOAP Application Profile". This is a (much richer) version of that, but goes beyond just security.
The non-obvious factor is related to the LibertyWSFAuthentication spec, mainly the SingleSignOnService profiles in it. Another one of those mini-profiles was this thing called a "SAML Token Service", where you could use a SOAP-based protocol to get SAML assertions, possibly using existing assertions as input instead of a password or something like that. Service authentication, essentially.
Well, take the SAML protocol, replace the SAML SOAP Binding with the WSF SOAP Binding, and voila, a SOAP-based SAML Token Service that supports SAML assertions (or anything else) as authentication credentials.
%COMMENT%