Veil
|
This table describes each privilege. A privilege is a right to do something. Most privileges are concerned with providing access to data. For each table, "X" there are 4 data privileges, SELECT_X, UPDATE_X, INSERT_X and DELETE_X. There are separate privileges to provide access to project and person details, and there is a single function privilege, can_connect
.
A role is a named collection of privileges. Privileges are assigned to roles through role_privileges. Roles exist to reduce the number of individual privileges that have to be assigned to users, etc. Instead of assigning twenty or more privileges, we assign a single role that contains those privileges.
In this application there is a special role, Personal Context
that contains the set of privileges that apply to all users in their personal context. Since all users have the same personal context privileges, the demo application provides this role to all users implicitly; there is no need for it to be explicitly assigned.
Assignments of roles in the global context are made through person_roles, and in the project (relational) context through assignments.
Role privileges describe the set of privileges for each role.
This is currently unused in the Veil demo application. Role roles provides the means to assign roles to other roles. This allows new roles to be created as combinations of existing roles. The use of this table is currently left as an exercise for the reader.
This describes each person. A person is someone who owns data and who may connect to the database. This table should contain authentication information etc. In the demo it just maps a name to a person_id.
A project represents a real-world project, to which many persons may be assigned to work.
This table describes the which roles have been assigned to users in the global context.
This describes the roles that have been assigned to a person on a specific project. Assignments provide privilege to a user in the project context.
This is a lookup-table that describes general-purpose attributes that may be assigned to persons or project. An example of an attribute for a person might be birth-date. For a project it might be inception date. This allows new attributes to be recorded for persons, projects, etc without having to add columns to the table.
Each detail_type has a required_privilege field. This identifies the privilege that a user must have in order to be able to see attributes of the specific type.
These are instances of specific attributes for specific persons.
These are instances of specific attributes for specific projects.
Getting security right is difficult. The Veil demo provides a number of views that help you view the privileges you have in each context.
Using these views, access control mysteries may be more easily tracked down.