Horizon does not use the default tenant

[Ryan Richard]

If a user is part of multiple tenants and logs into the dashboard, the user will not be placed into their default tenant. It appears that they get placed into the tenant that corresponds with the last row in the user_tenant_membership table for their user.

Steps to reproduce:
Create user and place into two or more tenants.
Log into the dashboard and confirm which tenant the user logs into.
If you get dropped into a tenant that is not your default, compare with the database rows.
If you are dropped into the default tenant, try creating more tenants and changing your default tenant.

Example database entries:

mysql -B -e "select * from user where user.name=\"ryan\"" keystone -h localhost;
id name extra
05274bc19e414c2281166f512a2cf707 ryan {"password": "<SANITIZED>", "enabled": true, "email": "<email address hidden>", "tenantId": "2925dc74c18a4201a6e1e44f123e077d"}

mysql -B -e "select * from tenant where tenant.id=\"2925dc74c18a4201a6e1e44f123e077d\"" keystone -h localhost;
id name extra
2925dc74c18a4201a6e1e44f123e077d test2 {"enabled": true, "description": "test2"}

id name extra
4da033cf8df747148ddbe77799539188 demo {"enabled": "true", "description": null}

mysql -B -e "select * from user_tenant_membership where user_tenant_membership.user_id=\"05274bc19e414c2281166f512a2cf707\"" keystone -h localhost;
user_id tenant_id
05274bc19e414c2281166f512a2cf707 2925dc74c18a4201a6e1e44f123e077d
05274bc19e414c2281166f512a2cf707 305bddfe0fc7417d9e54245326f26b4f
05274bc19e414c2281166f512a2cf707 4da033cf8df747148ddbe77799539188

I will always get dropped in the demo tenant which is the last row in the database even though my "default" tenant is set to test2.

[Jay Pipes (jaypipes)]

I'd like to point out that in the extra column, the test2 "enabled" key is set to true, while the demo enabled key is set to "true". Yet another reason why putting serialized structured relational data into a BLOB/TEXT field is not a good idea.

[Jay Pipes (jaypipes)]

I believe the bug is not actually in Horizon, but one of its dependencies (which IMHO should be under Gerrit control, and in the openstack GitHub.com organization) django_openstack_auth.

The bug is here:

https://github.com/gabrielhurley/django_openstack_auth/blob/master/openstack_auth/backend.py#L95

It's popping the last tenant from the tenant list.

-jay

[Gabriel Hurley (gabriel-hurley)]

This is a long-standing know bug, and was documented in the code itself as a TODO for over a year.

The root of this is that Keystone has never sent back the default tenant during the token authentication calls, so the ONE time that information is useful we don't have access to it.

The Keystone API v3 will fix this. Until then there's nothing to be done for it.

[Gabriel Hurley (gabriel-hurley)]

@Jay: the django_keystone_auth project was written from scratch (by me) to serve as the basis not only for Horizon but for any other Django project which wants to use Keystone authentication. We can debate whether or not OpenStack wants to "own" that, but it's not just an OpenStack thing. If OpenStack would like to support the Django community more, that's cool. But I see no value in subjecting it to Gerrit unless it's becoming some sort of "core" component.

That said, it's BSD licensed, so if OpenStack wants to fork it (and maintain my license) I can't stop that. I believe in Open Source :-)

[Jay Pipes (jaypipes)]

Gabriel, I like the django_openstack_auth code very much; I was just disappointed that:

a) it took me so long to figure out how auth was done in horizon. This is everything to do with my lack of knowledge and nothing to do with you :)
b) we need two different bug trackers for this -- see my pull request on the github.com repo.

I *think* we can mark this bug as actually not affecting Horizon, though, right? I mean, the Keystone v3 API will "fix" this, and the only code that will need to change is the django_openstack_auth code, which is not part of Horizon.

Would you agree? If so, probably best to just change the project from Horizon to Keystone?
Best,
-jay

[Gabriel Hurley (gabriel-hurley)]

Ah, that's true. However, I think I'll leave this here as a reminder just on principle. We can close it when it's implemented and verified.

I *think* there's another Keystone ticket about this... but I can't find it off the top of my head. Adding keystone to this ticket couldn't hurt, I guess.

[Dolph Mathews (dolph)]

We changed this behavior in Grizzly not only in v3, but also in v2. Default tenancy used to be assumed by auth_token but is now applied by keystone during auth.

A default tenant_id attribute on a user no longer grants implicit authorization on a project but instead is assumed as the user's default auth scope of one is not specified. A role must exist to grant the user any authorization on that project or auth will fail.

I'm actually targeting this issue at RC1 because I'm not aware of test coverage of this behavior and I'd like to ensure we have some before it ships -- otherwise the above is just lies :)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/24473

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/24473
Committed: http://github.com/openstack/keystone/commit/7c07de189335571bacced5a1d9a0de2f4c8dcecf
Submitter: Jenkins
Branch: master

commit 7c07de189335571bacced5a1d9a0de2f4c8dcecf
Author: Dolph Mathews <email address hidden>
Date: Mon Mar 18 08:22:01 2013 -0500

    Test default_project_id scoping (bug 1023502)

    Change-Id: I14361812980e27b6d3365055586c264e48a25a3b

[Lin Hua Cheng (lin-hua-cheng)]

Horizon would be able to only support this for KS V3.

Keystone V3 automatically scopes the user to the default project on authentication. This has been included in the implementation of Horizon support for Keystone V3: https://blueprints.launchpad.net/horizon/+spec/login-domain-support

For Keystone V2, it requires getting the user details first to get the default tenant id from its metadata. However, the User API requires admin privilege. It would not be possible to support this in Horizon for V2 without storing an admin credential just for calling the User API. This won't be supported for V2.

Code can be reviewed in https://github.com/gabrielhurley/django_openstack_auth/pull/47

[Gabriel Hurley (gabriel-hurley)]

I'm going to close this in favor of the v3 Login Support blueprint, since they're one and the same. Hopefully we'll have that blueprint unblocked and finished soon...

[Jordan Callicoat (jcallicoat)]

The work was completed on the blueprint and it was merged for Havana. https://review.openstack.org/#/c/21942/

Can the keystone client work be backported to Grizzly?

[Dolph Mathews (dolph)]

Jordan: the change you linked is a new feature on python-keystoneclient which should support grizzly. There's nothing to backport there.

[Alexander Bozhenko (alexbozhenko)]

Using v3 keystone api address this issue.
http://fosshelp.blogspot.ru/2014/01/openstack-configure-horizon-keystone-v3.html

Is there are any reasons, why v3 is not default option for horizon?

[Julie Pichon (jpichon)]

IIRC setting v3 to be the default caused authorisation issues with the other services, particularly when not using the Default domain.

See https://bugs.launchpad.net/django-openstack-auth/+bug/1294396 for some additional information, I'm not aware if the concerns raised at the time have been resolved in the other projects or the current status.

[Alexander Bozhenko (alexbozhenko)]

So, it is fixed in v3, but v3 is not used by default, even in Kilo, right?

When a lot of users have a default project, set by "last row in the user_tenant_membership table", and that project is disabled, all those users failed to login to horizon at all. And it will be fixed only by changing "last row in the user_tenant_membership table" for all users(

[Huachao Mao (huachaomao)]

Is this really fixed in Ocata, since I found django_openstack_auth code still doesn't use the default project id when select a project to get a project scoped token.

[Jesper Schmitz Mouridsen (jsmdk)]

This seems to me to be the case on Pike as well, e.g the default_project_id is not chosen when logging in to horizon. Horizon is configured for keystone v3. The user is a role Member of all projects, including the default one.