|Subject:||RE: Shibboleth Use Case Supported?|
|From:||RL 'Bob' Morgan (rlmo...@washington.edu)|
|Date:||Jan 31, 2001 1:45:31 am|
[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:
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"