Shibboleth Developers

["Scott Cantor" <>]

> Agreed.  The intent is to leverage previously issued assertions for
> the purposes of access control.  A SAML authentication assertion
> contains useful information a Grid SP can use for authorization.  A
> SAML V2.0 authentication response, in particular, contains an authn
> context that would be *very* useful.

You can already get at that now. Your requirement has to do with reuse or
forwarding, not consumption, and that's very different and has many other
important limitations, especially in SAML 1.1 where there's no encryption
and the assertion expires in minutes.

> So a Grid SP uses a forwarded authentication assertion for access
> control purposes only (authentication to the Grid SP is based on
> X.509).  To emphasize this fact, the authentication assertion might be
> nested inside an attribute assertion, something like this:

If that assertion is expired, and/or issued with an AudienceRestriction that
doesn't include me, what would I do with it? I don't really like profiles
that amount to "yeah, the assertion's invalid, but use it anyway".

> I've read the SAML V2.0 bits re IdP Proxying but I don't see a
> conflict.  Can you elaborate where it falls down?

2.0 proxying never forwards assertions, it builds new ones by translating
information from the original. The assumption is that the relying party
doesn't trust the original IdP, otherwise it would have used it directly.

I'm not saying your use case is invalid, just that it doesn't match.

> I think the IdP Proxy use case benefits from nested assertions in the
> same way the Grid SP does.  A nested assertion is asserted by some IdP
> further back in the chain.  The more distance between the consumer and
> the producer in the chain, the deeper the nesting.

There are privacy concerns when you do that, as well as assumptions about
validity as in SAML 1.1, and the ability to verify the signatures.

Given encryption, I'm not sure that adequate consideration was given to
modifying the ID-FF proxy profile to permit forwarding as long as the NameID
was encrypted, but the AudienceRestriction rules for SSO would kill you
anyway.

-- Scott