[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
David Chadwick
d.w.chadwick at kent.ac.uk
Mon Feb 12 12:49:08 CST 2007
Hi Von
Von Welch wrote:
>
> David,
>
> If I go to any two CAs operating in the Grid community today, I will
> get two different DN's, even if I authenticate myself to those CAs using
> the same passport, driver's license, etc. There are a number of good
> reasons for this.
Could you give me one or two good reasons please. I usually find they
are not good reasons at all, but are expedient measures taken by the CA
to limit its liability (so that it does not need to act like a CA at all
e.g. Verisign Class 1 CA for example).
thanks
David
Why should it be different if I authenticate with
> Shibboleth?
>
> Von
>
> On Feb 7, 2007, at 9:15 AM, David Chadwick wrote:
>
>> Hi Von
>>
>> to answer your specific points:
>>
>> 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.
>>
>> It is not unreasonable to assume that each IDP will have the same
>> privacy policy for the set of GridShib CAs that provide access to the
>> same set of grid applications. Thus the user's attribute set will be
>> identical in each instance. Therefore it is reasonable to expect the
>> same DN to be issued by each of these CAs.
>>
>>
>>> 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 think it is reasonable to expect that if the IDP releases the DN to
>> one of the CAs, it will release it to all of them. I dont see why the
>> IDP would treat members of the set differently do you, since the same
>> user is accessing the same grid applications in each case.
>>
>>
>>> I also find it disconcerting to have two different CAs issuing DNs in
>>> the same namespace in the event something goes wrong.
>>
>> I dont find that disconcerting at all. The same user should be
>> entitled to have the same DN regardless of the CA. I repeat that CA's
>> are not naming authorities, they are certification authorities that
>> certify a user's DN that is issued by a naming authority.
>>
>> (I agree we could
>>> move to a model of Issuer/DN for identity to resolve this.)
>>
>> In this case the CA becomes a naming authority.
>>
>> regards
>>
>> David
>>
>>> 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
>>
>> *****************************************************************
>>
>
>
--
*****************************************************************
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://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
More information about the ogsa-authn-bof
mailing list