Shibboleth Developers

time to don your hip waders.....

Issue -- encoding and interpreting EPPN

Keith described the starting point:
At 10:20 AM -0600 12/21/01, Keith Hazelton wrote:
> eduPerson 1.0 meant the whole ePPN string to be opaque.
>
> Remember that the design center for eduPerson 1.0 was "The 
> Institutional Directory."  The quick and dirty way we recommended 
> that an institution promote institutional namespace uniqueness (the 
> left-hand side of ePPN) to GLOBAL uniqueness was by adding a 
> right-hand side containing DNS strings, thus was born . 
> The scenario that drove this was to make it easy for web server 
> administrators to manage .htaccess file entries;  ePPNs from any 
> number of institutions can be thrown into an .htaccess file without 
> fear of name clashes.
>
> That's what the institutional LDAP directories are going to have to 
> offer first-round pilot schools.  What Shibboleth components do with 
> that once they get it is another question...

I remember the conversation just as Keith has described it. I think, 
tho, that the expectation was that web servers would be directly 
retrieving the EPPN attribute from the directory, and then comparing 
it against "the access policy" (which would be a string in an 
htaccess file). We clearly weren't thinking in terms of transporting 
these attributes (any of them) within SAML Assertions. I do believe 
that most of the thinking work on eduPerson predates the startup of 
the SAML group. Its certainly possible that some web server might 
still implement the original idea. However, to my knowledge, there is 
no extant implementation of this functionality, and, at this point, I 
doubt anyone will be implementing it.

A very active thread in the EPPN discussion has been David's proposal 
that the RM support a policy of the form:

<opaque_EPPN>as asserted by<AA name>

This would treat the EPPN as an opaque string (which just happened to 
contain an @), and would clearly differentiate the RHS of the EPPN 
from the name of the entity making the assertion. IMO, while this 
might occasionally be useful, I feel strongly that in the vast 
majority of cases it will introduce more complexity than most 
webmasters/resource managers will be able to effectively comprehend. 
Especially in a campus environment, where we often decentralize web 
maintenance to the local level, and consequently have many webmasters 
with minimal technical skills. This construct can have have a variety 
of meanings; its not at all obvious what it means. I find that 
extremely troubling. I'm even more troubled by the sense that we're 
"special casing" EPPN in various ways. I'd much prefer to treat it in 
the same manner as the other attributes.

At one point, Scott suggested an alternate syntax (perhaps using 
bang). I felt this helped some, but didn't manage to overcome the 
basic problem of "what does such a string mean?".

Borrowing from Scott again, it appears that we have several elements 
to play with:

the name of the asserting party (the name of the AA)

attribute scope (the value of SecurityDomain in the subject element)

org name (obtained from the Registry file, provided by the WAYF to the SHIRE)

EPPN (unique name@ security domain) (no statements made yet about any 
required relationships between this security domain and any other 
element)

PROPOSAL

Create a new dynamic attribute, supported by Shibboleth, and called 
SHIB_EPPN. If an ARP instructed an AA to provide this attribute, the 
AA would obtain the user's EPPN attribute from their directory 
object, would strip the RHS and the @, and provide the LHS as the 
value of SHIB_EPPN.  This attribute would be scoped, like any other 
Shibboleth attribute, by the value of the SecurityDomain element.

The SHAR, using its default AAP, would, as usual, ensure that this 
particular AA can make assertions about this SecurityDomain. And, 
probably, that the scope equals the org name. (It might also check to 
ensure that the SHIB_EPPN does NOT contain a @.)

The Shib RM would follow its standard practice, and would compare the 
string "value(SHIB_EPPN)@SecurityDomain" against the relevant policy 
rule.

This requires that the LHS be unique within SecurityDomain; 
previously, I think all that we required was that EPPN be unique 
within "the directory".

I think this is a "reasonable and natural" way to process EPPN; it 
works the way browser users and webmasters would expect.

At this point, I view our use of SecurityDomain as "version 2 in our 
attempts to obtain an appropriately uniquifying element" (David's 
phrase). The RHS of EPPN was version 1. Our thinking about scoping 
has clearly outgrown that initial attempt; I think we should move on 
to a more appropriate framework before we deploy Shib, and create a 
legacy environment.
--
--

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

   http://archives.internet2.edu/

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