Open Stack

Agreed. A user is just an account in Keystone. To echo Adam's sentiment on
Kerberos, services (i.e. Nova, Swift, etc) themselves are users of Keystone.


Guang



-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] 
Sent: Thursday, December 06, 2012 10:12 AM
To: Adam Young
Cc: OpenStack Development Mailing List; Henry Nash
Subject: Re: [openstack-dev] [Keystone] Trust Specification Updated



On 06/12/2012 14:53, Adam Young wrote:

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

Yes  but what is a user? It could be a human or an application. That is 
my point. There should be no restrictions on which type of user can 
delegate to which other type of user.

  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.

exactly. so I think we are in agreement here.

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

I would prefer that we have a clean model which is simple and clear to 
understand. We should have unconstrained delegation as well as policy 
constrained delegation. Unconstrained delegation gives the delegate 
exactly the same permissions as the delegator. Constrained gives less 
permission as determined by the delegator's policy.

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

Its just the opposite in my opinion. Trust is the more fuzzy term which 
can apply to anything. In fact you have to say what trust applies to for 
it to make any sense at all. I might trust you to write some OpenStack 
code, but I would not trust you with wife or my bank account (no offence 
meant). So trust is always qualified.

Delegation of authority on the other hand is very clear. Its about 
delegating authorisations.



  As I said, I
> consider delegation something that goes up and down an hierarchy

Well this is true in so far as anyone with more privileges than myself 
is clearly "above" me in terms of an authorisation hierarchy. But its 
not always true in terms of an organisational hierarchy, since in a 
federated world I should be able to delegate my permissions to anyone 
outside my organisation.

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

You delegate to your friend "permission" to use your car, so it clearly 
is delegation of authority.
Of course trust enters into it, since you would not delegate to an 
untrustworthy delegate. Since you are giving permission to the delegate 
to act as you (in a constrained or unconstrained way) then you need to 
trust them. But trust is a pre-condition, it is not something that is 
given to them at time of delegation. It happens before the delegation. I 
can trust you now to drive my car, without actually delegating the keys 
to you. So you are not able to drive my car even though you are trustworthy.


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

I think we have some misunderstanding here. I delegate a role to you in 
Keystone. So it is very concrete what is being delegated. If I had a key 
pair I would sign a delegation token containing the role and your name. 
However, since I dont have a key pair for the service to validate the 
delegation, I ask Keystone (which does have a key pair) to sign the 
delegation for me. Keystone will only do this if it knows that I have 
the role I want to delegate. When I simply delegate the role, this is 
unconstrained delegation, since I am giving you all the permissions that 
I have with the role. So I am not saying "anything not specified" is 
delegated. On the contrary, I am specifying everything that is delegated 
- my role. You have my full permissions as granted to my role. You dont 
need anything else to be specified since it is very clear what is being 
delegated.

However I might want to delegate LESS THAN my role to you. In this case 
we have constrained delegation, and now I should specify my delegation 
policy constraints.

So the model is very clean, very precise, and very easy to work out what 
has and what has not been delegated. I delegate my role to you in either 
an unconstrained or constrained fashion. If unconstrained I dont need to 
say what unconstrained means, since it means everything the role is 
entitled to do. If I do constrained delegation then I need to be very 
precise about how I am constraining the delegation, so extra parameters 
are needed.




>
> Also, the delegation of trust is done in the signed document.

Its delegation of authority, not delegation of trust. As I said before, 
trust is a given. I never delegate anything to someone I dont trust at 
all. I might delegate in a very constrained fashion to someone I only 
trust a little.

regards

David


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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121210/3f66070e/attachment.bin>