LibertyWSFSecurity

ID-WSF Security Mechanisms (SAML 2.0 Profile)

The ID-WSF Security Mechanisms work is pretty crucial to this whole value proposition because it gets at the heart of what Shibboleth is best at doing, securing applications in environments where a simple approach doesn't really scale up. If you don't need real security features over and above what you can get with simple SSL/TLS or passwords, frankly, you're better off not wasting your time here. Don't feel bad, I suspect you're in the majority.

That said, the Security spec is divided into two documents, one covering the general model and some of the simpler mechanisms that can be used, and the other profiling SAML 2.0 assertions as a security and identity mechanism. That's where most of the interesting features are.

Mechanisms

WSF defines security in terms of a set of "mechanisms" for accomplishing certain requirements when using the LibertyWSFSOAPBinding. The mechanisms are not separable from that spec, so it's essentially SOAP-specific at this point, mainly because the security information is usually expressed using WS-Security, which is also SOAP specific. But, the basic ideas should be transferrable to lots of other applications.

There are a bunch of different requirements, which you can read for yourself, but they get boiled down to these three concepts:

Peer Entity Authentication
Message Authentication
Message Authorization

The last category essentially just notes that the security credentials carried in the messages can carry information to be used to make authorization decisions, and also notes that when you use short-lived formats like SAML tends to be, the very fact that you can get an assertion can be an authorization in and of itself.

The first two categories cover how you authenticate the sender and receiver of SOAP messages, but they differ in whether they work at the level of the message or just the endpoints that are communicating (e.g. over HTTP). Only TLS (either server-only or mutual authentication) is defined for peer entity authentication. For message-level security, a number of different WSS-compatible approaches can be used, and it's easy to see how to define new ones.

At this point, WSF defines the security mechanism being used as a URI that combines a common prefix with some strings that denote the two options used for peer-entity and message authentication. It has some flaws, but it's a pretty simple concept in practice and it works well enough for now.

As an example:

$ urn:liberty:security:2006-02:TLS:SAMLV2 : Client uses a SAML 2.0 assertion containing a key and signs the message with that key. Server authenticates using TLS.

$ urn:liberty:security:2006-02:TLS:Bearer : Client uses a bearer token of some sort (could be a SAML 2.0 bearer assertion or not). Server authenticates using TLS.

$ urn:liberty:security:2003-08:ClientTLS:null : Client and server mutually authenticate using TLS, but no message-level authentication is performed.

Another interesting one:

$ urn:liberty:security:2005-11:ClientTLS:peerSAMLV2 : Client and server mutually authenticate using TLS, and client includes a SAML 2.0 assertion containing the client's TLS key in the message.

The difference between the first example and the last one is that in the last one, the client doesn't have to sign the SOAP message. The server just verifies that the key it uses for TLS is authorized for use with the assertion.

Use Cases and SAML 2.0

Hopefully some of these use cases sound familiar to some of the people we've been putting off while this work gets done:

SOAP client accesses SOAP service
User logs into web site, which accesses a SOAP service on behalf of user
User logs into web site, which accesses a SOAP service on behalf of user, then SOAP service accesses second SOAP service on behalf of user (and so on...)

The good news...all of those use cases are supported explicitly by the spec, although some of them are only supported through the use of SAML 2.0 assertions as a message security layer.

The better news in some sense is that in terms of the way the assertions work, most of this is now explicitly documented by the SAML 2.0 spec itself in errata, particularly the means of expressing when an entity is wielding an assertion on behalf of the assertion subject. That means other security specs that use SAML for non-SOAP applications should end up using SAML in the same way now for most basic uses.

Finally, it's worth noting that in many cases the information in the assertions used in ID-WSF may be encrypted. In some cases the whole assertion might be encrypted, but it's more common to just encrypt the identifier in the subject or attributes that might be included. This allows assertions containing information about users to be used by or pass through services that can use them to access other services that can decrypt the data.

Shibboleth Relevance

Hopefully this should be obvious. When we started, the only thing you could do with SAML interoperably was web single sign-on. Now there's a spec for not only using it in SOAP, but also defining how to construct the assertions themselves, to a point. And we can still carry attributes and look at different models for reusing or exchanging assertions to address different privacy requirements, none of that is precluded here.

%COMMENT%