Shibboleth Developers

["Scott Cantor" <>]

The n-tier use case is a long-standing problem and it's very difficult to
pin it down to a specific set of requirements or standardize it because it's
so complex and wide-ranging. In my experience, a combination of factors
generally leads to the problem being put off. It's hard. It's even harder to
scope. Most solutions only solve specific scenarios, and people want "the
one true profile". Etc.

> The use case goes something like this:  a student is using a metasearch
> engine (a service that sends searches to several database service at the
> same time) to conduct a broadcast search across a variety of SPs.  From
> the student browser's perspective the metasearch engine is an SP and
> attributes from the student's IdP are presented to the metasearch engine.

J-Stor, among others, raised the metasearch use case a couple of years ago.

> To the destination SPs (receiving the broadcast search), the metasearch
> engine appears as a browser.  (For the sake of this discussion, the
> interaction between the metasearch engine and the destination SP could
> be one of HTML-scraping result sets or a more sophisticated dialog.)

It's important to identify whether the intermediary acts as client or as
authority. Today, most use cases are internal, and the intermediary is
simply an authority. That is, it's trusted to make assertions about the
client, and the client doesn't control it or constrain it. The assertions
aren't usually SAML, of course, but they could be. The information provided
by the original IdP is simply re-asserted to the SP by the intermediary and
it's trusted, just as the IdP is trusted by the intermediary. There's very
little to specify here because the security is isolated hop by hop.

> So, another way to ask the core I think is this:  "does the metasearch
> engine, acting as an SP, have enough information to turn around an act
> as if it were an IdP to the destination SPs?"

This, as I said, is the easy case, because the IdP is the authority. If the
engine is trusted to do this, it makes up whatever it wants, presumably
based on what it received. In this use case, full trust to identify the
client is placed in it by the actual SPs. The client is somewhat incidental,
since the intermediary could unilaterally make requests as any client at its
discretion at any time.

In the new world order, this isn't so nice, and what you really want is the
intermediary to be a delegate of the client, constrained by the IdP. It must
really act as a client, and obtain tokens from the IdP that reflect the
situation, possibly even the delegation itself so the SP knows both
identities are involved.

For one spec, Liberty ID-WSF deals with this use case, given the assumption
that the back-end exchange is SOAP. It bootstraps itself with SAML, but then
plays some arguably fishy games using an all powerful discovery service to
exchange the original assertion for a new one that authorizes it to access
the WSP (either as itself or on behalf of the real client).

There are still no profiles in SAML that address this use case, regardless
of the back-end protocol. The SAML 1.1 profiles are entirely ill-suited to
produce a token that makes any sense beyond the first hop. They're
short-lived (like 5 minutes) for one thing.

SAML 2.0 assertions are potentially more capable, but there are still no
profiles that specifically address this outside of Liberty, and the new WSF
specs based on SAML 2.0 aren't public yet. If you read them, you'd
understand the scope of the problem. I like them for that reason, not
specifically because they represent the best or only way to do it, but
because they give an idea of how hard it is.

The biggest question with Liberty (IMHO anyway) is that they solve most of
the tricky bits by simply putting all the intelligence (and failure points)
into the discovery/token service. The clients are basically like dumb
terminals when it comes to security. Maybe that's the right approach, but
I'm not looking forward to writing a DS.

Of course, WS-* have their ways of addressing it with WS-Trust and (from
what I can see) largely using XML REL (XrML) tokens for delegation claims.
The "token-neutral" advantage turns into fiction fast when you want richer
semantics like delegation.

Probably more than you wanted to hear on the subject.

-- Scott