RE: Shibboleth Use Case Supported?

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Hal, Anders:

[Sorry for the delay in responding.  I managed to take a little vacation.]

Let me point out up front that there is not yet any Shibboleth design, at
the level, say, of the S2ML spec.  The Shibboleth documents we seem to be
discussing are scenarios that project participants put together to give
folks an idea of how things might work.

> The essence of the scenario you keep talking about is this exchange between
> security domains which I will refer to as credentials negotiation. In other
> words, instead of a security domain producing a set of user attributes,
> either unconditionally or based on some internal policies, the security
> domain which owns the resource, specifies information about the sort of
> credentials it would like the user to have. Based on this, the user's
> identity and some unspecified internal policy, the user's home domain
> produces a set of custom credentials.
>
> Is that the essence of the approach?

Close enough.  I think there are two principles at work here.  One is the
basic security principle of least-privilege:  a target should be given
what it needs to make its access-control decision, nothing more.  The
other is user choice:  if I'm trying to access a target resource and it's
demanding to know a bunch of things about me in order to process my
request, then I should be able to know what those things are and refuse to
play if I don't want to reveal them.  This is one definition of "privacy".
(And no, I don't think there has to be elaborate UI to achieve this in
practice, but it does mean that policies have to be able to expressed and
interpreted and enforced.)  Note also when I say "user" that the policies
on what to reveal might be set by the requesting end-user or by someone
else in their security domain.

I see this as a key differentiator of the inter-institutional
authorization space.  Inside corporate walls many of us walk around with
badges on display that say who we are and what we do.  This is quite
different from walking around in public with your driver's license pinned
to your lapel, which I suspect few of us do.  Similarly traditional
security systems (eg Win2000) have been designed to provide the entirety
of a user's attributes to any target service.  This is efficient but
doesn't support what are IMHO very common concerns in the
inter-institutional case.  I have heard it said that corporations never
reveal their corporate directory info outside the firewall; so will it be
OK to push a complete set of user attributes to partner sites with every
access request?

I recently ran across some work that both describes these concerns and
some methods for implementing appropriate controls:

  http://www.transarc.com/~trg/TrustManagement/
  http://www.pgp.com/research/nailabs/distributed/darpa00-trust.asp

I'm not proposing that we mandate support for this kind of negotiation in
our work, but I'd like to be able to implement something like this using
the framework we develop.

> I can see how this could provide flexibility, although the unspecified
> transformation in the middle worries me a little.

I don't see how this is any different from the interpretation of privilege
attributes by the receiving party, which is also "unspecified".

> I can also see how this enables anonymity (to the resource owner),
> which is a Shibboleth requirement, but has not yet been tabled as a
> requirement for this TC.

I wouldn't call our requirement "anonymity" which is both rather slippery
as a concept and not broad enough.  "Privacy" would be a better
single-word shorthand, and "negotiated credential exchange" a better
phrase.  And indeed I'm suggesting that it be a requirement for this TC.
I imagine that many of your customers are interested in this too.

Regarding the message exchange ideas in the Shibboleth docs, which are
apparently similar to what Anders's system (about which I know nothing)
does, and which Hal describes in the remainder of his note, I'd say these
are system-design-level issues which are not the concern of the use-case
sub-group.  The message flows we describe implement the negotiation we
need, but there are probably other ways to do it.

> In Shibboleth it seems to me that arbitrary knowledge of where to find the
> user's home security domain must be configured in advance. The document "A
> Possible Model for a Shibboth Implementation" says
>
>  "This model assumes that prior to operation, the Service Provider enters
> into an agreement
>  with the Campus that allows members of the Campus community to gain access
> to one or more
>  Services from that Provider. The rules for eligibility and the User
> Attributes that may be
>  supplied to the Service are negotiated. Finally, a set of “Service Names”
> is provided to
>  the Campus and PKI public keys are exchanged so that authentication
> information between the
>  Service Platform and the Campus Authentication Proxy can be signed and
> validated."
>
> That seems like considerable advance configuration.

The "configuration" described in that document (which I will admit is on
the busy side) is about establishing the business relationship between the
institutional parties.  Presumably this is needed in any real deployment
of any of our protocols and in any case is outside the scope of our work.

 - RL "Bob"