Skip to Content.
Sympa Menu

shibboleth-dev - RE: Attributes, and Shibboleth -- the EPPN swamp

Subject: Shibboleth Developers

List archive

RE: Attributes, and Shibboleth -- the EPPN swamp


Chronological Thread 
  • From: "RL 'Bob' Morgan" <>
  • To: "'Shibboleth Project'" <>
  • Cc: MACE-Dir <>, Shibboleth Design Team <>
  • Subject: RE: Attributes, and Shibboleth -- the EPPN swamp
  • Date: Fri, 25 Jan 2002 10:57:37 -0800 (PST)


On Thu, 24 Jan 2002, RL 'Bob' Morgan wrote:

> So, here's the game I propose, in Shib terms.

So, a semi-concrete example, deliberately avoiding real (meaning
XML-based) syntax since that's beside the point and I don't want to
pretend to be making a real syntax proposal.

Club Shib maintains data looking like:

origin-site: washington.edu
security-domain-list: u.washington.edu
handle-service: shib.washington.edu
handle-service-cert: ...
attribute-authority-list: aa1.washington.edu, aa2.washington.edu
admin-contact: Sandy Suit
<>
tech-contact: Bob Geek
<>
origin-site: mit.edu
security-domain-list: mit.edu, *.mit.edu
handle-service: shibweb.mit.edu
handle-service-cert: ...
attribute-authority-list: shibaa1.mit.edu, foo.outsource.com
origin-site: claremont.edu
security-domain-list: claremont.edu, harveymudd.edu, pomona.edu
handle-service: handles.harveymudd.edu
handle-service-cert: ...
attribute-authority-list: shib1.harveymudd.edu, shib1.pomona.edu

Club admins get the info from the Club contacts at the respective sites,
with appropriate inquiry into validity of both the base info and in
particular the claimed security domains. In particular verification of
authority over the security domains might involve checking DNS
registration records or other contacts regarding those domains. There is
work involved, but it's not unlike the info already maintained by, say,
Internet2 about its members (including DoDHE info, etc). This is all made
very public, and is signed by the published Club Shib key, so if a mistake
is made and, say, washington.edu fraudulently claims authority over
wsu.edu (heaven forbid), this should be readily detectable by all
concerned.

Does this scale up to 10^^4 or 10^^5 sites? Maybe not. But I think the
point of the Club observation is that it doesn't have to to be useful, at
least for the next few years.

So, the washington.edu institutional directory publishes EPPNs like
""
(yes, it really is "u." for historical reasons,
there is no defined "washington.edu" security domain at this point). The
washington.edu AA asserts attributes and values with the semantics:

eppn: local-part="rlmorgan", security-domain="u.washington.edu"
affiliation: local-part="staff", security-domain="u.washington.edu"

and these are accepted by RPs because their AAP includes the info that the
washington.edu AA is authoritative about the security-domains in these
attribute values.

Mit.edu doesn't have an institutional LDAP directory, but they manage to
keep track of the info that Paul Hill's preferred principal name is
"",
while Pat Lee's is
""
(how
they verify that that is really a valid security identifier for this
particular Pat Lee is up to them). The mit.edu AA can then assert
attributes and values for Pat Lee like:

eppn: local-part="patlee", security-domain="mumble.lcs.mit.edu"
affiliation: local-part="faculty", security-domain="mit.edu"

and these are accepted by RPs because their AAP includes the info that the
mit.edu AA is authoritative for the indicated security-domains, relying on
a regexp match between "mumble.lcs.mit.edu" and "*.mit.edu".

The claremont.edu AA similarly can assert things like:

eppn: local-part="dana", security-domain="pomona.edu"
affiliation: local-part="student", security-domain="pomona.edu"
enrolledcourse: local-part="phys-10", security-domain="harveymudd.edu"

This proposal brings up an issue regarding user expectations and WAYF. A
user with an EPPN of

may legitimately think that they
should type "pomona.edu" (or just "Pomona") into WAYF. So a user-friendly
WAYF would want to be able to do the same kind of matching that the AAP
does so this user isn't obliged to know that "claremont.edu" is really the
name of their site.

This is probably OK to do, but it does affect a different issue, which is
the possibility that multiple sites might be authoritative over a single
security domain. This would not be something to enter into lightly, but
seems do-able, eg if lcs.mit.edu wanted to start being its own Shib
origin-site while some of its users are listed in the main mit.edu site;
or if, say, the OKI project became okiproject.org and some of its members
wanted okiproject.org EPPNs, and some were listed in the mit.edu site and
others were listed in the stanford.edu site. What does the WAYF do if a
user says they're from "okiproject.org" and that matches more than one
origin-site? Maybe it could do what weather.com does and say:

Pick one of:
okiproject.org (mit.edu site)
okiproject.org (stanford.edu site)

Anyway, the general problem I suppose is that if there is a skew between
site names and security-domain names, and users can type in either,
there's potential for ambiguity.

- RL "Bob"



------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page