On Sun, Nov 24, 2013 at 9:39 PM, Adam Young <ayo...@redhat.com> wrote:
> The #1 pain point I hear from people in the field is that they need to > consume read only LDAP but have service users in something Keystone > specific. We are close to having this, but we have not closed the loop. > This was something that was Henry's to drive home to completion. Do we > have a plan? Federation depends on this, I think, but this problem stands > alone. > I'm still thinking through the idea of having keystone natively federate to itself out of the box, where keystone presents itself as an IdP (primarily for service users). It sounds like a simpler architectural solution than having to shuffle around code paths for both federated identities and local identities. > > Two Solutions: > 1 always require domain ID along with the user id for role assignments. > >From an API perspective, how? (while still allowing for cross-domain role assignments) > 2 provide some way to parse from the user ID what domain it is. > I think you meant this one the other way around: Determine the domain given the user ID. > > I was thinking that we could do something along the lines of 2 where we > provide "domain specific user_id prefix" for example, if there is just > one ldpa service, and they wanted to prefix anyting out of ldap with "ldap@", > then an id would be "prefix" "field from LDAP". And would be configured > on a per domain basis. THis would be optional. > > The weakness is that itbe Log N to determine which Domain a user_id came > from. A better approach would be to use a divider, like '@' and then > prefix would be the key for a hashtable lookup. Since it is optional, > domains could still be stored in SQL and user_ids could be uuids. > > One problem is if someone comes by later an "must" use email address as > the userid, the @ would mess them up. So The default divider should be > something URL safe but no likely to be part of a userid. I realize that it > might be impossible to match this criterion. > For usernames, sure... but I don't know why anyone would care to use email addresses as ID's. > > Actually, there might be other reasons to forbid @ signs from IDs, as they > look like phishing attempts in URLs. > Phishing attempts?? They need to be encoded anyway... > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev