Public bug reported:
User Ids cannot be something sepcified entirely by the Federation
providers. If they are, there are a handful of potential problems:
1. The userId specified will be too big for the colum (varchar 64)
2. Two different Identity Providers can provide the same value for user_id
The solution is to use the id_mapping capability of the identity
backend. This should be enabled on a per-idp basis, and the default
should be enabled.
The id_mapping approach needs a separate domain_id to deconflict
userids. This domain should be created by default and linked 1-to-1
with the IdP id.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1505256
Title:
Potential user_id collision between Federated IdPs
Status in Keystone:
New
Bug description:
User Ids cannot be something sepcified entirely by the Federation
providers. If they are, there are a handful of potential problems:
1. The userId specified will be too big for the colum (varchar 64)
2. Two different Identity Providers can provide the same value for user_id
The solution is to use the id_mapping capability of the identity
backend. This should be enabled on a per-idp basis, and the default
should be enabled.
The id_mapping approach needs a separate domain_id to deconflict
userids. This domain should be created by default and linked 1-to-1
with the IdP id.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1505256/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
