Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Adds multi-tenant best practices #684

Merged
merged 1 commit into from
Dec 7, 2017
Merged

docs: Adds multi-tenant best practices #684

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 15 additions & 5 deletions docs/access-control.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,9 +28,8 @@ Hydra's Access Control is able to answer the question:
* **What**: An arbitrary action name, for example "delete", "create" or "scoped:action:something".
* **Something**: An arbitrary unique resource name, for example "something", "resources.articles.1234" or some uniform
resource name like "urn:isbn:3827370191".
* **Context**: The current context containing information about the environment such as the IP Address,
request date, the resource owner name, the department ken is working in or any other information you want to pass along.
(optional)
* **Context**: The current context containing information about the environment such as the IP Address, the time or date
of access, or some other type of context. (optional)

To decide what the answer is, Hydra uses policy documents which can be represented as JSON. Values `actions`, `subjects`
and `resources` can use regular expressions by encapsulating the expression in `<>`, for example `<.*>`.
Expand Down Expand Up @@ -90,21 +89,32 @@ we developed over the years at ORY.
URN naming is as hard as naming API endpoints. Thankfully, by doing the latter, the former is usually solved as well.
We will explore further best practices in the following sections.

##### Scope the organization name
##### Scope the Organization Name

A rule of thumb is to prefix resource names with a domain that represents the organization creating the software.

* **Do not:** `<some-id>`
* **Do:** `<organizaion-id>:<some-id>`

##### Scope actions, resources and subjects
##### Scope Actions, Resources and Subjects

It is wise to scope actions, resources, and subjects in order to prevent name collisions:

* **Do not:** `myorg.com:<subject-id>`, `myorg.com:<resource-id>`, `myorg.com:<action-id>`
* **Do:** `myorg.com:subjects:<subject-id>`, `myorg.com:resources:<resource-id>`, `myorg.com:actions:<action-id>`
* **Do:** `subjects:myorg.com:<subject-id>`, `resources:myorg.com:<resource-id>`, `actions:myorg.com:<action-id>`

##### Multi-Tenant Systems

Multi-tenant systems typically have resources which should not be access by other tenants in the system. This can be
achieved by adding the tenant id to the URN:

* **Do:** `resources:myorg.com:tenants:<tenant-id>:<resource-id>`

In some environments, it is common to have organizations and projects belonging to those organizations. Here, the
following URN semantics can be used:

* **Do:** `resources:myorg.com:organizations:<organization-id>:projects:<project-id>:<resource-id>`

## Access Control Decisions: The Warden

Expand Down