Comment 19 for bug 1577996

I've been letting Lance drive it since it is his choice to drive on with
system scoping. What projects are checking is-admin-project so far?

On Wed, Jun 13, 2018, 10:40 PM Jamie Lennox <email address hidden> wrote:

> There are a couple of projects already enforcing on is_admin_project,
> they just do it manually and the outstanding oslo.policy bit was just a
> helper to make that a bit neater.
>
> I'm not sure what the migration plan is from is_admin_project -> system
> scope. My guess would be the admin_project is the same as system for a
> while? If so it would probably be worth waiting to see what happens in
> oslo.policy to check system scope and just include the is_admin_project
> compatibility in that. No point giving a new feature under an old name.
>
> --
> You received this bug notification because you are subscribed to
> OpenStack Identity (keystone).
> Matching subscriptions: keystone-bugs
> 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:
> Fix Released
> Status in oslo.context:
> Fix Released
> Status in oslo.policy:
> Confirmed
>
> 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
>