Open Stack

Not just auditability. I think static user ID/name plays an important role
in the entire stack. Can you please elaborate on how does ephemeral user IDs
play together with Swift, Nova, Glance, Quantum, etc? Take Swift ACL for
instance, how would one define a Swift ACL with ephemeral user ID?



Guang


-----Original Message-----
From: Adam Young [mailto:ayoung at redhat.com] 
Sent: Monday, January 28, 2013 9:50 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Keystone] Federated Identity Management and
user creation

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130128/1094b31e/attachment.bin>