Spaces:
Sleeping
Sleeping
File size: 5,491 Bytes
ad8da65 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 |
# Custom RBAC
(custom_rbac_managing_orgs_and_roles)=
## Managing RBAC and Organizations for SSO users
For customers using SSO (on-prem only), Arthur provides the ability to set up a fully customizable RBAC.
Please follow the below:
1. When setting up your identity provider via the YAML configuration, supply a global
role name and set of permissions under `globalRoleDefs` that your identity provider will authenticate users with.
This configuration will create the global role in the Arthur authorization system when it is applied. See the
{ref}`Creating Global Roles for Managing Organizations and RBAC Policies Guide <creating_global_roles_in_arthur_config>` for
more information.
2. That global role can then create custom role mappings for each organization:
* During organization creation, include the role configuration JSON (see below for example) in the request body when
calling [`POST /organizations`](../../../../api-documentation/v3-api-docs.html#tag/organizations/paths/~1organizations/post).
* After an organization is created, create or add custom_roles by sending the role configuration JSON (see below for
example) in the request body when
calling [`POST /autorization/custom_roles`](../../../../api-documentation/v3-api-docs.html#tag/authorization/paths/~1authorization~1custom_roles/post).
3. Users logging in through your IdP must now have a valid known role in their token when accessing the Arthur
Platform. Arthur will use this role to both authenticate that the user is a member of the organization and to
determine the permissions they have.
## Managing Roles and Permissions
### Understanding Permissions
* A permission is a combination of a resource and an action. For
example `raw_data read`, `users write`, `models delete`.
* For a full list of available permissions. please see {doc}`here </platform-management/reference/permissions_set>`.
* For a directory of permissions by API endpoint, please see
{doc}`here </platform-management/reference/permissions_by_endpoint>`.
### Create Custom Roles
The [`POST /autorization/custom_roles`](../../../../api-documentation/v3-api-docs.html#tag/authorization/paths/~1authorization~1custom_roles/post)
endpoint is available for customers using SSO to operate on custom roles for each organization. A few notes:
* This endpoint only operates on permission scopes within each organization. Permissions that have global scope (such as
creating a new organization) cannot be granted via this endpoint, those permissions must be assigned to a role with
global privileges via the Arthur IdP configuration YAML. See
{ref}`Creating Global Roles for Managing Organizations and RBAC Policies Guide <creating_global_roles_in_arthur_config>` for more
information.
* Roles can have a list of permissions to allow and/or a list of other roles to inherit permissions from.
* Role names cannot conflict with {doc}`default roles </platform-management/reference/permissions_by_standard_roles>`.
* Supplied permissions must be valid known Arthur permissions.
* Roles can inherit the permissions of other roles that are either
{doc}`default roles </platform-management/reference/permissions_by_standard_roles>`, or roles also defined in the same
organization. Unknown inherited role names will be rejected.
### Get Custom Roles
To retrieve a list of roles defined for an organization,
use: [`GET /autorization/custom_roles`](../../../../api-documentation/v3-api-docs.html#tag/authorization/paths/~1authorization~1custom_roles/get).
To filter on specific roles pass a comma separated list of role names in a roles query parameter. For
example:`/authorization/custom_roles?roles=role1,role2`. If you wish to return all roles simply leave out the query
parameter or pass `"*"` as role.
### Delete Custom Roles
To delete a role or multiple roles from an organization,
use [`DELETE /autorization/custom_roles`](../../../../api-documentation/v3-api-docs.html#tag/authorization/paths/~1authorization~1custom_roles/delete).
Specify which roles to delete in the JSON request body. For example, to delete a single role:
```json
{
"roles": [
"role3"
]
}
```
To delete all roles pass "*".
```{warning} If you do not specify an organization_id, this will delete all custom roles you have created
```
```json
{
"roles": [
"*"
]
}
```
### Example Role Configuration JSON
Below is an example JSON request body that creates three roles. role1 has 3 permissions defined, role2 gets an
additional permission and then inherits the 3 permissions from role1, and role3 inherits the permissions from Arthur's
default "Model Owner" role. For more details on the expected schema for each endpoint,
see [Authorization API documenation](../../../../api-documentation/v3-api-docs.html#tag/authorization).
```json
{
"roles": [
{
"role_name": "role1",
"permissions": [
{
"resource": "metric_data",
"action": "read"
},
{
"resource": "metric_data",
"action": "write"
},
{
"resource": "tag",
"action": "read"
}
]
},
{
"role_name": "role2",
"permissions": [
{
"resource": "user_self",
"action": "read"
}
],
"inherited_role_names": [
"role1"
]
},
{
"role_name": "role3",
"inherited_role_names": [
"Model Owner"
]
}
]
}
``` |