| 2018-06-28 16:08:14 |
Lance Bragstad |
bug |
|
|
added bug |
| 2018-06-28 16:09:21 |
Lance Bragstad |
description |
Oslo.policy's Enforcer object has a method called ``enforce`` that is used by services to check if a user it 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()``.
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 authentication or 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 that attributes are exposed on the context instances 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.
[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 |
Oslo.policy's Enforcer object has a method called ``enforce`` that is used by services to check if a user it 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 authentication or 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 that attributes are exposed on the context instances 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.
[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 |
|
| 2018-06-28 17:23:51 |
Lance Bragstad |
description |
Oslo.policy's Enforcer object has a method called ``enforce`` that is used by services to check if a user it 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 authentication or 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 that attributes are exposed on the context instances 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.
[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 |
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.
[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 |
|
| 2018-06-28 20:40:26 |
OpenStack Infra |
oslo.policy: status |
New |
In Progress |
|
| 2018-06-28 20:40:26 |
OpenStack Infra |
oslo.policy: assignee |
|
Lance Bragstad (lbragstad) |
|
| 2018-06-28 21:23:43 |
Lance Bragstad |
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.
[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 |
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 |
|
| 2018-07-12 16:31:02 |
OpenStack Infra |
oslo.policy: status |
In Progress |
Fix Released |
|
