Open Stack

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