In support of https://blueprints.launchpad.net/keystone/+spec/pluggable-remote-user https://blueprints.launchpad.net/keystone/+spec/split-identity https://blueprints.launchpad.net/keystone/+spec/federation We need to figure out what we are going to do when the Identity Backend is read only. We need to be able to map the usersIds There are three identified options: 1. Have a remapping table 2. Try domains one by one (exclusively for lookup, never attempt auth) 3. Agree on a naming convention so that we can deduce domain from the name Option 3 is preferred, as it allows OpenStack to use the pre-existing Unique identifiers. Since public clouds will have to support arbitrary email -> domain mappings or oauth, it might not be simple to map this to a SQL backend implementation. However, for those instances, it should be possible to use the email address as username and continue to use the UUID as the User Id. Is there any compelling reason to create a "shadow" entry in Keystone? It seems that any temporary entries should be role assignments, not user entries. Written up here: https://etherpad.openstack.org/mapping-user-ids -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/a247aba8/attachment.html>