This page is a pre-SRFI, but has nothing to do with R7RS.
The idea of role-based access control (RBAC) is that there are actions that can or cannot be performed on resources by principals, depending on whether or not a principal belongs to a role. This package allows clients to check what can be done, but it is up to its clients to actually permit or forbid actions based on this information. Such checks are done relative to a rulebase; all rulebases are entirely independent from each other.
Actions, principals, and roles are all named by symbols. Actions are typically verbs like read, write, modify, and delete; principals are typically nouns, especially proper names; roles are typically plural nouns. However, any of these can be anything at all. When setting up a rulebase for use by RBAC, we specify the actions, principals, and roles to be used in that rulebase. We can also specify rules of various types. A rule can say that a principal belongs to a role. Another kind of rule specifies that a role is a sub-role of another role; this means that all principals belonging to the first role automatically also belong to the second role.
A resource is named by a list of symbols representing a path in an abstract hierarchy. A rule specifying that a role is allowed to perform an action on a resource, implicitly means that the role is also allowed to perform the same action on any sub-resources. For example, if role updaters is allowed to perform action write on the resource (localhost pub), then it is also allowed to perform that action on the sub-resource (localhost pub canada). However, if a rule specifies that a role is blocked from taking a given action on a given resource, then principals belonging to that role cannot perform that action on the specified resource or its sub-resources. By default, all roles are blocked from performing any action on the empty resource named (). Resources are not declared in a rulebase, but are deduced from their presence in allow and block rules.
Finally, principals can be members of groups, and groups can belong to roles in the same way that principals can. We determine if a principal belongs to a group based on procedures that specify which principals are in the group. A group also has a lead member declared for it; at query time, if a group's procedures say that the lead member is not part of the group, an error is signaled if an attempt is made to allow or block a group member from taking an action.
(make-rbac)
Return a rulebase with no actions, principals, roles, groups, or rules.
(rbac-add-action rulebase action)
Add the symbol action to rulebase.
(rbac-remove-action rulebase action)
Remove the symbol action from rulebase.
(rbac-add-principal rulebase principal)
Add the symbol principal to rulebase.
(rbac-remove-principal rulebase principal)
Remove the symbol principal from rulebase.
(rbac-add-role rulebase role)
Add the symbol role to rulebase.
(rbac-remove-role rulebase role)
(rbac-add-group rulebase group all-members member? lead-member)
Add the symbol group to rulebase, specifying proc as the procedure for retrieving and checking group membership and lead-member for the lead member of the group. If all-members is called with no arguments, it returns a list of all the principals in the group. If member? is called with one argument, a principal, it returns #t if the principal is a member of the group and #f otherwise.
(rbac-remove-group rulebase group)
(rbac-add-in-role rulebase principals role)
Adds a rule specifying that the principals and/or groups in the list principals belong to role.
(rbac-remove-in-role rulebase principals role)
Removes a rule specifying that the principals and/or groups in the list principals belong to role. Note that this is only effective if exactly the same arguments were passed to rbac-add-in-role.
(rbac-add-subrole rulebase subrole role)
Adds a rule specifying that the principals belonging to subrole also belong to role.
(rbac-remove-in-role rulebase principals role)
Removes a rule specifying that the principals belonging to subrole belong to role. Note that this is only effective if exactly the same arguments were passed to rbac-add-subrole.
(rbac-add-allow rulebase role actions resource)
Adds a rule allowing role to perform any of the actions in the list actions on resource or any of its sub-resources.
(rbac-remove-allow rulebase role actions resource)
Removes a rule allowing role to perform any of the actions in the list actions on resource or any of its sub-resources. Note that this is only effective if exactly the same arguments were passed to rbac-add-allow.
(rbac-add-blockrulebase role actions resource)
Adds a rule blocking role from performing any of the actions in the list actions on resource or any of its sub-resources.
(rbac-remove-block rulebase role actions resource)
Removes a rule blocking role from performing any of the actions in the list actions on resource or any of its sub-resources. Note that this is only effective if exactly the same arguments were passed to rbac-add-block.
(rbac-compile rulebase)
Checks the rulebase for consistency: that is, actions, principals, roles, and groups referred to in rules have to exist in the rulebase. Returns a compiled form of the rulebase which can be efficiently checked; in particular, all groups and roles are expanded to the corresponding list of principals at this time. The objects and rules defined for compiled rulebases cannot be changed.
(rbac-allow? compiled-rulebase principal action resource)
Returns #t if principal (or some group it is a member of) belongs to a role which is allowed to perform action on resource, as specified by compiled-rulebase, and #f otherwise. Checks that groups include lead members are done at this time.