Skip to content

Participation Access Control

Jump to bottom
Stephen Cote edited this page Aug 5, 2014 · 4 revisions

Participation Access Control

Account Manager uses a foreign key table called the participation table to track object relationships. Participation tables identify member participants, and their entity type. Participation records accommodate the declaration of an affect, which may be a coarse or granular entitlement. The function of the participation table to define entitlement affects is called Participation Access Control (PAC). Not all participation tables are evaluated for PAC capabilities.

At present, the following participations make use of PAC: Data, Groups, Roles, Users, Accounts, Persons

Participation Access Control (PAC) is a blend of Discretionary Access Control (DAC), Access Control Lists (ACL) and Roles Based Access Control (RBAC). The participation tables define the atomic relationship data, while the Effective Authorization Service in conjunction with a series of database cache tables, views, and functions, construct the hierarchical entitlement representations. For comparison, here is a brief introduction to common access controls. Note that these are not necessarily independent of the other.

  1. Discretionary Access Control (DAC) defines access to objects at the discretion of the owner. Mandatory Access Control (MAC) extends or replaces Discretionary Access Control, and is a policy governing user access to objects they create, and where users may not change an assigned access level from the one applied by an administrator.
  2. Access Control List (ACL) describes privilege separation of a resource as related to a user or group.
  3. Roles Based Access Control (RBAC) is closer to an Access Control List (ACL), but differs in that privileges may be assigned at a higher level, such as a role level. RBAC may also be modelled to mimick a Lattice-Based Access Control (LBAC), which is a mathematical structure describing the greatest lower-bound and least upper-bound for a resource pair.
  4. Participation Access Control (PAC) includes elements of RBAC, DAC, and ACL through resource participation. Resource participation is a direct or indirect relationship between two or more entities.

Comparing PAC to other Access Controls:

  • PAC does not implement sensitivity labels, as is used by MAC.
  • PAC is similar to DAC in that every object must have an owner, and it is different in that every object does not have to have an ACL.
  • PAC is similar to RBAC in that permissions may be assigned to roles, and users may inherit permissions from those roles.
  • PAC requires every object to belong to an OrganizationType, including Organizations (except the top-most organization).
  • PAC requires every object to be owned by a UserType, except Organizations.
  • PAC requires most objects to belong to a GroupType.

Participation Model

The following conceptual model describes the relationship of PAC data.

  • [{Id}-{ParticipationId}] = {Participation} : A participation is a single unique base object. The base object Id is the ParticipationId.
  • [{ParticipationId}-{ParticipantType}-{ParticipantId}] = {Participant} : A participant is a unique object Id of a specified type to a participation.
  • Data, Groups and Roles can be Affected. Affect types (word choice aside) currently include granting and denying permission to the participation.
  • Participations may not transcend the organization level.

In most cases, the participation model is abstracted through the use of the available factories and services. In some cases, such as when dealing with bulk operations, it may be necessary to work directly with the ParticipantType objects.

Role Based Access Control

RBAC is implemented by defining a role of a particular type, optionally populating that role with members, and assigning the role to participate on a particular object with a specific affect. The following example illustrates the association. All of the data access operations are provided through the factories, so there is no need to hand code any direct data manipulation.

Given some AccountType accountA that is a member of AccountGroupType groupA, and where groupA is a member of AccountRoleType roleA, grant BasePermissionType permissionA to roleA on DataType dataA.

  • AccountRoleType roleA - stored in the Roles table.
  • AccountGroupType groupA - stored in the Groups table
  • AccountType accountA - stored in the Accounts table.
  • AccountParticipantType partA - Relates groupA with accountA, stored in the GroupParticipation table
  • GroupParticipantType partB - Relates roleA with groupA, stored in the RoleParticipation table
  • BasePermissionType permissionA - stored in the Permissions table
  • DataType dataA - stored in the Data table.
  • RoleParticipantType partC - Relates roleA with dataA and permissionA, stored in the DataParticipation table

The above creates a direct relationship between dataA and roleA and permissionA, and an indirect relationship between dataA and accountA and permissionA. The Effective Authorization Service correlates this information into detailed entitlement facts across a role hierarchy.

Clone this wiki locally