Open Stack

On 12/19/2012 11:51 AM, David Chadwick wrote:
> Hi Adam
>
> I am slightly confused. Your latest message indicates that nothing 
> further needs to be done, but your previous message indicated that 
> something needs to be done and I should update the attribute mapping 
> blueprint.
My last message was in regard to continuing to evolve the design of 
Keystone.  we need only to deal with revoking tokens upon role changes.  
Longer term, I want to see the changes I outlined in my last email.  
Trusts are not in yet,  tokens are long lived, and we have to deal with 
token revocation.  We have mechanisms for all that, we just need to make 
sure mapping and groups make use of them.


>
> So which is it?
>
> regards
>
> David
>
>
> On 19/12/2012 16:29, Adam Young wrote:
>> On 12/19/2012 11:18 AM, David Chadwick wrote:
>>> Hi Adam
>>>
>>> I propose the following
>>>
>>> 1. When a remote administrator in a federation alters the attributes
>>> or credentials of a user at an IdP, then this change only becomes
>>> active and noticed by service providers (such as OpenStack) when the
>>> user tries to login again to a service. He will now get his new
>>> attributes or authentication status and not his old ones. There is
>>> obviously some time delay between the change occurring at the IDP and
>>> the change being noted by an SP, but this time delay is kept small by
>>> making the authentication and attribute assertions from the IDP have
>>> relatively short durations. This is why SAML uses short lived
>>> assertions and does not provide any mechanism for long lived tokens
>>> and revocation. Even if you switched to using X.509 PKCs it would not
>>> help, since there is a time delay between revoking a key pair and it
>>> becoming active in the CRL, due to the issuing period between CRLs. So
>>> this time delay is something we currently have to live with.
>>>
>>> 2. When an administrator logs into Keystone and modifies some of the
>>> configuration parameters, such as attribute mappings, or credential
>>> validation rules, or group assignments, then we do have the ability to
>>> activate this almost immediately by notifying the token validation
>>> service to check that the user's token has not been revoked when the
>>> user next uses his token at a service endpoint. I suggest that we
>>> introduce a general purpose notification mechanism that can be used by
>>> all configuration services. We need a blueprint for this, but I
>>> suggest it may be something like this:
>>>
>>> 1. We clearly specify the APIs for token creation and validation (I
>>> discussed this in my post to the list yesterday)
>>>
>>> 2. We specify a new method/API for the token validation service which
>>> receives a message of the form: attribute X has been deleted/modified
>>> at time Y, where attribute X could be a role, tenant, domain (or any
>>> OpenStack attribute that is used in authorisation at the PDP).
>>
>> We have the token revocation list right now.  If tokens become short
>> lived, I think neither implementation is really necessary.
>>
>> If a scoped token life span is short (say a minute)  then changes in
>> roles are irrelevant. By  the time the change propagates through the
>> system the token would have timed out anyway.
>>
>> With trusts, the need for long lived tokens go away.
>>
>> I just don't trust that people will crank down the lifespan of tokens
>> until they understand how trusts need to be set up, etc.  I see token
>> revocation as a stop-gap measure.
>>
>>>
>>> 3. When validate token is called by a service, it checks if the user's
>>> role/tenant/domain etc is in the list of modified ones, and if the
>>> time of initial token creation was before Y. If it is, then the token
>>> validation service returns an error to the calling service of
>>> "reauthorise user". This will cause the user to have to log in again
>>> to Keystone.
>>
>> If only unscoped tokens are long lived, and unscoped tokens don't have
>> role information on them, the whole issue becomes moot, too.
>>
>>>
>>> 4. When time Y has expired ie. current time - Y is longer than token
>>> validity period, then delete attribute X from the list of modified
>>> attributes.
>> I can appreciate this mechanism, but I think it might be more than we
>> really need.
>>
>>
>>>
>>> 5. Every API that provides a configuration ability to administrators,
>>> uses its own internal logic to determine if the configuration change
>>> is likely to remove any privileges from any active users. If it is, it
>>> sends the appropriate notification message to the token validation
>>> service.
>>
>>
>>
>>>
>>> regards
>>>
>>> David
>>>
>>>
>>> On 19/12/2012 15:40, Adam Young wrote:
>>>> On 12/19/2012 09:56 AM, David Chadwick wrote:
>>>>> Hi Adam
>>>>>
>>>>> I believe our attribute mapping work is orthogonal to and
>>>>> independent of
>>>>> revocation of roles or tokens, since attribute mapping takes place
>>>>> before the token is created. if a role is revoked subsequently to it
>>>>> being assigned by the attribute mapping service, then it will remain
>>>>> revoked.
>>>>>
>>>>> What could potentially effect the mapping, is if the user's
>>>>> organisational attributes (or group memberships, if groups were to 
>>>>> use
>>>>> mappings) are revoked whilst he is accessing the cloud. Currently 
>>>>> this
>>>>> would not cause his current session to be terminated or his mapped
>>>>> roles to be revoked since there is no mechanism for the IDP to inform
>>>>> OpenStack about this. But when the user tries to activate a new
>>>>> session he would not be able to since he would no longer have the
>>>>> correct organisational attributes (or groups) and could therefore no
>>>>> longer be assigned a role.
>>>>>
>>>>> However, I need you to answer one question
>>>>>
>>>>> You said " When a users roles change,..." How do they change? Who
>>>>> changes them and how
>>>> It would need to happen when either the user attribute changes, or the
>>>> mapping changes.  Whenever a user would no longer have a role that 
>>>> they
>>>> used to have, all tokens that would have had that role need to be
>>>> revoked.
>>>>
>>>> Say a user is a member of group admins.  Then they get promoted. They
>>>> are removed from admins, and added to supervisors.
>>>>
>>>> both admins and supervisors  have the role "VMManagers" that allows
>>>> them to do things like create new vms and so forth, as enforced by
>>>> RBAC.  But we realize that we should not  trust managers to do 
>>>> this. So
>>>> we unmap the role "VMManagers" from the group "supervisors." All 
>>>> tokens
>>>> for supervisors must now be revoked.
>>>>
>>>>
>>>> Now when a user is promoted from admin to supervisor, we change their
>>>> group membership, and their tokens must be revoked at that point.
>>>>
>>>>
>>>> Both are "role changes" and both are revokable events.
>>>>
>>>>>
>>>>> regards
>>>>>
>>>>> David
>>>>>
>>>>> On 19/12/2012 14:30, Henry Nash wrote:
>>>>>> Hi Adam,
>>>>>>
>>>>>> Quite right.  The api blueprint for user groups specifies that this
>>>>>> should happen (Dolph had been reviewing this) and the server code is
>>>>>> using the same revoke mechanism that happens when a user role
>>>>>> changes. I'll see if I can refactor this so it is more general and
>>>>>> will then be obvious how we could plug in the mapping triggers.
>>>>>>
>>>>>> Henry On 19 Dec 2012, at 14:25, Adam Young wrote:
>>>>>>
>>>>>>> Since both of you are working on stuff invloving how Roles are
>>>>>>> assigned to users, I want you to both be aware of an important
>>>>>>> issue.  When a users roles change, their tokens get invalidated.
>>>>>>> Since both the group and mapping blueprints will affect Role
>>>>>>> assignments, both can have significant effects on the number of
>>>>>>> users whose tokens get revoked.
>>>>>>>
>>>>>>>
>>>>>>> Please update both of your blueprints to reflect this. We will
>>>>>>> need a common mechanism for determining which tokens to revoke.
>>>>>>>
>>>>>>> This must happen before anything that changes  role assignments can
>>>>>>> be merged.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ OpenStack-dev 
>>>>>> mailing
>>>>>> list OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>
>>