[openstack-dev] [Keystone] Trust Specification Updated

David Chadwick d.w.chadwick at kent.ac.uk
Wed Dec 5 17:18:55 UTC 2012

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



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

More information about the OpenStack-dev mailing list