[ogsa-authn-bof] Shibboleth/Grid Namespace Convergence
Von Welch
vwelch at ncsa.uiuc.edu
Tue Feb 6 21:48:14 CST 2007
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
>
More information about the ogsa-authn-bof
mailing list