Difference between revisions of "Storlets/DataSecuritySpec"
(→Usage) |
(→Implementation) |
||
| Line 27: | Line 27: | ||
== Implementation == | == Implementation == | ||
| − | Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift | + | Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift keystone auth mechanism for users. Upon setting this, we add: |
| − | + | org.apache.openstack.storlet_internal.<user_name>_<storlet_name> | |
| − | This meant that under the hood we set the container read ACL | + | to the to the Container-Read-ACL |
| − | + | This meant that under the hood we set the container read ACL to allow access to a user whose name is the concatenated name. | |
| − | + | The storlet middleware code will thus work as follows: | |
| − | + | 1. Do the existing GET call, with no change to the identity env. | |
| − | This | + | 2. If the calls fails on unauthorized, we change the user name in the identity env to the internal concatenated 'username' using the user name and storlet name from the request and retry. |
| + | This approach makes sure that the original user is an identified user with a valid token (there is an identity env for the user), and that the user was indeed granted access via the specified storlet | ||
== Changes in Flow == | == Changes in Flow == | ||
Revision as of 09:20, 14 September 2016
Requirements
Allow the ability for an account admin to set read access using storlets. That is, allow access to a container only if the GET request has an appropriate X-Run-Storlet header, thus enforcing sensitive data filtering done with that storlet.
At this point we require that the feature will work with Keystone only, and that access will be granted on a single user basis only.
Added API
POST account/container
- X-Storlet-Container-Read: user_name
- X-Storlet-Name: storlet_name
- X-Auth-Token: token
where:
- The user name, is the name of the user as appearing in the user's Keystone token.
- The storlet_name is the name as appearing in the X-Run-Storlet header, when invoking the storlet.
- The token is a token of a user that is authorized to change a container ACL.
Usage
GET account/container
- X-Run-Storlet: storlet_name
- X-Auth-Token: token
where:
- The storlet_name is the name of the storlet to invoke
- The token is a token of a user that is:
- Authorized to read from the storlet container - no changes from today
- Authorized to read from the accessed container or was given explicit access to read using the specified storlet name using the above API.
Implementation
Since we want to allow the account admin to set this without the need to do Keystone updates, we utilize the Swift keystone auth mechanism for users. Upon setting this, we add: org.apache.openstack.storlet_internal.<user_name>_<storlet_name> to the to the Container-Read-ACL This meant that under the hood we set the container read ACL to allow access to a user whose name is the concatenated name. The storlet middleware code will thus work as follows: 1. Do the existing GET call, with no change to the identity env. 2. If the calls fails on unauthorized, we change the user name in the identity env to the internal concatenated 'username' using the user name and storlet name from the request and retry. This approach makes sure that the original user is an identified user with a valid token (there is an identity env for the user), and that the user was indeed granted access via the specified storlet
Changes in Flow
When the proxy handler tries to do a GET with X-Run-Storlet that results in an "unauthorized" response, and the feature is enabled in the middleware config file, then it will re-attempt while adding the referrer header: org.apache.openstack.storlet_internal.<user_name>_<storlet_name> where the user name is taken from the identity env, and the storlet name from the X-Run-Storlet header. In addition the middleware will check that the account in the url matches that of the authenticating user.
These checks ensure that we are dealing with an authenticated user of the appropriate account.
