[openstack-dev] [Keystone] Auto user provisioning and token creation

David Chadwick d.w.chadwick at kent.ac.uk
Sat Jun 1 09:31:05 UTC 2013


In various discussions that we have had about auto user provisioning and 
token creation, it seems that there are at least three possible design 
options as follows. The purpose of this email is to generate discussion 
about the various options and agree on which one is the best one to 
pursue for the Havana release.

In the following discussion it is assumed that a user does not initially 
have an entry in the Keystone database, and that the authentication 
process has returned a session validity time for the user

Option 1.
Create a temporary user entry (i.e. a normal entry with an additional 
validity time field) with a validity time equal to the session validity 
time), then use the existing token generation code to create a token, 
with the proviso that the token validity time is not greater than the 
entry validity time

Option 2.
Create a permanent user entry, then use the existing token generation 
code to create a token, with the proviso that the token validity time is 
not greater than the session validity time

Option 3.
Dont create a user entry. From the user information obtained from the 
authentication and identification process, call the proposed new token 
generation plugin to create a token with a validity time equal to the 
session validity time. In this case, federated users will never have 
entries in Keystone's database.


Pros
Option 1. A background process can easily decide when to delete 
temporary entries, based on the dates of their validity fields.
Option 2. Does not need to change the existing user entries.
Option 3. Does not need to create or delete user entries.

Cons
Option 1. Validity time needs to be updated each time the user logs in
Option 2. User database grows to infinity. No easy way of knowing which 
entries have expired and which have not. May  need to add meta data to 
Keystone entries such as date of creation, date of last access etc. so 
that a background process can delete old entries
Option 3. Needs the token creation to be completely separate from user 
entries and not to depend upon their existence. This is something Guang 
is currently working on

Let the discussion begin!

regards

David








More information about the OpenStack-dev mailing list