[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Von Welch
vwelch at ncsa.uiuc.edu
Wed Feb 7 08:34:21 CST 2007
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.
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 also find it disconcerting to have two different CAs issuing DNs in
the same namespace in the event something goes wrong. (I agree we
could move to a model of Issuer/DN for identity to resolve this.)
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
>
> *****************************************************************
>
More information about the ogsa-authn-bof
mailing list