Shibboleth Developers

["Scott Cantor" <>]

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

The formal term is IdP proxying, but attributes have never been part of that
picture (for the obvious reason that it's much more complicated unless you
just relay them along as if they were issued by the proxy).

> Can we assume that ePPN is used as a globally unique, persistent
> principal identifier throughout?

If you're talking about it as the subject, somebody would have to actually
define that. There's a reason that nobody has spent much time worrying about
defining global naming formats...they simply don't apply to the general
problem space.

> 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)?

In the short term, I think you should reissue the information at the proxy.
This is  I think people are already doing this sort of thing. You could even
hack on the IdP to do secondary queries out the back end as a DataConnector
or something.

I don't know how many ways the SP would break if you actually tried to ship
a signed assertion from the original IdP along. I know it would fail, but I
don't know how badly, or if it might work after some changes but
unintentionally because other holes might exist in some of the checks.
There's certainly no policy support for it, and you definitely have to
deliver them all at once in one response, whether it's push or pull.

-- Scott

<<attachment: winmail.dat>>