[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