This is a replacement for the ShibPortals topic, which delved into an obsolete draft document I worked on to try and understand the technical requirements for applying SAML 2.0 to portals, meta-search, web services, and other multi-tier use cases. The general problem space is one of web services (thus the topic change), although a lot of the basic pieces should be applicable in some fashion to other kinds of applications in the future.

But initially, the priority seems to be how to extend the "Shibboleth model" into a web services environment. At this stage, the Shibboleth model is for all intents and purposes SAML V2.0. Right now, SAML V2.0 does NOT include profiles that provide complete authentication solutions for SOAP. Neither does Shibboleth, in either its current (1.3) or next (2.0) version, provide any support for this. If that's why you're here, you can stop reading unless you're interested in reading about possibly future directions.

I define web services as SOAP, period. The name is lousy (SOAP has nothing to do with the web), but it's the industry term, so readers can make whatever internal adjustments they find appropriate. Note that non-SOAP services, such as the so-called "REST" model, lack any inherent ability to support new security models other than at the HTTP layer. That's the most important difference. REST assumes security is a non-factor, or that HTTP can handle it. If either is true for your application, you don't really need SAML anyway.

That said, focusing on SOAP, the user's client itself may be SOAP-capable, servers may be interacting directly, or a traditional browser client may be invoking a service that is invoking SOAP services on behalf of the user. I believe that this set of possibilities adapts itself to model most of the use cases in the general space of portals and meta-search, as well as the kinds of use cases directly addressed by the Liberty ID-WSF 2.0 specs.

As I see it, there are four basic components to a solution here, aside from SAML 2.0 itself and all the underlying functionality that's already somewhat understood. This glosses over a lot of the details, but I'm considering issues like NameIdentifiers and attributes to be out of scope. They're the data being carried, but they should compose with the new mechanisms in whatever manner is appropriate for the privacy and security necessary for the application in question.

The original draft identified these four solution components:

Modeling SAML assertions that reflect "on behalf of" security semantics
Integrating requests for such assertions with web SSO
"Stand-alone" token service for obtaining assertions outside of web SSO
Application profile for use of assertions to secure SOAP calls

Of these four, all but the second are addressed by portions of the Liberty ID-WSF 2.0 specs (as outlined below). ID-WSF also adds significant pieces that may become important in the future, such as service discovery, which I ignored. The second requirement is not explicitly addressed in ID-WSF, but can be implemented with a small SAML 2.0 extension profile if it's needed.

I don't believe that the additional complexity due to the generality of these specs justifies spending project resources implementing proprietary approaches that may be slightly simpler but are still highly complex relative to the usual fall-back solutions. If it's justifiable to do something as complex as what I originally proposed, the added benefit of a commercial standard is worth a small increase in work.

To help in understanding how the ID-WSF specs map to the solution components above, I suggest referring to the following, and the LibertyWSFRoadmap:

Modeling Delegation

When services access other services on behalf of users, or other services, it's important to reflect the "presence" of both actors in the invocation. The LibertyWSFSecurity specs include a technique for expressing this in SAML V2.0 using the SubjectConfirmation element.

This technique has been "blessed" as being consistent with the SAML V2.0 Core specification in an errata that rewrites some of the language around the SubjectConfirmation element and the use of an embedded identifier. This avoids the need for communities to define their own syntax for expressing this.

SOAP Application Profile

The LibertyWSFSOAPBinding and LibertyWSFSecurity specs define a SOAP application profile. It's fairly extensive, but the core requirements are fairly simple. It doesn't constrain the use of WS-Security as much as I'd like, but that can be tightened up for particular applications.

SAML Token Service

The LibertyWSFAuthentication spec includes a SAML V2.0 profile that is referred to as a "token service". It was developed by me (Main.ScottCantor) and adapted to ID-WSF requirements, which also serves to tighten up the profile and provides more specifics on how to use it.

The token service is important to enable services to trade in old assertions for new ones, which is important when preserving privacy using pairwise NameIdentifiers or encrypted attributes. It's also important when not relying on LibertyWSFDiscovery to obtain assertions during the process of locating services.

Use Cases / Examples

As use cases are developed, they'll be compiled here along with examples on how they can be addressed with industry standards.

$ MetaSearch: Applications involving intermediary search services.
$ PerfSONAR: Network Monitoring Data Exchange projects.