← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1577996] Re: Unable to distinguish between not is_admin_project and feature not enabled

 

Reviewed:  https://review.openstack.org/312323
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ed634e8cdcdf385b749bbb9e951104989a020277
Submitter: Jenkins
Branch:    master

commit ed634e8cdcdf385b749bbb9e951104989a020277
Author: Jamie Lennox <jamielennox@xxxxxxxxx>
Date:   Wed May 4 14:30:56 2016 +1000

    Always add is_admin_project if admin project defined
    
    By only setting is_admin_project in the token if it is true we are
    unable to distinguish in policy enforcement if the admin project is not
    defined in configuration or if the current scope is not the admin
    project.
    
    If the admin project is defined in config we should always set the
    is_admin_project in the token either true or false so we can provide
    backwards compatible policy files in projects.
    
    Change-Id: Icdfc4f4792422af9d844004c2c92993c9065134d
    Closes-Bug: #1577996


** Changed in: keystone
       Status: In Progress => Fix Released

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

Title:
  Unable to distinguish between not is_admin_project and feature not
  enabled

Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  New

Bug description:
  The is_admin_project flag is used in a token to indicate that the
  current token is scoped to a project that is indicated as the admin
  project. Currently this is only added to the token when the
  admin_project is True and nothing added when False.

  From a policy perspective we need to write policy files that are
  backwards compatible, however we cannot determine the difference in
  policy between is_admin_project == False and the admin project not
  being set from config because both result in no flag being set in the
  token.

  If we were to enforce is_admin_project == True on a deployment that
  did not use it this would completely break backwards compatibility as
  the is_admin_project check would never pass.

  To fix this we need to make is_admin_project a required field of a
  token at least when the admin project is set.

  Because the current default is that every project can be the admin
  project, the default value of is_admin_project must be True. For
  deployments that do not configure an admin project we can either set
  is_admin_project=True for every project, or we can exclude the field
  from the token. I think exclude makes sense because the check from a
  policy perspective is going to have to default to True for backwards
  compatibility and you can then tell from a token whether the
  admin_project concept is in use (i'm not sure if this is an
  information leakage problem - please comment on preference).

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


References