(jaas-authorization)=
# Authorization

JAAS provides enterprise-level features on top of Juju. One such features is enhanced authorization, which provides enterprises with more control over user permissions to access underlying Juju resources (e.g. controllers or models). JAAS utilises [Relationship-Based Access Control (ReBAC)](https://en.wikipedia.org/wiki/Relationship-based_access_control) by using [OpenFGA](https://openfga.dev/) as the back-end service for ReBAC. You can read more about Juju's permission model in [here](https://juju.is/docs/juju/user-permissions).


## What is ReBAC?

Unlike [Role-Based Access Control (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control) where permission sets are managed by the concept of *roles*, in ReBAC, a user's access to a resource is modelled through a *relation*, which can be either direct or indirect (the result of another relation). This makes ReBAC more dynamic in comparison to RBAC, and also more suitable for complex authorization schemes where there are large number of users and resources.

As an example, consider a simple file-system structure with two kinds of resources: directories and files. Without ReBAC, you need to be explicit about every user's permissions (or set of permissions, as roles) to every file or directory. But, with ReBAC, you can achieve the same result with much less effort and data, by defining the right relations. For instance, you can assign the `read::directory:foo` relation to a user (meaning that the user has `read` relation to the `directory` named `foo`), and then the user will have the read access to all files and directories under `foo`. Note that, you only declared *one* relationship (or more precise, *tuple*), and the other relations are automatically inferred from that.


## JAAS authorization components

Conceptually, the JAAS authorization system consists of two main components:

1. **authorization model**, which defines the schema of different entity types (e.g. controllers, users, or groups), the possible relationships between them (e.g. group memberships, or administrator relation for controllers), and the inheritance structure for permissions (e.g. a controller administrator is also an administrator for all models on that controller).

2. **Tuples (or relationship data)**, which represent a set of individual relationships between concrete entities (e.g., a user named *foo* is an *admin* of a controller named *bar*).

Inherently, the authorization model is a static component and cannot be changed by the administrators of JAAS. On the other hand, the tuples, are dynamic data and JAAS provides tools for administrators to manipulate them.

> See more: {ref}`relation`