Shibboleth Developers

["Tom Scavo" <>]

Well, that's what I get for diving into details right off the bat. :-)
 Note to myself: Always argue from first principles.

The use case under consideration is the one you alluded to the other day:

IdP -> SP/IdP -> SP

I like that diagram a lot.  It's a simple ASCII equivalent for a more
detailed flow diagram:

https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/MyVocs

You used the word "chaining" to describe this scenario, which is a
nice way of thinking about it.

Can we assume that ePPN is used as a globally unique, persistent
principal identifier throughout?  Nate has argued that ePTID is better
suited for this purpose, and I totally agree, but that's not an option
right now.  (That ball is in your court. :)

If we can't agree to use ePPN all along the chain, then there's no
hope of progress in the short term.  Can we just sweep privacy under
the rug for the moment and see what happens? :-)

Let's make the following simplifying assumption: The terminal SP (on
the far righthand endpoint of the chain) trusts the terminal IdP (on
the far lefthand endpoint of the chain).  Thus it is conceivable that
an attribute query can occur without a whole lot of new machinery.  In
particular, this is not a delegation scenario.

So there are two sets of attributes to be had.  One set of attributes
is passed directly to the terminal SP, which is straightforward, so we
ignore them in what follows.  In addition, the terminal IdP is
prepared to assert attributes to the terminal SP.  The question is:
How does the terminal SP obtain attributes from the terminal IdP
(directly or indirectly)?

I'll stop there and see what gives. :-)

Tom

On 3/28/06, Scott Cantor 
<>
 wrote:
> > 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
>
>