[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Stephen A. Langella
langella at bmi.osu.edu
Tue Feb 13 14:10:30 CST 2007
Von,
From Dorian's perspective (at least currently) it is not
required that they have an identifier.
--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: Von Welch [mailto:vwelch at ncsa.uiuc.edu]
Sent: Tuesday, February 13, 2007 3:09 PM
To: Stephen A. Langella
Cc: Alan Sill; Tom Scavo; OGSA Authentication WG BoF
Subject: Re: [ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Steve,
> (2) The identifier assigned by Dorian to the IdP:
>
> /OU=IdP[1]
So IdP's in Dorian's world (for lack of a better term) don't have
identifier's of their own, like Shibboleth IdPs do?
von
On Feb 11, 2007, at 5:24 PM, Stephen A. Langella wrote:
> Ok let me try to elaborate a little, as I mentioned Dorian runs a
> CA, in
> the example I provided the subject of that CA is:
>
> O=OSU,OU=BMI,OU=caGrid,OU=Dorian,OU=cagrid05,CN=caGrid Dorian CA
>
> Our user identities are assigned as follows:
>
> (1) CA subject without the CN.
>
> /O=OSU/OU=BMI/OU=caGrid/OU=Dorian/OU=cagrid05
>
> (2) The identifier assigned by Dorian to the IdP:
>
> /OU=IdP[1]
>
> (3) The user's unique id within the IdP, for example
> eduPersonPrincipalName:
>
> /CN=someuser
>
> Assuming the subset of the CA subject that we use is unique,
> putting all
> of these together we get a unique grid identity:
>
> /O=OSU/OU=BMI/OU=caGrid/OU=Dorian/OU=cagrid05/OU=IdP[1]/CN=someuser
>
>
> As I mentioned earlier appropriately naming/namespacing CA(s) and
> enforcement of signing policies is of critical importance.
>
> I should mention that this works for use but we are certainly not tied
> to it. Although effective we don't like using Dorian id for an
> IdP in
> the grid identity because it is not portable, for example if we
> were to
> change the way Dorian assigns IdP identifiers, all of our grid
> identities would need to change.
>
> To comment on David's suggestions:
>
>
>>> i) create the user's DN based on the name of its IDP, because we
>>> know
> that IDPs are already uniquely named by their DNS >>names.
>
> In my opinion this would be very hard to enforce signing
> policies, also it is possible that a user could have two or more
> sets of
> credentials signed by two or more certificate authorities.
>
>>> ii) create the user's DN based on the name of the CA, since all CAs
> have to have unique names (otherwise the PKI is >>broken).
>
> For Dorian this won't work because we could have two users with
> the same local user id from two different IdPs.
>
> Combining Dave's suggestions (1) use the ca name, (2) use the DNS
> based
> name, and (3) using the local user identity within the IdP would work.
> This is essentially what we are doing now except we use the Dorian
> assigned identifier for an IdP rather than the DNS based name. I
> certainly would not be opposed to changing Dorian to support the DNS
> based IdP name as I think it is more readable and would not suffer
> from
> the portability issues I mentioned before. Perhaps there are other
> ideas as well. 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: Von Welch [mailto:vwelch at ncsa.uiuc.edu]
> Sent: Sunday, February 11, 2007 12:29 PM
> To: Stephen A. Langella
> Cc: Alan Sill; Tom Scavo; OGSA Authentication WG BoF
> Subject: Re: [ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
>
>
> 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