About security

Security protects the system against threats such as unauthorized access and modification. Therefore, it must answer the following questions: who is the user accessing the system, what can he/she do with it and, finally, what has he/she done with it?

Authentication

Authentication is the process by which we know who the user is and what property he claims to have, such as his/her name, email address, date of birth.

Sometimes, business procedures might require that the user’s signature, to prove he/she approved some action. Difficulties are to ensure the signature is neither forged nor tampered with.

Usually, the user as recognized by the system should be the one manipulating it, except when it is necessary to reproduce context in which a specific user work, for developing, testing, or debugging a system. Such a mechanism is called impersonation.
Allowing impersonation on the production environment should be carefully weighted.

Impersonation should not be confused with surrogation, in which a user can temporarily be granted permissions of a colleague.

Authorization

Authorization is the process of granting or denying access to a resource or a command. Permissions explicit what a user may be able to do with the system. For instance, is he/she allowed to:

• Edit a page.
• Publish a page.

But that does not mean that he/she can edit or publish any pages. Therefore, access control lists are often used to declare what a user can do on a particular resource.

Managing the permissions and ACL can be cumbersome so roles and groups are defined to cope with this complexity.

A role is a set of permissions that should be configurable, as they reflect how companies are organized. Permissions, on the other hand, are defined by the implementation of the system. For instance, continuing the previous example, some might want to define a role Editor with the “Edit page” permission and a role Publisher with the “Publish page” permission. Others might prefer a single role Editor with both permissions.

If a role defines what a user can do, a group defines where the user belongs. Let says you have two departments, one to handle local pages and another one for international pages, you might not want users from the first group to edit pages belonging to the second. It is important to note that a user can have multiple roles , and be in multiple groups. Also, it is not uncommon to have group in other groups, forming a hierarchy or even direct acyclic graph.

For the sake of completeness, permission verification does not have to be limited to the assertion of whether you have it or not. Some case might require a more refined approach in which the subject has an authorized level that have to be superior or equal to the level required by the object to be granted access to the object. For instance, two persons may have the permission to publish documents but only the CEO can publish Confidential documents.

Finally, a policy can be built by combining requirements to handle complex access rules.

Audit trail

The audit trail is a chronological set of record that provide documentary evidence of the sequence of activities that have affected at any time the system.

The audit trail should include facilities to prevent tampering of the records.