This session will include the following subject(s):
Identity Providers:
LDAP, SAML, and The SQL Identity Backend all have assumptions about how IDs should be allocated. This session will discuss how to ensure they can interoperate in a single Keystone instance.
(Session proposed by Adam Young)
Identity IDs in a multi-backend or Federated world:
Today, our SQL and LDAP backends can produce very different formats for ID (e.g. 32 char UUID for SQL, while some arbitrary 64 char string for LDAP). In addition we have the requirement to enable keystone to route an API call with just an entity ID as a parameter to the relevant backend serving it (for example when we have an LDAP per domain). We discussed two solutions during the IceHouse development (a mapping table or encoding the domain into the Identity ID - both we coded, but in the end decided to wait to allow more discussion). Some other folks would like keystone to essentially hide the real format of the identifier behind a "as small as possible" ID for efficiency and security point of view. Time to plot our course for Juno!