In the last story I summarized existing authorization methods. One in particular came close to being a well rounded solution without excessive complexity. That solution was Role Based Access Control with Permission and Domains (RBACPD). RBACPD associates roles with users inside each group. Each role has a set of permissions. Give a request, the system verifies whether the user has a role that has the required permission for the resource object with the resource object belonging to the same group as that role (may need to read this a few times). The verification process can be described in the following steps:
- Identify all Groups to which the resource object belongs.
- For each Group retrieve the roles of the authorizing user.
- For each role look for the required resource permission.
RBACPD can provide very fine grained access control for non trivial applications; however this process degrades very quickly with additional complexity. Because roles are associated at the group level, a different set of roles would need to be associated with each group. This makes administration nearly impossible for a large number of groups. Since permissions are only effective at the group level, a new group would need to be created whenever any resource object requires different resource permissions. A near infinite number of groups would need to be maintained as the number of resource objects grows.
Due to these weaknesses, RBACPD isn’t widely used. Actually, the term RBACPD doesn’t even exist according to Google; I made it up. But what if we could add something to RBACPD to make it practical for every application. The missing component is something I named Scope. Scope as it relates to authorization isn’t a new concept, it has been around since the 1970s. The Unix file system, by default, provides three separate scopes for each file: User, Group and Other. User denotes the owner of the file, group denotes the file’s owner group and other is everyone else who may access the file. The permission system is so useful that Linux had adopted it and is still in use today.
Scope, in the realm of RPS, provides a schema like structure to the groups. Groups of the same kind can now be described using a single type. Due to this new concept, Roles now can be associated to a scope; thus, roles are available to all groups within the scope. Each group now possesses a unique identifier (ScopeId) within the scope. Resource Objects are associated with a number of ScopeIds for each scope. Give an authorization request, the following steps are used:
For each scope:
- Identify all Groups (ScopeIds) to which the resource object belongs.
- For each Group retrieve the roles of the authorizing user.
- For each role look for the required resource permission.
You may notice the authorization steps are nearly identical to RBACPD without the aforementioned weaknesses. In the next part, I shall present RPS in detail.
