[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Von Welch
vwelch at ncsa.uiuc.edu
Sun Feb 11 11:29:27 CST 2007
Steve,
Could you expand on your example DN some? I'm not sure what strings
are literal and which are supposed to represent other values. E.g. is
"Idp[1]" a literal string or replaced with some IdP id?
/O=OSU/OU=BMI/OU=caGrid/OU=Dorian/OU=cagrid05/OU=IdP
[1]/CN=someuser
Thanks,
Von
On Feb 8, 2007, at 10:41 AM, Stephen A. Langella wrote:
> I agree with Alan, Dorian (the user CA for caBIG) provides a similar
> functionality allowing users to create grid credentials by
> authenticating with it using their institution provided credentials.
> We have the same problem in that we must assign user's an identity in
> the grid space based of their identity in the local space. Our
> experiences show that some in our community use eduPerson, while
> others
> do not. To be able to deal with the diversity of local
> representations
> of users that we encounter in our community we have defined the notion
> of attributes abstractly. For example Dorian only requires that a
> local identity provider be able to uniquely identify their users,
> Dorian
> does not place any restrictions on the attribute name
> (eduPersonPrincipalName vs userId at XYZ). When a local Identity
> Provider
> is registered with Dorian, we specify to Dorian the name of the
> attribute that the Identity Provider uses to uniquely identify its
> users. When Dorian receives assertions from the Identity Provider it
> then uses the attribute name specified to extract the value. Dorian
> also assigns a unique id to each Identity Provider registered to it.
> Dorian assigns unique grid identities based on the Dorian CA subject,
> the id of the local Identity Provider, and the user's unique
> identifier
> within their IdP. For example:
>
> /O=OSU/OU=BMI/OU=caGrid/OU=Dorian/OU=cagrid05/OU=IdP
> [1]/CN=someuser
>
> Of course in order to ensure the uniqueness of identities in a Grid
> with
> multiple Dorian's running or across Grids; appropriately
> naming/namespacing CA(s) and enforcement of signing policies is of
> critical importance. Just my two cents, comments welcome.
>
> --Steve
>
> Stephen Langella
> Senior Research Specialist
> Ohio State University
> Department of Biomedical Informatics
> Multiscale Computing Laboratory
>
> Office: (614) 292-9845
> langella at bmi.osu.edu
>
> -----Original Message-----
> From: ogsa-authn-bof-bounces at ogf.org
> [mailto:ogsa-authn-bof-bounces at ogf.org] On Behalf Of Alan Sill
> Sent: Wednesday, February 07, 2007 12:43 PM
> To: Tom Scavo
> Cc: OGSA Authentication WG BoF
> Subject: Re: [ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
>
> 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 :
> ====================================================================
>
>
> _______________________________________________
> 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
>
More information about the ogsa-authn-bof
mailing list