[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Stephen A. Langella
langella at bmi.osu.edu
Sun Feb 11 17:24:32 CST 2007
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