Keystone/UserIdentityMapping

Proposal:

This proposal contains the arry of options. As we determine the correct approach, it will change until it reflects the actual design.

Openstack requires the integration of multiple Identity Providers together in a single Keystone Instance. The Domain administrators need the ability to configure the mapping to compse the user identitfier (user_id) field. However, since this is a globally unique field, it needs to be composed of a portion that is managed by the Keystone administator in order to ensure there is no conflict between userids assigned by two different Identity providers (IdP).

The user_ids must be mappable back to the origianl users for auditing purposes.

The userid field has been standardized at 64 characters in all of the services. Going longer than that is not practical.

One IdP will contain one or more domains. Users will still be managed at the domain level.

The preferred approach would require no additional data stored in the keystone instance. To get to a form like that, the fieled would be compsed of

The separator should be URL safe. The proposed character is the at sign: @ . However, som exisitng deployments may use email addresses as the IdP specific field. In this case the separator would be a double at sign: @@

The domain Identifier can be either the domain name or a UUID domain ID.

If Kerberos is in Use, the ful Kerberos Principal is an ideal candidate for a userid. For example, if the User Kermit Frog had a uid of kfrog at the MUPPET.COM domain:

kfrog@MUPPET.COM

If, however, email addresses had been used, and the email addresses were from various providers, a UUID based scheme would look like this: kfrog@muppet.com@@F3CEB001

If the deployment wishes to anonymize the account, a hash of the field can be used instead:

sha256(kfrog@muppet.com@@F3CEB001) = 2352b89d16f2d1aaade9e64372d852ceac61e8ecb957fe096f249554dd1fde8f

In order to map this back to the user, they are recorded in a table with the hash and original values