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

Wed Feb 7 09:09:27 CST 2007

Hi Von

the user is always the same user, no matter which portal he enters the 
grid through. His home IDP is always the same home IDP (assuming he uses 
the same login ID each time), so it seems functionally wrong that he 
should have different DNs just because a different CA was involved in 
issuing the cert. (My UK passport name is always the same, regardless of 
which UK passport office issued it. The office depends upon my home 
address, not my name. It should be the same with CAs.)  DNs are globally 
unique IDs by definition. DNs are allocated by naming authorities not by 
CAs. CAs are certification authorities who authenticate users and 
certify that they are entitled to the global DN they request. Thus I 
believe your original model is flawed.

The only time a CA becomes a naming authority is when it issues subject 
RDNs that are subordinate to its own globally unique DN. This is the 
model you suggested in your last paragraph. I personnally dont like this 
model, but it is not broken.

regards

David

Von Welch wrote:
> 
> 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
>>
>> *****************************************************************
>>
> 
> 

-- 

*****************************************************************
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

*****************************************************************