Open Stack

On Sun, Nov 24, 2013 at 9:39 PM, Adam Young <ayoung at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/8144883d/attachment.html>