ID-WSF SOAP Authentication and SingleSignOnService Spec

The Authentication Service spec is probably the most abstract of the ID-WSF documents, but is fairly important in the context of Shibboleth. It contains three separate service specs that are only indirectly related. They share a document mostly for historical reasons.

The last of the three is a very specialized service for Identity Mapping. It's a generalization of a somewhat obscure SAML 2.0 feature that allows services to map identities across different domains and formats using an !IdP as a translator. It's used in WSF primarily to assist in cases where users access services belonging to other users, which is referred to as a "cross-principal" access.

The other two services are complex, but the best way to understand them is to cut through the details and boil them down into philosophy and purpose. Fundamentally they're both authentication services.

SASL => WSF

The first one, actually called the SOAP Authentication Service, is an adaptation of SASL, an IETF framework for pluggable authentication, into a SOAP-based service. Using SASL request/response messages and any existing or future SASL mechanism, the client can negotiate an authenticated session with the server and at the end of the process the server can return security credentials as a result, such as a reference to the user's LibertyWSFDiscovery service. In other words, the framework is SASL, and the result is usually what's referred to in Liberty as a "bootstrap" EndpointReference .

WSF => SAML

The second one is called the SingleSignOnService (SSOS) and is SAML-based. The SSOS is actually two separate SAML profiles. One is an adaptation of a SAML 2.0 profile for web SSO that is designed for use by richer clients, formally combined with the LibertyWSFSOAPBinding and LibertyWSFSecurity specs to provide an interoperable means of user authentication for that SAML profile. It applies to scenarios in which the SP in question supports the vanilla SAML SSO profile.

The other profile is referred to as a "SAML Token Service". Simply put, it's a SOAP-based SAML !IdP service that returns customized assertions to authenticated clients. As with the other profile, the LibertyWSFSOAPBinding and LibertyWSFSecurity specs are used as the basis of the protocol, and the client can use any supported authentication mechanism defined in them. In other words, the framework here is ID-WSF (and WS-Security in a sense), and the result is always a SAML assertion issued for some service.

Relevance to Shibboleth

Without ruling out potential uses, the primary pieces here are the SingleSignOnService profiles because they align with the components already planned or under construction. And as noted in the LibertyWSFSOAPBinding topic, the SAML Token Service idea was originally conceived as a future direction for Shibboleth.

Internet2 contributed the technical design for it to ID-WSF, and in fact the overall idea was actually used to design the SAML 2.0 AuthnRequest message and protocol originally in order to support this use case. This is in some sense the result of several years of design in various venues. It doesn't live up to that billing, but it's a useful piece.

%COMMENT%