Security Roles and Policies in Sahana Systems

Sahana Systems manage accounts for users, and provide users with mechanisms to identify themselves as particular account holders when using the system (authentication).

As a minimum, any authentication mechanism in Sahana requires the user to present some kind of secret access token (e.g. a password) to confirm their identity as the respective account holder.

Recommended reading:

• The definitive guide to form-based website authentication
• HTTP Authentication, RFC 2617
• OAuth 1.0, RFC 5849
• OAuth 2.0, RFC 6749

User accounts can be assigned roles. Through such assignment, the user receives all privileges associated with the respective role (e.g. access permissions).

Sahana defines three standard user roles:

• ANONYMOUS: all users who are not logged in (can not be realm-restricted)
• AUTHENTICATED: any user who is logged in (can be realm-restricted)
• ADMINISTRATOR: the site administrator (can be realm-restricted)

For usability reasons, it is recommendable that

• the AUTHENTICATED role inherits all permissions granted to the ANONYMOUS role
• the AUTHENTICATED role is implied for all logged-in users rather than explicitly assigned
• the ADMINISTRATOR role always has unrestricted access to all resources and functions
• the last assignment of the ADMINISTRATOR role can not be deleted (there must always be at least 1 ADMINISTRATOR)

Besides these standard roles, the system may define any number of additional roles.

Typically, these roles would define permission levels for specific data domains (e.g. for warehouse management):

• READER (users who can only read data)
• EDITOR (users who can create, edit and delete data)

or resemble roles in the business process like:

• MANAGER
• STAFF

Sahana Systems can allow multiple role assignments per user account.

Access permissions are granted per user role.

Permissions should be differential per type of user action, and can be differential per origin of user action (e.g. page, interface, requester IP address), or per target of user action (e.g. a certain set of records) - or combinations of these. Where combinations of action, origin and target permissions are allowed, the most restrictive setting shall apply.

Where a user holds multiple roles each defining different permissions for the same combination of action, origin and target, the most permissive role shall apply.

Users can own records, and this can imply additional permissions on the owned records. Ownership shall not be restricting, i.e. the user shall have at least the same permissions on owned records as they are granted for all other records within the same target.

Records can be owned by individual users, or collectively by groups of users. Individual record ownership and group ownership shall be treated as equivalent.

A user role assignment can be restricted to a certain subset of the database (realm) which is associated with an entity that is itself not represented by a user account (non-participant), e.g. an organisation or a location. This can for example be used for distributed governance in multi-tenancy deployments.

Where a user holds roles for multiple realms, the most permissive role shall apply for any intersections.