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

Alan Sill Alan.Sill at ttu.edu
Wed Feb 7 11:43:18 CST 2007 

I would agree that we have identified namespace mapping on the front  
end (persistent identifier to DN) as an issue that needs to be  
addressed in a generalized AuthN approach if X.509 DN's are required  
for interoperability with existing grid software.  Note this issue is  
similar to, but different from, the mapping needed on a resource or  
service at the AuthZ level.

Let me note that the use of eduPerson... in the discussion here is  
interesting, but we need to come up with a standards architecture  
that will be of use beyond just the educational space, e.g. for  
interoperability with commercial grids, etc.

All a very interesting discussion!

On Feb 7, 2007, at 11:33 AM, Tom Scavo wrote:

> Just a point of clarification with respect to the IdP...today campus
> IdPs are able to assert eduPersonPrincipalName (which has the same
> value across SPs), but many production IdPs are loathe to release
> ePPN.  Instead, to prevent collusion among SPs (and to protect
> privacy), Internet2 is moving towards eduPersonTargetedID (ePTID).
> Unlike ePPN, the value of ePTID is specific to the SP, that is, ePTID
> is essentially a triple (see SAML2Core regarding the new persistent
> identifier).  So by default, collusion is prevented.
>
> Moreover, I should point out that campus IdPs do not, and probably
> will not (unless the CA is integrated with the IdP), assert
> X509SubjectName.  In the foreseeable future, t will be up to the Grid
> to map ePTID to DN.  Today we algorithmically map a campus identifier
> to a DN.  I think we will have to move to a persistent model
> regardless of the DN properties we choose to adopt.  The model I have
> in mind is employed by myVocs today.
>
> Tom
>
> On 2/7/07, David Chadwick <d.w.chadwick at kent.ac.uk> 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
>>
>> *****************************************************************
>> _______________________________________________
>> 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

Alan Sill, Ph.D
TIGRE Senior Scientist, High Performance Computing Center
Adjunct Professor of Physics
TTU

====================================================================
:  Alan Sill, Texas Tech University  Office: Admin 233, MS 4-1167  :
:  e-mail: Alan.Sill at ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
====================================================================

More information about the ogsa-authn-bof mailing list