Inside multi (Keystone) endpoint environment Horizon logs into incorrect region

Bug #1506825 reported by Timur Sufiev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Won't Fix
Undecided
Unassigned

Bug Description

A. Consider a Horizon setup which knows about 2 Keystone endpoints (setting AVAILABLE_REGIONS, I'm refraining from using it because it'll change in future, see bug 1494251). And each of these Keystone endpoints has 2 service region within it, but these service regions a different, for example RegionOne and RegionTwo in Keystone1 and RegionNorth and RegionSouth in Keystone2. Currently last service region selected is stored in cookies, that means that if User first selects RegionSouth in Keystone2, then signs out and logs in into Keystone1 where he by default placed into RegionOne (effectively saving this new region in cookies), then, he returns back to Keystone2 his RegionSouth choice is lost.

B. Another specific setup with multi-endpoint Keystone is when within Keystone1 Region1 is the own Keystone1 cloud and Region2 are the resources of the Keystone2 own cloud, and for Keystone2 situation is the same - Region1 are foreign resources, Region2 are local ones. In that case most deployers would like to default to Region1 when logging into Keystone1 endpoint and default to Region2 when logging into Keystone2 endpoint.

The proposed solution is to
* make a default selection of a service region based on the endpoint User is logging in (fixes B)
* save last service region in a per-endpoint cookie (fixes A)

Revision history for this message
Timur Sufiev (tsufiev-x) wrote :

Please note that there also exists bug 1359774 which tries to remedy a different problem in a different way, not compatible with this one.

Revision history for this message
Timur Sufiev (tsufiev-x) wrote :
Revision history for this message
Timur Sufiev (tsufiev-x) wrote :

I've discussed use case B with our Keystone team and seems that it's impossible to support such a use case in Keystone until Federation is fully implemented. (Or at least implement it w/o severe security implications related to token revocation). Since this use case was the main reason of implementing the Horizon support, I'm changing this to Won't Fix for now.

Changed in horizon:
status: New → Won't Fix
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on horizon (master)

Change abandoned by Timur Sufiev (<email address hidden>) on branch: master
Review: https://review.openstack.org/235240
Reason: The related bug was set to Won't Fix.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to horizon (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/478404

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to horizon (master)

Reviewed: https://review.openstack.org/478404
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=d8f95c64d64c1675dfbc32122cf1e418f1477a6c
Submitter: Jenkins
Branch: master

commit d8f95c64d64c1675dfbc32122cf1e418f1477a6c
Author: Timur Sufiev <email address hidden>
Date: Mon Oct 12 10:07:47 2015 -0700

    Introduce DEFAULT_SERVICE_REGIONS

    It should be together with related change in django-openstack-auth, if
    specified it will change the default service region calculation: it
    will be taken from this setting (on a per-endpont basis) instead of a
    value stored in cookies. This value is still checked for sanity,
    i.e. it should be present in Keystone service catalog.

    Change-Id: I7e36f766870793f3e8fc391a06f0ee49deaa7add
    Related-Bug: #1506825
    Closes-Bug: #1703390

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.