Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Wed, 23 Jan 2002, David L. Wasley wrote:

> I would offer another (favorite) example.  Let's assume the EPPN is
> in fact globally unique (through use of a DNS RHS).  If Jeff Schiller
> is on sabbatical at Berkeley for a year, we might choose to assign an
> EPPN of 
> 
>  for him in our directory.  We all know that that
> EPPN belongs to the one and only true Jeffery I. Schiller.  In this
> case stripping the RHS clearly would be wrong.

This example is interesting to consider, but I believe consideration
reveals the practice proposed in this example to be either irrelevant or
impractical.

That is, I think it is essential to the usefulness of the EPPN concept,
and more particularly the (EPPN-based) individual authorization
identifiers that are sent by Shibboleth AAs, that the asserting authority
is *authoritative* about them.  This implies that EPPNs have a structure,
with a local part and a globally-unique domain part, and that the
directory and/or AA is authoritative about names in that domain.  This is
not the only way to play the game, but I believe it is a way that is
consistent with current practice and will meet our needs.  More on this
below.

Let's think about what really would (or should) happen if Jeff Schiller
were to be at UCB temporarily.  I think there are two reasonable
possibilities.  One is that he simply continues to use MIT authentication
services, where MIT authorities identify him as 
.
  In Shib,
when he goes to a resource, at UCB or elsewhere, and sees "Where Are You
From?" he'll say "mit.edu", authenticate to the MIT HS in the MIT way (via
his MIT-issued cert, no doubt), and if the resource wants his EPPN it will
get 
"",
 along with his MIT staff affiliation, etc.  Everything
will be just as it is when he sits at MIT.

The other reasonable possibility is that UCB would give him a UCB EPPN,
such as 
"",
 as well as a UCB password (or other
authentication means, eg a client cert).  When he goes to a Shib-ized
resource he would tell the WAYF he's from "berkeley.edu" and then
authenticate to the UCB HS in the UCB way; resources will get his
""
 EPPN, along with his UCB visitor affiliation, etc.

I can't see any use for UCB to issue him (and for relying parties to be
prepared to accept) an EPPN of 
"".
  Institutionally it makes no
more sense than Berkeley issuing him a MIT ID card.  How would he use this
in Shib?  Would he get to the WAYF and think "well, I'll tell it I'm from
Berkeley, but I know when I get into the service it will think I'm
"?
  This would confuse even Jeff.

If Jeff wants to authenticate to resources as 
""
 he can do that
via MIT.  If he wants to access resources based on his UCB affiliation he
can authenticate with his UCB identity.  You might say:  suppose he wants
to do both at the same time?  I'd say:  (a) accessing resources using a
combination of authorization attributes issued by multiple authorities is
an interesting problem but not one we are trying to tackle at this time,
and (b) the proposed approach doesn't solve it in any case, because the
EPPN as seen by the RP is, as you say below, 
{}@berkeley.edu,
which is *not* the same as 
.

> A Relying Party, on the other hand, might want to receive 
> 
> and the fact that is was asserted by an AA/directory at UC Berkeley.
> It's AAP then would say whether to "trust" Berkeley to assert such an
> EPPN.

I can't see that this is a realistic policy for us to expect RPs to have.
The policy would be "the Berkeley AA can assert any EPPN".  The only way
this makes any sense is if every EPPN asserted by Berkeley is implicitly
"<the-EPPN>@berkeley.edu".  But *this* is far too limiting.

> Maybe there's a subtle issue here: the namespace or scope of EPPN
> versus the asserting party.  In Paul's #3 below, suppose the
> assertion of EPPN is received by server Alpha.com from UCB.edu.
> Alpha then passes it to server Beta.com which passes it to resource
> manager Gamma.com.  If I were Gamma, I would want to know
>
>    (((EPPN asserted by UCB.EDU) asserted by Alpha.com) asserted by Beta.com)
>
> Gamma's AAP then can decide what it wants to do with the EPPN.
>
> In any case, I still feel strongly that the EPPN should be treated as
> an opaque string by every party except perhaps the final relying
> party.  What's the downside of that?  
> (@xyz.edu?
>   Ugly
> but so what.  Maybe it should be rewritten as 
> xyz.edu!
> (or 
> berkeley.edu!))

David, I'm sorry.  This is just nuts.  Ask anyone.  *Nobody* wants to put
expressions such as those into ACLs or other access rules.  Have you ever
seen a system that uses such expressions?  I haven't.  In fact, I would go
so far as to say it's a basic function of the security infrastructure
component of a system to take assertions of the form "X is asserted by
Authority Y" and transform them to simply X (or perhaps X') so they can
be used by the rest of the system (while throwing out invalid assertions,
of course).

What people want is for the security system to deliver to them, with
reasonable assurance, attributes such as 
""
 and "MIT staff" and
"holder of entitlement X327B" which can be used by ordinary humans in
access control expressions.  The "who asserted this" *has* to be filtered
out before it gets to the access decision function; in the Shib case this
is by the AAP, or more precisely by the evaluation of the AAP.

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

Origin sites (OSs), which run HSs and Attribute Authorities, are
associated with DNS-named security domains (SDs) for which they are
authoritative.  In the many simple cases this is one-to-one, eg
OS(washington.edu) -> SD(washington.edu).  In more complex cases multiple
security domains can be associated with an origin, eg OS(claremont.edu) ->
SD(harveymudd.edu, pomona.edu, claremont.edu).  In other cases sets of
security domains might be represented by regular expressions, eg
SD(*.mit.edu) if the MIT OS wanted to claim authority over lcs.mit.edu,
medialab.mit.edu, etc, in one swell foop.  These associations are
maintained by the Club Shib administration (in the Club Shib case) or
optionally by relying parties (RPs) individually, and are the basis of
attribute acceptance policies at the RPs.  Scoped attributes, such as EPPN
and Affiliation, are always expressed by the OS, explicitly or implicitly,
as <local_part> + <security_domain>.  OSs only send to RPs attributes with
security domains values for which they are authoritative, both in order to
abide by the rules and because they know that RP policies will reject
attributes that are out of scope.  RPs can easily match the security
domains of attributes they receive against the list of domains for the
asserting party, and reject non-matching ones.  (I believe Steven and
Scott will be providing actual schema and other necessary details to fill
in these hand-waving concepts.)

I think this scheme will be relatively easy to manage for the Club and for
the other participating organizations, will provide reasonable
expressiveness for OSs (solving the "Claremont problem", eg), will provide
reasonable protection for RPs against misbehaving OSs, will provide usable
scoped attribute expressions, and will cover enough interesting attributes
to get us started.  It doesn't deal with other attributes such as
Entitlement for which scoping is less clear, but that's at least partly
because we don't know how those attributes will be used.  It doesn't deal
with assembling, at the RP, multiple scoped attributes from multiple
authorities in order to establish access, but as I said I think that's a
hard problem we'll have to solve some time later.

 - 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--