yahoo-eng-team team mailing list archive

[OpenStack Infra <1577996@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/314409
Committed: https://git.openstack.org/cgit/openstack/keystoneauth/commit/?id=ed7586380732842a0b52236a59499d191033ef11
Submitter: Jenkins
Branch:    master

commit ed7586380732842a0b52236a59499d191033ef11
Author: Jamie Lennox <jamielennox@xxxxxxxxx>
Date:   Tue May 10 14:10:52 2016 +1000

    Expose is_admin_project in AccessInfo
    
    There is currently incomplete is_admin_project information in the token.
    We can expose this already via keystoneauth because we have to handle
    the default case where there is nothing in the token.
    
    The default feels backwards but to handle the historical situation where
    a deployment has not got the admin_project set all projects were in the
    admin project so it must default to true for policy enforcement.
    
    Adds the fixture handling as well for testing with this enabled.
    
    Change-Id: I58db52427a2bac6cd56794429559771499dc7f5a
    Closes-Bug: #1577996


** Changed in: keystoneauth
       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):
  In Progress
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