Open Stack

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. 

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 
delegation which can be done by users independently of Keystone. However, 
Keystone should be able to verify the integrity of the entire chain. 

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 will be glad to jointly work on adding these two enhancements. 

Thank you very much,
Alex. 
 
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 
http://wiki.openstack.org/Keystone/Trusts#Token_Format_Changes to 
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/33a8e2b4/attachment.html>