yahoo-eng-team team mailing list archive

[Adam Young <1505256@xxxxxxxxxxxxxxxxxx>]

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