Shibboleth Developers

["Scott Cantor" <>]

> Suppose IdPA pushes both an authentication assertion and an attribute
> assertion to the SP.  Assume the NemeIdentifier is a globally unique
> (persistent) principal identifier (such as ePPN or ePTID). Suppose
> further that the NameQualifier attribute is set to the providerId of
> IdPB.

You're potentially violating the rules by exposing a federated identifier
apparently issued to IdPA from IdPB in an assertion in the clear from IdPA
to some SP. When you crosswalk like that, you generally have to use XML
encryption. The idea would be for IdPA to embed an identifier it shares with
IdPB in a form that IdPB can read but the SP can't.

It doesn't take the place of the Subject identifier, but it can be
communicated in an attribute, for example. Or, more commonly as in Liberty,
it's perhaps inside a second security token embedded inside a SOAP endpoint
reference. That combines "who" and "where" with "how".

> Is there any way to force an attribute query to IdPB despite the
> fact that the SP has already consumed the attribute assertion from
> IdPA?

The SP was designed around one IdP at a time, and queries are implicit, not
something you can invoke directly (and all but gone for the basic use case
in the future I suspect). There just all kinds of places where the code
would just crash and burn, starting with the entire cache at the moment.

There are a lot of ways to do aggregation, all of them with different
privacy properties, complexity, etc. It's a project in itself. If we tried
to inject it deeply into the design now, you wouldn't see 2.0 until 2007.
The faint hope is to generalize a few bits so that the internals aren't
quite as restrictive.

But the attribute angle is the one you want. You can't hack something into
the subject without violating all kinds of expectations and it would be
wrong to try. But you can always pass attributes that can be fed into other
functionality layered on top, and you generally need the IdP's cooperation
anyway in order to cross-walk.

Fundamentally, this is just Liberty WSF, plain and simple. Multiple
providers of data or service, and you have to be able to discover them,
invoke them with proper credentials on behalf of the principal, generally
with encrypted identifiers so you can crosswalk between domains without
exposing the identifiers to the SP/WSC.

I think it would be quite sound to WSF-enable SAML queries and use that as a
test case.

-- Scott