[openstack-dev] [Keystone] Trust Specification Updated

David Chadwick d.w.chadwick at kent.ac.uk
Tue Dec 4 14:37:21 UTC 2012


Hi Alex

On 04/12/2012 13:08, Alexandra Shulman-Peleg wrote:
> Hi Adam, all,
>
> While working on Object Storage, we recognized two important delegation
> requirements: (1) fine-grained delegation (e.g. at the object level);
> (2)  direct user-to-user or application-to-application delegation
> (without involving any cloud management entity). To achieve these , I
> would like to propose the following two enhancements to the delegation
> specification.
>
> First, I suggest to broaden the specification of the delegation subject.
> It seems that the current proposal focuses on the delegation of roles,
> while for some services we might be interested in delegation of access
> to resources. For example, in Swift we might be interested to delegate
> an access to a single object. With the role delegation model, you might
> violate the principle of least privilege by giving more access rights
> than required. Thus, I think it will be good to have a generic field of
> "resource descriptor" in the token. Depending on the service that uses
> this mechanism, this field may refer to an object, container, vm or any
> other resource that can be of interest as a delegation subject.

You are correct in your analysis that a role might be too coarse grained 
for some delegations. The solution to this could be either

a) to include more policy information with the delegation which refines 
the delegation even furthre (as you suggest, one policy field could be 
the resource descriptor. We already have endpoint and validity time as 
other policy fields)

b) to make the delegator the attribute authority, and to invent his own 
attribute which has exactly the granularity he needs.

We have implemented the latter in our public demo here (which is built 
using Eucalyptus not OpenStack, but the principles are the same)

https://authz.tas3.kent.ac.uk/proxyS3/

If you have a google account you can login and try out the delegation 
feature.

Alternativelly you try it out as a standalone feature here (not part of 
a cloud infrastructure, but the delegation code is the same in both cases)

https://authz.tas3.kent.ac.uk/disdemo/

We would like to build this into OpenStack one day if we can get the 
APIs right


>
> Second, I suggest to broaden the delegation mechanism. I think that it
> will be good to have a user-to-user or application-to-application

correct. The delegation should be recursive and independent of the 
identity of the delegate or delegator.  So user to app and app to user 
should be equally allowable.

> delegation which can be done by users independently of Keystone.

This is more problematical, as you have to have signing keys somewhere 
in order to protect the delegation tokens. Since users typically dont 
have these, then you need a Delegation Service to issue the delegation 
tokens on behalf of the users (this is what our delegation service does 
in the demos)


> However, Keystone should be able to verify the integrity of the entire
> chain.

Which means the tokens have to be signed by a trusted issuer. (this is 
the X.509 model by the way).


>
> You can see additional details of the delegation chaining mechanism, as
> well as the requirements and the token fields in the following paper:
> http://www.scpe.org/site/index.php/scpe/article/view/727/325- see the
> full reference below.

I see this is a capability based model (from reading the abstract). I 
have had discussions with Alan Karp, HP, about this, and we have agreed 
that attribute based delegation can be just as functional as capability 
based schemes. (In fact I think more so, given the level of indirection 
between attribute and privilege)

regards

David


>
> I will be glad to jointly work on adding these two enhancements.
>
> Thank you very much,
> Alex.
>
> Paper reference:
> Secure Access Mechanism for Cloud Storage
> <http://www.scpe.org/site/index.php/scpe/article/view/727>
> D Harnik, E K Kolodner, S Ronen, J Satran, A Shulman-Peleg
> <http://researcher.watson.ibm.com/researcher/view.php?person=il-SHULMANA>,
> S Tal
> Scalable Computing: Practice and Experience 12(3), 2011
>
> ----------------------------------------------------------
> Alexandra Shulman-Peleg, PhD
> Storage Research, Cloud Platforms Dept.
> IBM Haifa Research Lab
> Tel: +972-3-7689530 | Fax: +972-3-7689545
>
>
>
> From: Adam Young <ayoung at redhat.com>
> To: David Chadwick <d.w.chadwick at kent.ac.uk>,
> Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Date: 04/12/2012 06:18 AM
> Subject: Re: [openstack-dev] [Keystone] Trust Specification Updated
> ------------------------------------------------------------------------
>
>
>
> On 12/03/2012 04:19 PM, David Chadwick wrote:
>  > Hi Adam
>  >
>  > yes this is nice work. I have added a few minor mods to the wiki
>  > version to pick up a few missing pieces. I have annotated these with
>  > <David> so that you can easily spot them
>
> Good changes all.  I took two of them pretty much as is (DELETE  and the
> optional fields).  I also added this
> http://wiki.openstack.org/Keystone/Trusts#Token_Format_Changesto
> account for tracking the chain of responsibility.
>
>  >
>  > regards
>  >
>  > David
>  >
>  >
>  > On 03/12/2012 16:34, Adam Young wrote:
>  >> I realize we have had a little bit of disagreement on what to call
>  >> this.  I am going to continue to call it "Trusts" as it is a subset of
>  >> the set of mechanisms for delegation.
>  >>
>  >> I've wikified the Specification.  Big thanks to David Chatwick for
>  >> making this a much better spec.
>  >>
>  >> http://wiki.openstack.org/Keystone/Trusts
>  >>
>  >> Blueprint is still at
>  >>
>  >> https://blueprints.launchpad.net/keystone/+spec/trusts
>  >>
>  >>
>  >> I will continue to work on this, to include, for example, how to
>  >> specifiy duration and start times, but there should be enough here for
>  >> people to understand.
>  >>
>  >> My initial write up:
>  >>
>  >> http://adam.younglogic.com/2012/10/preauthorization-in-keystone/
>  >>
>  >> _______________________________________________
>  >> OpenStack-dev mailing list
>  >> OpenStack-dev at lists.openstack.org
>  >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>



More information about the OpenStack-dev mailing list