On 4 Dec 2013, at 13:28, Dolph Mathews <[email protected]> wrote:
> > On Sun, Nov 24, 2013 at 9:39 PM, Adam Young <[email protected]> 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. > I know this sounds a bit like "back to the future', but how about we make a user_id passed via the API a structured binary field, containing a concatenation of domain_id and (the actual) user_id, but rather than have a separator, encode the start positions in the first few digits, e.g. something like: Digit # Meaning 0-1 Start position of domain_id, (e.g. this will usually be 4) 2-3 Start position of user_id 4-N domain_id M-end user_id We would run a migration that would convert all existing mappings. Further, we would ensure (with padding if necessary) that this "new" user_id is ALWAYS larger than 64chars - hence we could easily detect which type of ID we had. > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > > -Dolph > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
