Shibboleth Developers

["David L. Wasley" <>]

Good question...
-----
At 9:51 AM -0600 on 1/20/04, Von Welch wrote:

>  I've been thinking about this over the weekend and let me try popping
> up a level for a moment and ask a more basic question.
>
>  There are applications out there that have authentication schemes
> other than Handles.

Could you describe what you mean?  Typically an authN mechanism will 
result in associating the physical user with some basic 'token' that 
is meaningful within the context of the authN domain.  In the Good 
Old Days it was the Unix or CMS login name.  With Shib, we've simply 
created a dynamic, short lived "handle" to preserve personal 
anonymity where that might be important.  However, the higher ed 
version of the AA assumes the EDUperson schema which includes a 
persistent identifier for the physical person - EPPN - which can be 
given to eligible applications.

My point is, if you're going to avoid asking the subject to 
re-authenticate every time it is necessary to determine their 
privileges then I believe you have to establish a stateful way of 
referring to that physical individual.  The embodiment of that state 
is a trusted string or data object of some sort.  Let's call it an 
"ID token" to avoid the Shib term.

> Assuming that Shib wants to work with these
> applications it seems like one of two things has to happen:
>
>  1) The Shib AA has to understand the identities used by these
> applications (either in addition to handles/EPPNs or instead of).

First terminology: "identity" is ambiguous (to me) in the above.  I 
think of the "stateful trusted data object" (ID token) as merely a 
handle by which applications can refer to a specific individual or 
class of individuals (e.g. "students").  I think of "identity" as the 
set of information ("attributes") that apply to that individual or 
group.  Some subset of that information should be discoverable by 
means of the ID token and a suitable authoritative database.

Of course, the ID token can be considered an attribute but that seems 
odd if it is transient, e.g. a Shib handle.  Therefore, can we agree 
that "identity" is "the persistent set of attributes that apply to an 
individual or group of individuals" and not the ID token per se? 
This is important to the following...

>  2) The applications have to understand handles/EPPNs (I'm not sure
> which) so that they can cast their questions in terms the shib AA
> understands.
>
>  In other words, where do you want to put the burden of federating the
> identities?

If you start with the basic assumption of Shib - the subject is known 
in some security domain - then only #2 above makes sense.  Once 
authenticated, the ID token refers to information known only in the 
security domain for which the AuthN mechanism applies.  In other 
words, the user authenticates to a security domain in which certain 
information is known about her/him.

"Federation" does not mean that the ID tokens are understood by every 
member of the federation but that members are willing to trust 
information provided by another member that applies to an individual 
who has authenticated in that other member's security domain.  The 
Shib "handle" is not "understood" by the target domain - it is merely 
passed back to the origin AA as an opaque object.

Therefore, if you want a VO to "borrow" a persistent identifier for 
members of a Grid community, you have to use the EPPN known to the 
member's HO.  The Grid applications can map that EPPN to a Grid 
identity.  Better yet - the Grid member can be known by their HO EPPN 
from the git go.  I see no motivation at all to ask every Home Org to 
store additional identifiers for use in other domains.

>  #1 seems to have the advantage that applications are kept simpler,
> but requires support of extra namespaces by the administrator/deployer
> of the shib AA.
>
>  #2 allows anyone who understands the EPPN/handle namespace to talk to
> the shib AA without any special support from it, but obviously is more
> work on their part.
>
>  I've been pushing on the #2 case recently.
Me too.

        David