Class 14: Role-Based Access Control (RBAC)

We're going to head to the mountain tops then back to the trenches to look at "RBAC"; a powerful (but very abstract) security framework used by the vast majority of large institutions. We'll start with a look at it from the standards level perspective.

There are several flavors of RBAC specified in the official standard.

• Core RBAC
• Hierarchical RBAC
• Constrained RBAC
• Static Separation of Duty Relations
• Dynamic Separation of Duty Relations

Let's start with the core RBAC the minimum set of features to have a role-based access system.

Core RBAC

So the goal of this is to control which users of the system can execute actions on objects in a way that can quickly adjusted in large organizations. There are six fundamental elements in this security model:

• Users (a human, an end-user agent, a requester of services)
• Roles (a job function, a context in an organization)
• Objects (OBS) (something that contains or receives information: files, rows in a database, directories, etc.)
• Operations (OPS) (an action on an object: CRUD and execute)
• Permissions (PRMS) (approval to perform an operation on a protected object)
• Sessions (the set of roles active for a user at a particular interaction with the system)

Specifications: In the forum example we started to build last time what are some OBS, OPS, and Roles you could imagine?

Relational Algebra

So this abstract model that works for so many businesses and organizations boils down to some set-theory based rules. If your discrete math is a little weak here are the things you need:

• \(A \times B = \{ (a,b) \mid a \in A, b \in B \}\) is the direct product of two sets, it creates a mega-set of tuples from \(A\) and \(B\).
• \(\mathcal{R} \subseteq A \times B \) defines a relation between \(A\) and \(B\) based on the elements in \(\mathcal{R}\). That is, if \((a,b) \in \mathcal{R}\) then we say \(a\) is related to \(b\).
• Relations capture almost any type of mapping including functions, possession, and every database table is a relation.
• Given a set \(A\) the number of elements in \(A\) is denoted by \(|A|\) and the subsets of \(A\) is denoted \(\mathcal{P}(A)\) and it has \(2^{|A|}\) many elements.
• \(f: A \to B\) is a function from \(A\) to \(B\) and is any relation where every element of \(A\) is in exactly one tuple in the relation.

Relation Play: Let \(A = \{1, 3, 5, 7\}\) and \(B = \{2, 6\}\). Write down all tuples defined by the relation \(\mathcal{R} = \{(a,b) \mid a \leq b, a \in A, b \in B\} \subset A \times B\)

Formal Core RBAC:

Here are the relational algebra rules that define RBAC:

• \(USERS, OPS, OBS, ROLES, SESSIONS\) are sets.
• \(UA \subseteq USERS \times ROLES\) is user assignments a many-to-many mapping users to roles.
• assigned_users\(: ROLES \to \mathcal{P}(USERS)\) maps each role to a subset of users.
• \(PRMS \in \mathcal{P}(OPS \times OBS)\) is the set of permissions
• \(PA \subseteq PRMS \times ROLES\) is the many-to-many permission to role assignment relation.
• assigned_permissions:\(ROLES \to \mathcal{P}(PRMS)\) maps a role to the permissions granted by that role.
• \(Op:PRMS \to \mathcal{P}(OPS)\) is a mapping from a permission to the associated operations
• \(Ob:PRMS \to \mathcal{P}(OBS)\) is a mapping from a permission to the associated objects
• session_user\(: SESSIONS \to USERS\) maps a session to its user
• session_roles\(:SESSIONS \to \mathcal{P}(ROLES)\) mapes a session to a subset of \(ROLES\) active for that user and that session.
• avail_session_perms\(:SESSIONS \to \mathcal{P}(PRMS)\) maps a session to the permsissions available to a user in a session. In this case those permissions are the union of assigned permissions of roles for each role in this users session.

Write down some of these: for your created roles and operations and objects add some users and assign them roles by defining what UA, assigned_users, PRMS, PA, assigned_permissions look like for your forum app.

Functional Version

Here are the functions this leads to:

• Add/Delete User
• Add/Delete Role
• Assign/Deassign User
• Grant/Revoke Permission
• Create/Delete Session
• Add/Drop ActiveRole
• CheckAccess
• Assigned Users/Roles
• Role/User Permissions
• Session Roles/Permissions
• Role/User OperationsOnObject

Now Design With It

Let's build an artist auction site. Artists create "paintings" and bidders look at the "paintings" then make "bids" on those paintings.

I want an sqlite database that has three roles:

• admin
• artist
• bidder

I want three objects:

• users
• paintings
• bids

The role permissions are as follows:

• admins can CRUD (Create, Read, Update, Destroy) users, paintings, and bids
• bidders can Read Paintings and CRUD Bids
• artists can CRUD Paintings

Let's start with three users:

• Pablo is an artist
• Nancy is a bidder
• Jenny is an admin

Assumptions

So you have all built logins already. So for this experiment we will let the user tell us their name without verification as part of the payload. (Pretend like the login handles auth perfectly well.) Your job is the following:

1. Design, create, and populate the RBAC-based tables in SQLite3
2. Write one PHP utility function which consumes:
   • a username
   • an operation (Create, Read, Update, Destroy)
   • an object/resource (User, Painting, Bid)
   It should return true or false based on the data in your database.

Your design should be flexible enough that you can revoke the ability to update bids from bidders with one row removal.

Now create a person "Claude" which is both an artist and a bidder. This person should work without issue.