Open Stack

Hi Adam

I have addressed auditability in my previous post. Misuse can still be 
addressed even with transient IDs and transient users, so no further 
comments here on that issue.

In our initial implementation of FIM we did indeed create new users in 
Keystone for every new user arriving from an IDP. This has two negative 
consequences

a) we cannot deal with users with transient IDs (as can be produced by 
Shibboleth) so we have to mandate that permanent IDs are used by all 
IDPs (which Shibboleth can do). Still its a (minor) limitation.

b) we have a housekeeping problem of knowing when to delete old users 
from the user database. In our initial implementation we did not address 
this, so the database just keeps on growing unless manual intervention 
takes place. This is a tricky problem to solve. When should an entry be 
deleted? Time limits is not an adequate solution. My account at Kent has 
been active for 8 years and growing, whereas students accounts are 
deleted each year. Should the IDP notify Keystone every time its 
database is updated? Or something else?

So we thought that a better option would be to only hold transient user 
entries in Keystone for the duration of the validity time of the 
identity assertion from the IdP. This solves the user management 
problem, as well as the rights revocation problem, since a user now only 
has rights for the duration of his session. (If you want active 
revocation in the middle of a session this is a different issue.) User 
management is pushed right back to the IDP, which is the right place for 
it. The IDP keeps its user database up to date, and only current users 
will be given credentials to access Keystone.

As far as I can tell the only negative consequence is on a service which 
currently uses the user ID in its access control list. Since Keystone 
creates this ID automatically when a user entry is created, then the 
same user will have different ID for different sessions. So the user ID 
ACL system wont work without either

a) Federated Keystone having a different way of assigning unique IDs to 
user entries, so that the IDs can be the same for the same user even if 
the entry is deleted then created again, or
b) services using a different attribute type in their ACLs (one that 
still contains a permanent unique ID for the user).

regards

David


On 28/01/2013 17:50, Adam Young wrote:
> On 01/28/2013 08:20 AM, K.W.S.Siu wrote:
>> Hello,
>>
>> When Federated Identity Management is used, the authentication
>> statement issued by the external Identity Provider(s) may contain a
>> temporary (or transient) identifier for the user rather than a
>> permanent (or persistent) one. Because of this, it is not possible to
>> always uniquely identify the user each time when federated
>> authentication is used in Keystone (unless one of the user's identity
>> attributes is globally unique, such as an email address). As an
>> existing user is required to issue tokens, it is necessary to create a
>> new user each time authentication takes place which could result in
>> the backend storage becoming full of redundant data. As a solution to
>> this, we propose the addition of a validity time field in the user
>> entity which can be used to remove expired user data and allow
>> temporary users to be created based on the ID provided by the Identity
>> Provider. Determining the details of the new user account will be done
>> by the proposed attribute mapping service.
>
> That is a pretty important distinction.  It would potentially have
> impacts on Auditability.  Once you say the user object is transient, it
> n longer has an authority to address misuse, at which point it falls
> back on the organization that is Federated to Keystone. Would it be a
> cleaner solution to link the tokens with a single federated account, and
> then to use that account to create all tokens?  The tokens could have a
> subset of roles and access to a subset of endpoints based on the data
> approved by the Federated organization.  It would just be a metter of
> nailing down how the ephemera ids are issued.  I would almost want them
> to be stored in a separate table from the users, which is what the token
> table already is.
> Is it essential that we modify the user object, or are you just
> proposing it as a "path of least resistance?"
>
>>
>> At the moment we are wondering how people feel about this, and if
>> anyone has any comments or suggestions.
>>
>> Many thanks,
>> Kristy
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev