Open Stack

On 12/06/2012 07:13 AM, David Chadwick wrote:
> 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?
Perhaps in the abstract, but in the context of Keystone, only users can 
receive tokens.  Thus, remote services are assigned service users, and 
the Trust will be set up between users.  This model works well enough in 
the unix world that I don't think it will fundamentally limit us.  It is 
comparable to the X509 approach where everything is a principal.

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

I can see that for some systems.  Like I said,  we won't rule it out, 
but I want to see demand from the community before I take the range 
limit off.  I think, though, even when we allow infinite regress, we 
make that an explicit choice, not default.


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

I think I want to keep the name trusts.  I think delegation needs to be 
qualified, as it is an overused term in computer science.  As I said, I 
consider delegation something that goes up and down an hierarchy (no, I 
don't usually put 'an' before 'H' words, see what bad habits I'm picking 
up?)  It sounds strange to say that "I delegate to my friend the use of 
my car", but "I trust my friend with the use of my car" makes perfect sense.

A user really has no autonomy in a Keystone system.  Everything a user 
does has to be blessed off in the signed document.  That is why it 
doesn't really make sense to say "anything not speicifed is delegated" 
as we can only delegate things that are specified in the token document 
anyway.

Also, the delegation of trust is done in the signed document.  The Trust 
is the contract, but the actual delegation is done by the token generation.

So the delegation I've written up should be qualified as "delegation of 
token signing" or something less of a mouthful.  I think yours sits 
squarely on top of the term Federation and should stay there.



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