RE: Shibboleth Use Case Supported?

[Hal Lockhart <hal.lockhart@entegrity.com>]

Anders,

I am still struggling to understand the basis of this use case. Probably I
am just thick headed.

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
identify and some unspecified internal policy, the user's home domain
produces a set of custom credentials.

Is that the essence of the approach?

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

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 am not sure, but I believe you assert that this message exchange reduces
the need for advance configuration. I do not see that. 

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.

I don't see where the gain comes from or is it from some other aspect of the
scheme?

In general, I don't see what advantage this scheme has over generating the
same credentials for a user every time. I feel you are trying to solve some
specific problem, but I don't quite grasp its essential characteristics.

Let me start again and introduce some terminology.

Authentication (authc) Domain - a security domain trusted to be able to
authenticate a user and identify the user by at least one attribute,
typically name.

Authorization (authz) Domain - a security domain trusted to provide
credentials associated with a particular user.

Policy Decision Point (PDP) - a security domain capable of making an access
decision using user credentials and other inputs.

Policy Enforcement Point (PEP) - a security domain that allows or prevents
access to some resources based on the policy decision.

All of these entities can be under the control of different parties.

As I understand use case 1, the user first authenticates to the authc
domain, acquires credentials from the authz domain and the credentials are
conveyed to the PDP which makes a decision which is enforced by the PEP.
Authc and Authz can be under the same control or different, but they are
distinct from the PEP and PDP.

Another scenario which has been discussed is where the PEP asks the PDP to
make a decision based on user's credentials and other inputs. In this case,
the PEP and PDP are under different control. Authc and Authz may be under
the same control as the PDP.

In your use case, as I understand it, the user first contacts the PEP and
requests access. This causes the PEP to generate a "credentials
specification" which is conveyed to the Authz Domain. (Authentication
happens somewhere in here.) The Authz Domain generates credentials based on
the user's identity and the specifications, which are them conveyed to the
PDP. In Shibboleth it appears that Authc and Authz are under the same
control, but this does not seem to be required. The PDP is under different
control than the Authz.

Does that at least clarify my confusion?

Hal

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Tuesday, January 23, 2001 6:25 AM
> To: S2ML-USE; RL 'Bob' Morgan
> Subject: Shibboleth Use Case Supported?
> 
> 
> In Shibboleth is *seems* that the request order is like the following:
> 
> 1. A client tries to access a protected resource at a remote site
> 2. An associated auth-service asks the client to identify its 
> "home" domain
> 3. The auth-service signs a message indicating what kind of 
> authorization/authentication it wants and
> through redirect that is sent back to the home domain
> 4. The home domain authority creates a suitable signed credential
> for the client who trough another redirect hands over to the 
> protected resource
> 
> In the S2ML draft I see no support for this and AuthXML lacks 
> descriptions on this level
> so I can't really tell.
> 
> Nevertheless, this is a *VERY* important scenario that should 
> be a part of the use cases.