Difference between revisions of "Keystone/UserIdentityMapping"
(Created page with "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 integ...") |
|||
| Line 1: | Line 1: | ||
Proposal: | Proposal: | ||
| − | This proposal contains the | + | This proposal contains the array 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). | 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 | + | The user_ids must be mappable back to the original 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. | The userid field has been standardized at 64 characters in all of the services. Going longer than that is not practical. | ||
| Line 30: | Line 30: | ||
sha256(kfrog@muppet.com@@F3CEB001) = 2352b89d16f2d1aaade9e64372d852ceac61e8ecb957fe096f249554dd1fde8f | 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 | + | Most likely, different organizations are going to request different subsets of these approachs. Thus, a the mapping strategy should be contained inside of a specific component that can be selected by the mapping backend. This has been referred to as the "Pluggable" approach. |
| + | |||
| + | The LDAP Identity Backend has the need to deconflict between multple LDAP sources. In that case, the as subset of Identity Mapping components available to the Mapping extension should be available to the Identity providers as well. | ||
| + | |||
| + | In order to map this back to the user, they are recorded in a table with the hash and original values. This should probably be a separate table from the User Table, for two reasons: | ||
| + | 1. To allow splitting Identity off into its own service eventually | ||
| + | 2. To prevent a security issue where a user with an ephemeral account somehow manages to use that account to bypass the Federated ID mechanism. | ||
Latest revision as of 18:28, 8 May 2014
Proposal:
This proposal contains the array 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 original 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
<Idp specific field> <separator> <Domain Identifier>
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
Most likely, different organizations are going to request different subsets of these approachs. Thus, a the mapping strategy should be contained inside of a specific component that can be selected by the mapping backend. This has been referred to as the "Pluggable" approach.
The LDAP Identity Backend has the need to deconflict between multple LDAP sources. In that case, the as subset of Identity Mapping components available to the Mapping extension should be available to the Identity providers as well.
In order to map this back to the user, they are recorded in a table with the hash and original values. This should probably be a separate table from the User Table, for two reasons: 1. To allow splitting Identity off into its own service eventually 2. To prevent a security issue where a user with an ephemeral account somehow manages to use that account to bypass the Federated ID mechanism.
