Open Stack

Comments below. lots of cuts to aid readin

On 05/12/2012 19:52, Adam Young wrote:

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

Correct. It means having code that can update the user's policy, and 
having code that can evaluate multiple policies (user's, openstack 
administrator's, service provider's etc) and resolve conflicts between 
them. A nice relatively long term challenge.


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

In my opinion the delegator and delegate should be any entity, and not 
restricted to delegation to the same type of entity as yourself. That is 
one thing. Do you agree with this?

The other is recursion. You can have zero, limited or infinite.
There are use cases where infinite (or a large number) is appropriate, 
just as there are use cases for zero and limited.

  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.

If you have a dynamic workflow which you want to run to completion, 
which has multiple steps, which can vary, then you most likely want 
infinite or a large number (at least as big as the max possible number 
of steps) otherwise you are in danger of the workflow halting before it 
reaches the end.

>
>>
>>> 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.
>
> http://wiki.openstack.org/keystone/Delegation

I have re-read this and added some more detailed comments to it. I think 
that your original title of Federation was more correct than the current 
title of delegation. I think trusts should be re-named delegation, and 
delegation should be renamed Keystone Federation, whilst my Federation 
blueprint should be renamed Federated Identity Management to 
differentiate it from Keystone Federation.

regards

David



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