OrgAuth

OrgAuth are security policies based on policy 5 (table-level permissions) which allow multiple organizations using the same instance of Sahana Eden to control who can access their data and with which permissions.

Realms

Person Entities

A person entity is a type of records describing business entities which involve one or more individual persons. This can be, e.g., organisations, offices, teams, and of course persons.

Organisation Units

In an organizational structure, a person entity can be a sub-unit (organization unit, OU) of another person entity. E.g. an office can be a sub-unit of an organisation, or a person a sub-unit of a team.

Realms

The realm of a person entity is the set of all records controlled ("owned") by this entity (="their data"). Which entity gains control over a record can be defined per record type, and even as deployment options. The realm which a particular record belongs to is encoded as person entity ID (pe_id) in the owned_by_entity field in this record.

Role Restrictions

In all OrgAuth policies (6, 7 and 8), a role assignment for a user (and thus all the permissions the user receives out of this role) can be restricted to a particular realm:

The realm for each role assignment can be chosen from the "for Entity" list.

In this list there is also an entry for "All Entities" which means that this role assignment is not restricted to a realm, but applies site-side (=for all records regardless of their respective owner entity).

The entry "Default Realm" means all entities the user is (or will be) an organisation unit of at the time of the request authorization.

NOTE: The "Default Realm" setting can be dangerous and may be inappropriate for most multi-tenancy settings, because the user would automatically receive this role for any entity they will ever join in future - without that entity being anyhow in control of this. However, in certain deployments, this dynamic realm may still be convenient practice.

Realm Hierarchy

In policies 7 and 8, realms follow the OU hierarchy. That is, the realm of an entity includes all the realms of all organization units (OU) of this entity.

Access Delegation

OrgAuth policy 8 additionally allows the delegation of access rights for a realm to other entities (rather than to particular users), thus facilitating controlled data sharing at the organization level.

Restriction Level

Policy	Role assignments are restricted to
6	the realm of a person entity
7	the realm of a person entity including the realms of any of its organisation units
8	the realm of a person entity including the realms of any of its organisation units + delegated realms

Extended Record Ownership

The "owned_by_entity" field get automatically populated in CRUD and Imports, using the auth.set_record_owner method. This method can be influenced by the owner_entity table hook:

s3db.configure(tablename,
               owner_entity = function_or_lambda)

The hook function must accept (table, row) as parameters, and return the pe_id (Person Entity ID) of the owner entity.

It is possible to set a global default for the owner_entity hook in the config.py of the respective template:

settings.auth.owner_entity = function

NOTE: the global owner_entity setting overrides any table-specific setting (this is deliberate), i.e. to retain a table specific setting, you must repeat it in the global hook function.

Extended Restriction of Access

Any role of a user is always only applied to the realms the role is restricted to.

That is, the user can exercise permissions of role X only on the records of the entity he has this role for. E.g. a user who is "HR Manager" for OrgA can exercise the "HR Manager" permissions only on records "owned" by OrgA.

If there is no restriction in the role assignment (for_pe=0), then the role applies for all records regardless of their owner entity (=site-wide role).

The AUTHENTICATED, ANONYMOUS and ADMIN roles can not be restricted to realms, i.e. the permissions of these roles always apply for all records.

NOTE: It is possible to define a dynamic realm in a role assignment (for_pe=None). This dynamic realm is the realm of all entities the user is directly affiliated with at the time of the request. This practice can though be dangerous and may be inappropriate for most multi-tenancy settings, because the user would automatically receive this role for any entity they will ever join in future - without that entity being anyhow in control of this. However, in certain deployments, this may still be convenient.

Delegations of Permissions

A person entity can allow another entity to access records within their realm with the permissions of a certain user role. This is called "delegation".

All users which are affiliated with the other entity (or any of its organisation units) can then exercise the permissions of the delegated role on the realm of the delegating entity provided they would have the same permissions for the realm of the other entity.

Example:

• if OrgA allows OrgB to access their realm with the "HR Editor" role, then all users affiliated with OrgB are permitted to edit human resource records of OrgA if they are permitted to edit human resource records for OrgB.

NOTE: Delegations are not personal. If a user is no longer affiliated with the receiving entity, they can not receive permissions out of the delegations to this entity anymore - and vice versa. For personal delegations, it is better to use a direct role assignment for the realm of the delegating entity.