[openstack-dev] [Keystone] Trust Specification Updated
ayoung at redhat.com
Wed Dec 5 19:52:18 UTC 2012
On 12/04/2012 09:37 AM, David Chadwick wrote:
> 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
>> 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)
That is cool. I think this is along the lines of what we want to do.
The user needs to tell the enforcer somehow that "this attribute means
these actions" and the PDP needs to understand that.
> If you have a google account you can login and try out the delegation
> 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
> 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.
Two different things. recursion should not be infinite. When shooting,
you want a range on your munitions, otherwise, the whole world is down
range. Same with giving authority: it is rare you want to delegate
authority infinitely. We'll make it explicit for a first approximation,
and then listen to the screams from the community.
>> 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)
This is in a blueprint already. I originally called it "Federation" as
you recall, but it is now, more correctly called delegation, which is
why I wanted to keep the name "Trusts" to keep the two mechanisms separate.
>> However, Keystone should be able to verify the integrity of the entire
> Which means the tokens have to be signed by a trusted issuer. (this is
> the X.509 model by the way).
Yes, and this is what the Delegation blue print builds on. We use CMS.
>> 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)
>> I will be glad to jointly work on adding these two enhancements.
>> Thank you very much,
>> Paper reference:
>> Secure Access Mechanism for Cloud Storage
>> D Harnik, E K Kolodner, S Ronen, J Satran, A Shulman-Peleg
>> 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
>> 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
More information about the OpenStack-dev