Open Stack

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