[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence

Wed Feb 7 08:34:21 CST 2007

David,

  I should have phrased requirement #1 as:

>  1) The same user, identified by a given IdP, using the same  
> GridShib-CA, MUST always map to the  same DN in the Grid space

In regards to dropping requirement #6, I think what you really want  
is to change requirement #1 so that it looks like the following:

The same user, identified by a given IdP, using *any* GridShib-CA,  
MUST always map to the same DN.

I have several concerns about this approach. I believe this means we  
have to do one of the following:

1) Every GridShib-CA instance must have access to the same user  
attributes and use the same transformation policy. This is tight  
coordination that I don't believe is possible to guarantee.

2) The IdP must provide the DN to all instances of the GridShib-CA.  
Again, global coordination that I don't see as possible.

I also find it disconcerting to have two different CAs issuing DNs in  
the same namespace in the event something goes wrong. (I agree we  
could move to a model of Issuer/DN for identity to resolve this.)

Von

On Feb 7, 2007, at 7:35 AM, David Chadwick wrote:

> Hi Von
>
> It seems to me that requirements 1) and 6) conflict. I support  
> requirement 1) but not 6). If a user enters grid space via two  
> different Shibbolised portals, he will always be redirected back to  
> his IDP to authenticate, and ought to get the same grid DN from  
> both portals. Requirement 1) implies this. Requirement 6) states  
> this will not be the case. Hence I think you should drop  
> requirement 6).
>
> regards
>
> David
>
>
> Von Welch wrote:
>> Nate,
>>   Here's my current thinking on this. Let me start with what I see  
>> as  the requirements and then move on to what our plans are  
>> currently.  Note that our current implementation (0.3.0) of the  
>> GridShib-CA does  not implement this, but the plan is for the next  
>> version to do so.
>> Requirements for a standard Grid profile follow. One could also   
>> imagine profiles that support psuedonymity, but I assert that the   
>> following profile is a standard mode of operation any Shib->Grid   
>> translator SHOULD be able to support.
>>   1) The same user, identified by a given IdP, MUST always map to  
>> the  same DN in the Grid space
>>   2) Two different users MUST never map to the same DN in the Grid  
>> space
>>   3) Identifiers mapped from a given IdP MUST be mapped in such a   
>> manner that prevents conflict with identifiers mapped from  
>> another  Idp. (Note that this implies that the same user,  
>> identified by two  different IdPs, will have two different DNs.)
>>   4) It SHOULD be discernible from a DN, which IdP asserted the   
>> mapped identifier.
>>   5) DNs SHOULD contain a reasonable facsimile of the user's  
>> legal  name. (This motivation for this comes from the IGTF.)
>>   6) DNs created by two different instances of a GridShib-CA  
>> SHOULD  be done in such a manner as to prevent any conflict. This  
>> implies the  same user, from the same IdP going through two  
>> different GridShib-CA  instances will get two different DNs. The  
>> only exception to this  should be if both GridShib-CA instances  
>> are operated by the same  organization in some sort of replication  
>> scenario (the are logically  the same instance).
>> Currently Shibboleth identifiers are scoped to the issuing IdP.  
>> This  makes some of the requirements above easier to meet. If this  
>> changes,  it will require the addition of a IdP identifier to the  
>> DN given  below. See the following URL for a discussion of this:  
>> http:// bugzilla.globus.org/bugzilla/show_bug.cgi?id=4888
>> Our plan is for the GridShib-CA to issue DNs which look like the   
>> following:
>> /DC=edu/DC=uiuc/DC=ncsa/DC=gridshib-ca/O=User Certificate/ 
>> CN=<ePTID>/ <displayName>
>> The DC components serve to uniquely identify the GridShib-CA  
>> instance  in question and meet requirement #6.
>> Where <ePTID> is the eduPerson Targeted ID and <displayName> is  
>> the  displayName attribute, both as provided by the IdP.
>> ePTID is used because it has a persistence quality lacked by ePPN   
>> (i.e. it is guaranteed never to be reassigned). This serves to  
>> meet  requirements #1-#4.
>> displayName provides the facsimile of the user's legal name   
>> (requirement #5).
>> That said, we expect some institutions may have problems  
>> providing  ePTID, so we expect to be able to fall back to ePPN,  
>> recognizing that  doesn't guarantee meeting requirement #2 as ePPN  
>> could, in theory be  re-assigned, and doesn't meet requirement #5  
>> as ePPN looks more like  an email address than a legal name.
>> Comments welcome.
>> Von
>> On Feb 5, 2007, at 10:26 PM, Nate Klingenstein wrote:
>>> OGSA-Authn BoFfers,
>>>
>>> At our meeting in North Carolina, I flagged the translation of names
>>> from the grid world to the institutional world and vice versa as
>>> being an important topic for discussion in the next several months.
>>> We need to begin to document current practices so that a path  
>>> towards
>>> convergence can be identified.
>>>
>>> I'd like to give a brief background for those on the list who aren't
>>> heavily steeped in this problem.  The various Shibboleth-grid
>>> integration projects out there all want to bootstrap grid
>>> authentication (and sometimes authorization) by use of institutional
>>> authentication.  This authentication generally results in a unique
>>> identifier for the user which differs in form from that used on the
>>> grid, and potentially in semantic meaning as well.
>>>
>>> There is a lot of different types of identifiers.  If a campus is
>>> using LDAP, the user will also have a DN associated with their  
>>> entry,
>>> but this directory DN is rarely used as an identifier in practice  
>>> and
>>> usually won't correspond to those issued in x.509 certificates
>>> anyway.  Local practices for primary identifier vary based on local
>>> needs, and many institutions don't use LDAP at all.
>>> eduPersonPrincipalName, which takes the form of name at domain, has
>>> proven the most ubiquitous and successful in inter-realm deployment
>>> thus far.
>>>
>>> The critical step is translation of the identifier that results from
>>> campus authentication to a grid-usable credential(and, potentially,
>>> vice-versa for callbacks).  This bootstrap can be performed in many
>>> ways at many different points.  Differences in practice could  
>>> lead to
>>> non-interoperability and general confusion for grid SP's and campus
>>> IdP's alike.
>>>
>>> There are several projects out there that have bridged this gap in
>>> creative ways, such as SHEBANGS, SLCS, and GridShib.  I'd like to
>>> invite each project to take some time within the next month to
>>> describe in a brief document how they linked Shibboleth
>>> authentication to the grid as a first step.  If there's a  
>>> willingness
>>> to document additional passing of authorization or attribute
>>> information, I think that would be useful as well.
>>>
>>> Cheers,
>>> Nate.
>>> _______________________________________________
>>> ogsa-authn-bof mailing list
>>> ogsa-authn-bof at ogf.org
>>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>>>
>> _______________________________________________
>> ogsa-authn-bof mailing list
>> ogsa-authn-bof at ogf.org
>> http://www.ogf.org/mailman/listinfo/ogsa-authn-bof
>
> -- 
>
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
>