What is the authorization concept?

The strength of Password Safe version 8 lies in the fact that it provides the right solution to all conceivable demands placed on it with regards to authorization management. In order to keep the manual work to a minimum, handling several users at once via roles is a tried-and-tested method. The setting of the permissions for these roles can either be completed manually or automatically. There are a number of variants for both options, which are explained in detail in the following sections.

Alongside the definition of manual and automatic setting of permissions, the (optional) setting of protective mechanisms forms part of the authorization concept. The protective mechanisms are thus downstream of the permissions. The interrelationships between all of these elements are illustrated in the following diagram.

Before the manual and automatic setting of permissions and the possible protective mechanisms are covered in the next section, it is still necessary to explain the basic mechanics of the authorization concept here. These three cornerstones are irrevocable and always impact permissions of every type.

The three cornerstones of the authorization concept

The reproduction of company-specific authorization structures can vary greatly in terms of effort. However, small working groups as well as international corporations are generally subject to the same rules with regard to administration in Password Safe. The basic concept is based on only a few rules which always apply without exception. Despite the innumerable individual adjustment screws, these basic rules can be summarized in three essential steps.

1. Permissions only for users or roles

If the authorization for a data record is to be defined, there are basically only two possibilities:

  1. Authorization for a user
  2. Authorization for a role

A role is technically nothing more than a summary of multiple users with the same permissions. It is, of course, a good idea to manage these roles in accordance with your company’s activities. The role “Administrators” can therefore be provided with more extensive authorizations than, for example, the role “Sales Assistance”. This role-based inheritance allows the organization to maintain the overview in a larger corporate structure as well as a simple procedure when adding new employees. Instead of having to entitle him individually, this is simply added to his role.

It is obvious to proceed with the organization of accesses using the concept of roles as a basis and only to grant rights individually to employees in exceptional cases. The unplanned absence of personnel must also be taken into account in such concepts. Working with roles defuses such risks significantly.

2. Membership in roles

The key point is membership in a role. If an employee can use the authorizations according to the roles assigned to him, * he must be a member of the role *. Only members see the records that have been authorized for the role.

3. Membership vs. permissions for roles

The admin user in Password Safe must pay particular attention to the interplay between users and roles. This dynamics is crucial for understanding the concept of authorization, in order to ensure maximum software adaptability to any corporate structure. The following diagram illustrates this with an example of two users.

  • User 1 is a member of the role, and is therefore authorised for all records that are assigned to the role. However, it has only “read rights” for the role itself. This means, it can see the role, but cannot “Edit, move, or delete” it.
  • User 2 has all rights for the role. It can add additional users to the role by means of “authorise”. The crucial point, however, is that it is not a member of the role. It cannot, therefore, see any records for which the role is authorized.

In practice, the first user would be a classic user that is assigned, for example, to the Sales role by the administrators, and can view the records accordingly. The second user could be one of those administrators. This user has extensive rights for the role. It can edit it, and add users to it. However, it cannot see any data that is assigned to sales. It lacks membership in the role.

Specific example and configuration

Similar to the previous section (Membership vs. rights to roles),, the configuration of a role will be illustrated using two users. The configuration is performed in the Client Module Roles. By double-clicking on the role “IT-Consultants” in the list view, you can open their detailed view.

  • The user “Holste” is a member of the role and can, therefore, access those records for which the role has permissions. He has the obligatory read right for the role, which is the basic requirement in order to be a member of the role. Which exact rights it has to the data record is not defined within the role! This is set out in the following section.
  • The user “Administrator” has all rights to the role, but is not a member! Thus, it cannot see any records that are authorized for the role. However, it has all rights to the role and can therefore print, assign other users to the role, and delete them.

This example clearly shows the advantages of the concept. The complete separation of administrative users from regular users brings significant advantages. Of course, one does not necessarily exclude the other. An administrator can, of course, have full access to the role and also be a member in it! The boundaries between the two often overlap, and can be freely defined in Password Safe.

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.