Open Stack

Hi Adam

the rationale for having unconstrained delegation is that if I delegate 
to you one of my roles, then in the simplest unconstrained case I want 
you to have all the privileges that I have from this role, so that you 
can carry out the full functions of that role.

If I want to constrain you then I add some policy constraints.

I think this is the cleanest model and easiest to comprehend

regards

David


On 05/12/2012 14:55, Adam Young wrote:
> On 12/05/2012 05:01 AM, David Chadwick wrote:
>> Hi Adam
>>
>> thinking again about the implementation of delegation/trusts and the
>> defaults for the various parameters, we have essentially two different
>> types of parameters: the attributes being delegated and the policy
>> constraints on this delegation.
>>
>> The attributes currently comprise the tenant and role(s).
>> The policy constraints comprise: endpoints, duration, delegation depth
>> etc. New constraints may be added with time as user demand requires.
>>
>> We should consider two types of delegation: unconstrained where the
>> policy constraints are missing (actually default values apply), and
>> constrained where non-default values for the various policy parameters
>> are provided by the delegator.
>>
>> This means that several changes will need to be made to the current spec.
>>
>> 1. All policy constraints should be optional parameters
>> 2. All policy constraints should have default values which do not
>> constrain the delegation
>>
>> The above mean for example that endpoints should become optional, and
>> delegation depth default should be infinity not zero.
> Basically I agree, but,  I think you will need to argue harder for me to
> accept these as the defaults.  I would state that the default should be
> as restrictive as possible, and anything that goes more permissive needs
> to be explicit.
>
> However, that will be enforced by policy, not by the token generation
> scheme.  Thus, it is up to the Policy [ Decision or Administration ]
> Point to set the defaults for unspecified Attributes.
>
> What is your rationale for "all" being the default?  Is it the fact that
> "unspecified" attributes will make tokens useless, as there will be
> potential attributes against which it is not explicitly enabled?  If
> that is the case, then we need a policy for token generation that is
> also configurable, which states the acceptable values for attributes in
> a token.  So, while a token with no endpoint specified is not limited to
> an endpoint, such a token should be invalid from a creation standpoint.
> However, I would still want to be able to put a rule in place that says
> such a token is invalid.
>
>
>>
>> Comments please
>>
>> David
>>
>> On 04/12/2012 14:57, Adam Young wrote:
>>> On 12/04/2012 05:48 AM, David Chadwick wrote:
>>>> Hi Adam
>>>>
>>>> in terms of delegation duration, it is more common to specify a start
>>>> time (defaults to now) and an end time (defaults to infinity) rather
>>>> than a delta (which implies a start time of now in every case)
>>> Good point.  Updated
>>>
>>>>
>>>> regards
>>>>
>>>> David
>>>>
>>>>
>>>> On 04/12/2012 04:16, Adam Young wrote:
>>>>> 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
>>>>>
>>>
>