Open Stack

Hi David,

So this question is relates exactly to the point I am at trying to re-write the auth-roleassignment-domain blue print.  Not yet complete, but here, as food for thought, are three new diagrams I am adding that try and show how we re-cast the current identity components ready for the mix of internal and external "providers" that we want to enable:

First, the case for an all-internal solution:



Second, what happens if we have external authentication only:


...and finally, potentially, for both auth and role assignment being external:


The question I am trying to thinking through (and which relates to your question as well), is how much "internal support" remains for users/role assignments etc. as these functions are provided externally?  Do we need to still support "openstack only  users/roles"?  For example service users...a corporate LDAP/IDP might not contain these.  Also, might a cloud provider want a way of preventing a given user authenticating (what ever the external authority says).  Would you do this by a black list, or just allow the creation of an internal (to keystone) user entity that was disabled...and have internal user entities "override" the external permissions?  

Hope to have this nailed and included in the BP this week.

Henry
On 1 Jun 2013, at 10:31, David Chadwick wrote:

> 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
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/c6f0acf4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Keystone Stores.jpg
Type: image/jpg
Size: 113013 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/c6f0acf4/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Keystone Stores II Auth.jpg
Type: image/jpg
Size: 90558 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/c6f0acf4/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Keystone Stores II Ext Auth and RA.jpg
Type: image/jpg
Size: 116054 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/c6f0acf4/attachment-0005.jpg>