Shibboleth Developers

[Von Welch <>]

 > Maybe I should ask: what functionality is the Grid really looking
 > for?

I can answer this quickly so let me do so. There are actually two
things that I could see advantageous to the Grid community in regards
to Shib:

1) Leveraging Shib as a piece of AA software. Shib is written,
standards-based and supported, so why should we duplicate that effort?
If we can figure out how to make it interoperate with the Grids
(specifically the Globus Toolkit) then if a VO needs a AA, I can say
"Run Shib, and configure the Globus Toolkit like so".
 
2) Leveraging the current Shib deployments. Allowing VOs that may have
an interest in basing policy on attributes being served via Shib by
higher ed sites to do so.

I've bounced back and forth between the two. I think #1 is clearly
useful, folks in the Grid community are already writing things like
this. I'll admit #2 is a little bit more "build it and they will
come", I think some folks might use it, but maybe not as many as
#1. It seems like it would be nice if it fell out of solving #1, but
maybe not critical. Again this comes down to the question I asked
earlier about how the shib architects want to support applications
that have their own authentication mechanisms in place but want to
access user attributes through shib.

Von

David L. Wasley writes (09:58 January 20, 2004):
 > I agree completely with Scott, of course :-).  Shib is about exchange 
 > of trustworthy information, not about authN or what that information 
 > represents.
 > 
 > Since for higher ed (at least) one possible piece of information is a 
 > persistent identifier, I have been suggesting that the Grid use that 
 > for it's purposes.
 > 
 > Maybe I should ask: what functionality is the Grid really looking for?
 > 
 > If the Grid issues its own x.509 credentials, then it's clearly not 
 > looking for authentication.  If Grid apps want to use the identifier 
 > in those credentials to query a user's HO AA, then I suggest that the 
 > HO's EPPN for that user be in the Grid cert somewhere.
 > 
 > Is there something else?
 > 
 >      David
 > -----
 > At 11:29 AM -0500 on 1/20/04, Scott Cantor wrote:
 > 
 > >  >  There are applications out there that have authentication schemes
 > >>  other than Handles. 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).
 > >>
 > >>   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.
 > >
 > >I'd rather there not be any implication about EPPNs being somehow part of
 > >Shibboleth or in any way related to the notion of a handle. eduPerson is
 > >really the source of the promulgation of EPPN as a global username for
 > >principals across higher ed. If we think that's not a good solution, then 
 > >we
 > >should use something else, but Shibboleth really doesn't have to be a part
 > >of that discussion.
 > >
 > >Probably it is a decent solution but doesn't replace the existing 
 > >investment
 > >some may have in X.500, I would imagine. I can't think of anything else 
 > >that
 > >has any real global reach.
 > >
 > >As far as handles go, I'd rather focus on the underlying concept here, 
 > >which
 > >is representing a unique identity while preserving privacy. SAML 2.0 will
 > >standardize two ways of doing this: transient identifiers which are
 > >essentially like our handles and "federated" identifiers which are
 > >persistent pair-wise aliases for a principal. Both are intended to address
 > >privacy and work to prevent activity correlation across sites.
 > >
 > >Absent either of those considerations, other naming approaches probably 
 > >make
 > >more sense, and SAML is agnostic to all of them.
 > >
 > >>   In other words, where do you want to put the burden of federating the
 > >>  identities?
 > >
 > >Depending on how you define that, there is no identity federation 
 > >happening
 > >if you use a globally unique identifier. I prefer a more relaxed 
 > >definition,
 > >but either way, the issues are different if you don't need privacy.
 > >
 > >>   #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.
 > >
 > >It's almost a requirement to really address applications that can't deal
 > >with and manage an opaque identity though (e.g. storing of aliases). At 
 > >the
 > >very least, you have to map right away to something non-opaque, leaving 
 > >one
 > >to question the point of that. So I think we want the SAML authorities to
 > >support flexible policy about supporting different kinds of subject names
 > >based on the relying party, and that's where we're headed, which just 
 > >makes
 > >the subject one among the full set of attributes we're talking about.
 > >
 > >>   #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.
 > >
 > >The AA really doesn't care at all about the name *until you try and 
 > >address
 > >presence as a requirement*, and any persistent name fails at that, so
 > >probably that's something we need to address more generally than just
 > >forcing people to use handles.
 > >
 > >-- Scott
 >