On 12/04/2013 12:35 PM, Henry Nash wrote:
On 4 Dec 2013, at 13:28, Dolph Mathews <[email protected]
<mailto:[email protected]>> wrote:
On Sun, Nov 24, 2013 at 9:39 PM, Adam Young <[email protected]
<mailto:[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:
This might be the most insane idea I have heard all day. I love it.
Digit #Meaning
0-1Start position of domain_id, (e.g. this will usually be 4)
2-3Start position of user_id
4-Ndomain_id
M-enduser_id
I suspect it is more of a brainstorming attempt than as an actual
proposal. It can't be binary for many reasons, and strings parsing gets
wonky, especially if you assume utf-8 is in there (how many bytes per
character?)
The interesting idea is appending the domain id instead of prepending
it. It may be an irrelevant change, but worth mulling.
An interesting approach would be to do domain prepended user ids using
/ so that
user/domain is the ID, and then the URL would be automagically
segmented: If they leave off the domain, then the userid by itself
would still be valid.
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]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-Dolph
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
