Open Stack

Hi Guang

Federated Identity Management requires a new way of thinking. Forget 
about unique IDs as being the only way of identifying users, and instead 
think about identity attributes as identifying users. This is a much 
more powerful model, and it is a superset of the unique ID model, since 
one of the identity attributes can be a unique ID. However, the unique 
ID would only be one of many different attributes that can be used for 
identification and authorisation. So for example, you can have a 
resource that is available to "employees of org X", another to "users 
over 18, with red hair, married, and with 2 children", and another to 
"user with unique ID 123". So Swift, Glance etc. can still use their 
existing access control models, providing that either Keystone makes 
some mods to how the existing unique IDs are assigned, or the services 
use a different attribute type to represent the unique ID. We are not 
removing unique IDs, we are saying that user entries in Keystone are 
transient, since the authn and attribute assertions from the IDPs are 
transient. This significantly simplifies the user management task ie. it 
removes it entirely from Keystone and places the responsibility on the 
IDPs instead. So this is a major gain for the Keystone administrator.

Auditing is a different issue. This is always possible with ephemeral 
IDs as well as permanent IDs, providing the information is logged and 
the logs are stored securely. It does however require the service 
provider to liaise with the identity provider to ask "which user did you 
assign ephemeral ID 345 to at a specific date and time?". But this is 
part of the trust relationship of FIM. The service trusts the IDP to 
manage users and in return it does not need to. So the service gains 
significantly, but tracing actual users in case of abuse requires 
cooperation with the IDP. Note however, that the service can always 
alter its access controls to ban abusive users at any time. This process 
is not being altered.

regards

David


On 28/01/2013 19:05, Yee, Guang wrote:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>