RFE: policy enforcement should accept context objects

Bug #1779172 reported by Lance Bragstad on 2018-06-28
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
oslo.policy
Undecided
Lance Bragstad

Bug Description

Oslo.policy's Enforcer object has a method called ``enforce`` that is used by services to check if a user is authorized to do something or not. It does this by comparing information about the user to information about what the user is trying to do. The information about the user is passed to the method as the ``creds`` parameter and the information about what they are trying to do is passed in as the ``target`` and ``action`` parameters.

Currently, oslo.policy assumes the ``creds`` parameter to be a dictionary of information about a user [1], which is extremely vague. It's really up to the service to make sure things are populated accordingly in ``creds`` before calling ``enforce()``. In some cases, service might not even pass anything to at all.

Fortunately, a lot of what is passed in the ``creds`` dictionary is actually information that is standardized with oslo.context objects [2]. A possible improvement we could make would be to teach oslo.policy how to handle instances of oslo.context.context.RequestContext for policy enforcement.

The benefit of this is that it lowers the bar for consistent policy enforcement across services. This is because keystonemiddleware typically sits in front of OpenStack services and validates tokens used for the request. Upon successful validation of the token, keystonemiddleware will set specific headers for this information in the request. If a service uses oslo.context to build context objects from request environments [3], these headers are processed automatically and those values are exposed on the context objects as attributes for the service to use.

The only thing left for the service to do is to pass an instance of RequestContext to the oslo.policy library. This makes it easier to consume large changes like system scope because it doesn't require *each* service to set a specific attribute in their implementation of ``creds``. It's also just makes things more consistent across the board for policy enforcement.

The description of this bug report is a condensed version of a discussion we had in IRC [4].

[0] https://github.com/openstack/oslo.policy/blob/a0d50a5846369f50950432d13e924669bdc1309a/oslo_policy/policy.py#L779
[1] https://github.com/openstack/oslo.policy/blob/a0d50a5846369f50950432d13e924669bdc1309a/oslo_policy/policy.py#L791-L792
[2] https://github.com/openstack/oslo.context/blob/f2e394ca8850db691608f6432d136c50a2d53a71/oslo_context/context.py#L175
[3] https://github.com/openstack/oslo.context/blob/f2e394ca8850db691608f6432d136c50a2d53a71/oslo_context/context.py#L424
[4] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-28.log.html#t2018-06-28T12:17:36

description: updated
description: updated

Fix proposed to branch: master
Review: https://review.openstack.org/578995

Changed in oslo.policy:
assignee: nobody → Lance Bragstad (lbragstad)
status: New → In Progress
description: updated

Reviewed: https://review.openstack.org/578995
Committed: https://git.openstack.org/cgit/openstack/oslo.policy/commit/?id=775641a5fc549c20be37cf862deca394bf7f2d21
Submitter: Zuul
Branch: master

commit 775641a5fc549c20be37cf862deca394bf7f2d21
Author: Lance Bragstad <email address hidden>
Date: Thu Jun 28 20:31:27 2018 +0000

    Teach Enforcer.enforce to deal with context objects

    The ``creds`` dictionary passed into oslo.policy's enforce() method
    assumes a lot of the same values already specified by oslo.context
    RequestContext objects.

    This commit teaches enforce() to handle being passed an instance of
    a RequestContext object, and populate credential values accordingly.

    Change-Id: Ia74bf6c40b1e05a1c958f4325e00f68be28d91b9
    Closes-Bug: 1779172

Changed in oslo.policy:
status: In Progress → Fix Released

This issue was fixed in the openstack/oslo.policy 1.38.0 release.

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

Other bug subscribers