Shibboleth Developers

["Scott Cantor" <>]

> The lowest common denominator in the various GridShib use cases is the
> attribute assertion.  Let me give a typical use case:

The game I was talking about was HTTP server trickery to get the information
to the app. In a non-web case, the app is the one doing the query, so it
should be able to get back what it needs, likely in Java land where it's
relatively painless to use.

Below, you're talking about a different question, which is more a profile
issue.

> If the gateway queries for attributes, all it has access to is an
> attribute assertion.  If the authn context were embedded in the
> attribute assertion (which makes conceptual sense since that context
> is to be used for access control) then all is well.  Today, the best
> we can hope for is to *require* Shib attribute push or artifact, in
> which case the authn assertion is exposed, but we'd rather not require
> such a workaround.

Except in the limited case where somebody queries on their own behalf (and
thus "authenticates" to the AA), I see no justification for including an
authn context here. Server queries do not presume user authentication has
even happened.

In a Liberty-enabled query, you could have the gateway use an assertion
based on the original SSO assertion to make the query "on behalf of" the
user. Then you could imagine getting back authn data along with the
attributes. But not without WSF security semantics and a lot of new code.

-- Scott