yahoo-eng-team team mailing list archive

[Pavlo Shchelokovskyy <2115353@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

As already mentioned, in https://bugs.launchpad.net/horizon/+bug/2067075,
when multidomain support is enabled in Horizon, and user happens to also be an admin in the domain its user belongs to (the actual check is for this is also broken btw, afaiu it always returns True),
specifically on requests to Keystone API (not auth, but management of domains, projects, etc) Horizon will silently swap the 'project' token of the user to the domain token (for the domain of the user).

The problem is that this reliably works only with default policies, where "cloud admin" (the most elevated user of the openstack APIs) is simply 'role:admin' check.
But when you start fiddling with those policies and e.g. limit who the cloud admin is, this logic in Horizon breaks UI.

For example, if I set admin to be 'admin in admin project' - AFAIU quite
the standard way of limiting the admin-ness in the cloud, policy change
to keystone is 'admin_required: (role:admin and is_admin_project:True)
or is_admin:1', when I now log in as presumably cloud admin, I can not
access most of Identity panels any more, as those calls are silently
switched to domain token and that is no longer in fact the 'cloud admin'
even if it has admin role (in that domain), and thus project list, role
list, group list etc are blocked.

TBH I don't know why this token scope swap was implemented in the first place.
But given that this token scope swap is quite brittle, IMO it should at least be possible to opt out of it.
Horizon already has possibility of switching to explicit domain scope in the domains panel.

** Affects: horizon
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2115353

Title:
  Token swap to domain is brittle and very sensitive to policies in use

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  As already mentioned, in https://bugs.launchpad.net/horizon/+bug/2067075,
  when multidomain support is enabled in Horizon, and user happens to also be an admin in the domain its user belongs to (the actual check is for this is also broken btw, afaiu it always returns True),
  specifically on requests to Keystone API (not auth, but management of domains, projects, etc) Horizon will silently swap the 'project' token of the user to the domain token (for the domain of the user).

  The problem is that this reliably works only with default policies, where "cloud admin" (the most elevated user of the openstack APIs) is simply 'role:admin' check.
  But when you start fiddling with those policies and e.g. limit who the cloud admin is, this logic in Horizon breaks UI.

  For example, if I set admin to be 'admin in admin project' - AFAIU
  quite the standard way of limiting the admin-ness in the cloud, policy
  change to keystone is 'admin_required: (role:admin and
  is_admin_project:True) or is_admin:1', when I now log in as presumably
  cloud admin, I can not access most of Identity panels any more, as
  those calls are silently switched to domain token and that is no
  longer in fact the 'cloud admin' even if it has admin role (in that
  domain), and thus project list, role list, group list etc are blocked.

  TBH I don't know why this token scope swap was implemented in the first place.
  But given that this token scope swap is quite brittle, IMO it should at least be possible to opt out of it.
  Horizon already has possibility of switching to explicit domain scope in the domains panel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2115353/+subscriptions