[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Von Welch
vwelch at ncsa.uiuc.edu
Sun Feb 11 11:18:32 CST 2007
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. 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
>
> *****************************************************************
>
More information about the ogsa-authn-bof
mailing list