Re: Shibboleth Use Case Supported?

[Anders Rundgren <anders.rundgren@telia.com>]

Hal,
Comments in line.  Maybe Bob should take this one since I may have misunderstood some parts of Shibboleth?

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

Right on!

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

Naturally there must be agreements between parties on credential profiles.
This scheme does not change that a single bit.  No scheme will.

> 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 think this is a very valuable option.  PKI is sometimes a bit scary.
But there are a lot of interesting things between giving away your
birth certificate and full anonymity.   The scenario I am mostly 
interested in, OBI, is something in the middle: "This person, who we
call J Doe is a representative for our [buying] organization and he is licensed to shop"

Or "This user is between 18 and 78 and may enter your disgusting XXX site" :-)

I.e. Shibboleth may function as an electronic ID card but may also support
a B2B-solution where individuals are "tools" for their organization.  Or serve the
health-care sector (that typically requires a lot of roles, clearances etc.).
Then when DoD has *finally* found out that the Army-wide PKI is a dead duck, they
can also adopt this.  Using mil-specified java code I guess :-)

An helpful home-domain server will of couse alert the user if personal
infomation is to be given out.  And since the credential consumer is identified
in the first place, you also have a pretty good idea where this info goes.

In the IETF-PKIX group I have "marketed" this as the X509 AC killer and I see
no signs of being wrong so far.

> I am not sure, but I believe you assert that this message exchange reduces
> the need for advance configuration. I do not see that. 

You are absolutely right.  The "payload" must be agreed upon.  But if your are
let's say "OBI compatible", that does not require much more than this declaration
(in Purple(tm) there is even a Service Discovery Interface in the works so you can see
what your potential partner is capable of in terms of payloads).

What I have argued about is that S2ML v0.8 requires configuration of certain
low-level protocol pieces as well.  I.e. in spite of agreement on payload,
you must set a lot of partner-specific stuff.

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

It sure is but it is on a rather high level.  Each usage will dictate their own procedures.
In B2B you may want to do a credit analysis on your potential partner (not the user) more than anything else.

Shibboleth does AFAIK not support anything to support this in a convenient manner.
This is a part of my proposed extensions.

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

I would say that Shibboleth solves a much broader class of authentication/authorization
problems than a system that only does one thing. 

> Let me start again and introduce some terminology.

OK, they are probably over the map. Realms, Domains, Sites, etc.
 
> 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, you are not a bit confused!  This was a nice and clear specification. Coould'nt
made it better myself. :-)

Regards
Anders