Authorization Academy - Role-Based Access Control (RBAC)

Quoted on this wiki

Every place a page here uses this source, in the order the words come in it.

1. A permission specifies an action that a user can take on a resource. For example, we might say that a user in an organization has permission to read repositories. “In general, a role should align with who the user is, what they want to do in the application, and perhaps even their role or title within their organization.” For example, in GitClub the primary users are developers – that would be one “role” in our system. There are other roles, too: we might have IT administrators who are responsible for configuring organizations or finance users who are responsible for the billing. Each of these users have a different set of permissions they need to use our application. Each of these will be a single role in our GitClub authorization model.

   In Buyer and user personas

2. The nice thing about this model is that it is structured identically to organization roles. “All resources, in this case organizations and repositories, have equivalent data models, like this:” As a best practice, you minimize the number of different ways a user can get access to the same resource. Therefore, we make it so that in order to access a repository you must have a repository role. We will no longer assign permissions to organization roles that permit interacting with a repository.

   In Cross-tool data model