Permissions
  • Permissions identify classes of actions

  • Often coupled, e.g., DATA_READ and DATA_WRITE

  • Some identify classes of users: ANYBODY and ANY_USER

  • Permissions defined by application in code, but

    the default set usually good enough

  • AuthSupport dynamically adds: SUPER_USER_TRANSIENT and SUBSTITUTE_USER_TRANSIENT.

Notes:

A permission is a "bit" defined by an enumerated type. PermissionSet is the collection of these bits for a Task or RealmRole. They define the aggregate authorizations that are required by a task or given to a user, respectively.

Permissions allow you to group operations into logical classes, which separates the concerns of who can do what. In complex applications, there are hundreds of tasks, and tens of permissions. You can then review your task list to see if a given task belongs in the right logical groups, and independently review roles to see if they have been granted the correct permission set.

Often a permission represents an area of access, e.g., DATA or ADMIN. And those areas get access rights, e.g. READ and WRITE. The resultant permissions are named logically by combining the two: DATA_READ, DATA_WRITE, ADMIN_READ, and ADMIN_WRITE.

Some permissions are given to all users, e.g. ANY_USER, while others are given to everybody, e.g. ANYBODY. These general permissions allow access to whole classes of users or visitors. For example, ANY_USER is a good name for permissions on tasks that require a user to be authenticated. ANYBODY allows everybody access to the task, even visitors (unauthenticated users), that is, if ANYBODY is the only permission in the task's required set, and all roles in that realm have been granted the ANYBODY permission. These names are simply conventions for permissions we are likely to need, since all tasks require at least one permission.

You can define your own permissions through bOP's delegation interface, but they all are identified by the delegator, Bivio::Auth::Permission. Many of bOP's security classes allow you to override the default values in this way. However, don't go adding new values unless you are sure you need them. Most applications can get away with a simple set of permissions.

There are two special permissions set dynamically by Bivio::Delegate::SimpleAuthSupport, the default Bivio::Auth::Support delegate. SUPER_USER_TRANSIENT indicates that the authenticated user is a super user (plays the role of ADMINISTRATOR in the GENERAL realm). SUBSTITUTE_USER_TRANSIENT identifies the state when a super user is acting as another user. These transient permissions are set on special tasks to enable special features for administrative purposes, and they are not stored in the RealmRole table. Dynamic permissions allow you to control behavior in a global way that would otherwise be difficult to control.