Open Stack

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.

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