Open Stack

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

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.

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.

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