Permissions
...
Users
Groups
Roles
Permissions
When talking about zone management and users, groups, roles, and permissions, it is useful to remember there is a distinct division between permissions and scopes. Permissions control access to a YOUnite resource (i.e endpoints) and scopes control access to the data behind the /domains and /dr endpoints.
When a zone is created, the automatically-created zone users 1) of Zone IT Admin (admin) and 2) Zone Data Steward (ZDS) are given appropriate permissions based on their respective roles. The admin Zone Admin can grant permissions to most of the resources in the zone. The remainder of the permissions, which are data related, are granted by the ZDS.
Resource permissions granted to zone users Zone Users (users) are restrictive by default. Permissions can be granted to a resource by specifying:
- The "ALLOW" type of permission
- The URI location
- The URI can contain the
*wildcard character.
- The URI can contain the
- The REST action. Possible actions mirror the REST verbs available at the resource and the special case ALL, which is a shortcut for "all vebsverbs":
- GET
- PUT
- POST
- DELETE
- ALL
Examples
To allow a user to view the groups in a zone:
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/groups/*"
} |
For example, The user with the permissions to view zone groups can then get the list of groups in the zone:
| Code Block | ||
|---|---|---|
| ||
GET /zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/groups |
Get Getting the group with UUID 9e463a36-5dd7-4440-8a90-94ce32e06c13 :
...
| Code Block | ||
|---|---|---|
| ||
GET /zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/groups/9e463a36-5dd7-4440-8a90-94ce32e06c13/permissions |
Special Cases
Typically, permissions end with the wildcard "*" e.g. /zones/zone-uuid/users/*. However, there are cases where permissions end with:
...
Individual resource access is needed at times when sub-resources contain sensitive information as described below in "Sensitive Sub Resource Access."
Access by Resource Name
This permission allow allows a user to view all of the adaptors in the zone (identified by UUID 18e1f27a-36b5-472f-a03c-6831fb78f97a in the example below).
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors"
} |
Note the absence of the wildcard character.
This request can be made by the userSetting access by resource name in the example above allows the user to request the following:
| Code Block | ||
|---|---|---|
| ||
GET /zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors |
However, this would not allow the user to view the individual adaptor resource details. For example, if the zone had an adaptor identified by the UUID 7c11c574-0e35-4c78-b572-222952156ac8, this request would be denied:
| Code Block | ||
|---|---|---|
| ||
GET /zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/7c11c574-0e35-4c78-b572-222952156ac8 |
Access by Individual Resource
To allow This permission allows the user access to an individual adaptor:, but not that adaptor's resource details.
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/7c11c574-0e35-4c78-b572-222952156ac8"
} |
This is in contract contrast to allowing the user detailed access to all adaptors in the zone, using the '*' wildcard:* wildcard, which does allow the user access to that adaptor's resource details.
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/*"
} |
Sensitive Sub Resource Access
...
NOTE: The examples below demonstrate how to manage secure access with the adaptors resource but similar situations could apply with other resources.
...
Using wildcards at times There are cases where using wildcards may not be desirable, since it allows they allow access to resources that should be accessed by only the adminZone Admin.
For example:...
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/*"
} |
Would allow ...allows a user to see all of the adaptor's registration information for a given zone:
...
If the requirement is to grant a user detailed access to adaptors in a zone zone but not grant access to the adaptor's registration information, then permission to adaptors in the zone to that zone's adaptors must be granted on an adaptor-by-adaptor basis.
For example, assume the zone in our examples has three adaptors:
...
| Code Block | ||
|---|---|---|
| ||
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors"
},
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/7c11c574-0e35-4c78-b572-222952156aaa/*"
},
{
"type": "ALLOW",
"action": "GET",
"resource": "/zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors/ae91d787-65c9-4f24-bff4-e3acbd616bbb"
} |
The following request would return limited information on all three adaptors...
| Code Block | ||
|---|---|---|
| ||
GET /zones/18e1f27a-36b5-472f-a03c-6831fb78f97a/adaptors |
And ...and detailed access to either adaptor specified in the permissions (ending in aaa and bbb) would be allowed but the following request would be denied:
...