[cap-talk] Comparing models

[Karp, Alan H]

I've changed the subject line to reflect the topic being discussed.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp


> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Wednesday, June 08, 2011 2:39 AM
> To: Karp, Alan H
> Cc: Hoyt L Kesterson II
> Subject: Re: We met at the Cornerstones of Trust conference and...
> 
> Hi Alan
> 
> On 07/06/2011 22:31, Karp, Alan H wrote:
> > That's quite different from the kind of RBAC systems you see
> > presented at places like the RSA conferences and what I see in
> > corporations.  For example, HP used to have 850+ roles, which were
> > becoming unmanageable.  Folks in my Lab used some clever mathematics
> > to reduce that to a bit over 200 at the cost of modest over
> > provisioning.
> 
> Yes I realise this is a problem in large scale systems, where you may
> need almost as many roles as permissions in order to get the right
> granularity of access. But as you say you can often collapse the number
> of roles by giving some users a few more permissions than they should
> really have.
> 
> 
> >
> > I spoke (typed!) too soon on my previous reply.  We're not in full
> > agreement, just mostly in agreement.  The difference is that a
> > capability combines designation of an object with the right to use
> > it.  What you described separates them, a string for the file name
> > and a delegation of a role for the authorization.
> 
> Yes. The permission stays as in your system, an access method on an
> object. The role is a completely separate string that may or may not be
> syntactically related to either or both of the access method and the
> object. Since the role is the only string that the user sees, then the
> user has to infer what permission he is being given from the role.
> Clearly one could generate role strings of the type "<action><object>"
> such as "submit job" but this is not part of the model. The role could
> just as we be "operator".
> 
> 
>   That split
> > requires extra care to avoid using the wrong role when accessing a
> > resource.
> 
> correct.
> 
>    That's not a showstopper, but it is worth thinking about.
> > Our ZBAC approach,
> > http://www.hpl.hp.com/techreports/2007/HPL-2007-105.html, allows a
> > similar split for invoking legacy services.  In our approach, the
> > resource is designated by a URI, and the same URI appears in the SAML
> > authorization assertion.
> 
> Well I would not expect (nor want) users to see SAML assertions, and
> preferably not URIs either.
> 
> 
>   How does the invoked service know which
> > role to use for each access in your approach?
> 
> Because its in its ABAC/RBAC policy. The policy says "this set of
> attributes are needed to perform this action on this resource".
> 
> There is typically one such rule for every permission in the system. In
> this way you have a many to many mapping, and one attribute can give
> many permissions, or many attributes can be needed for one permission.
> We have just built an example system where you need the following 4
> attributes (provided as SAML assertions from different authorities) in
> order to buy a car parking permit from a local council web site:
> A credit card from a bank
> A car registration number from the Vehicle Licensing Authority
> A name from the Dept of Pensions
> An address from the Dept of Pensions
> 
> This is now a public demo, which we gave at the recent W3C Identity in
> the Browser workshop in Mountain View. If you want to try it I can send
> you details. (the technical details are described in our position paper
> to the W3C workshop)
> 
> 
> >
> > Capability systems use a pattern called "rights amplification" that
> > is similar to needing two or more roles to get permission to do
> > something.  The classic example is a sealed box containing an object.
> > The only way to invoke methods on the object is to have both a
> > capability to the box and a capability that unseals it.  The
> > difference is that one of the roles might carry permissions on its
> > own, while neither capability can do anything on its own.
> 
> Exactly. This is precisely what our system provides. (as in the example
> above, a credit card may provide lots of permissions, whereas a car
> registration number on its own may provide nothing.)
> 
> Regards
> 
> David
> 
> --
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> School of Computing, University of Kent, Canterbury, CT2 7NF
> Skype Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site:
> http://www.cs.kent.ac.uk/research/groups/iss/index.html
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************