Granting Rights to Users

This section provides examples for how you might use roles, groups, and ownerships to grant or restrict rights. It also explains how the order of precedence between security elements determines what rights are granted. Finally, it introduces security levels and explains how they are used to limit the privileges that can be granted to users via roles and groups.

This section explains these topics:

Example 1: Using Roles and Groups

To understand how you might define roles and groups, consider the following example: Suppose you are defining access for a staff that includes catalogers, circulation clerks, supervisors, and a site administrator. To grant each member appropriate access based on job responsibilities, you might create the following roles and groups and assign the users and roles to the groups in this way:

Figure 5-1: Roles and Groups

As shown in this example, you define users and roles, then assign users and roles to groups to give users the access they need. (The roles are actually role/owner pairs, but record ownership is not considered in this example.) Remember that a role defines a set of privileges (for example, a privilege for canceling a hold request or creating a bib record). The individual privileges are not shown in this example.

You can assign a role to more than one group. (For example, the System Basic role is assigned to Cataloging Staff and Circulation Staff to give all users access to basic processes.) You can also assign a user to more than one group. Since Yolanda is a cataloging supervisor, she is assigned to both Cataloging Staff and Cataloging Supervisors. Richard, the site administrator, is assigned to all groups, giving him all cataloging, circulation, and supervisory rights.

Although not shown in the diagram, you assign individual privileges only once—to the role. This reduces the data entry required to grant privileges to users. You should define your roles carefully to make them applicable to as many groups as possible and to minimize the number of times you must assign a privilege to more than one role. In this example, privileges for basic tasks are assigned only once—to the System Basic role. However, the privileges are available to all users because of how the role and the users in this example are assigned to groups.

Once you have set up your roles and groups, making changes is easy. (For example, to grant rights to a new cataloger, all you need to do is create a user record and assign the user to the Cataloging Staff group.) Or, suppose you want to give your catalogers access to basic circulation processes. To do this, you would simply assign the Circulation Basic role to the Cataloging Staff group. All the users assigned to the group now have access to the privileges included in this role.

The purpose of this example is to give you an idea of what you can do with roles and groups. You can define your own roles and groups however you want to, according to the needs of your library.

As this example shows, roles and groups provide a great deal of flexibility for granting rights to users. You can assign one or more roles to one or more groups, and one or more users to one or more groups, as needed. Groups provide an extra level of organization that make the administration of privileges more flexible and easier to change, especially if you have many users who need various levels of access. Groups also provide an efficient method for granting rights by ownership, as shown in the next example. Smaller libraries that do not have these requirements may simply create one role per group in many instances.

If a user has multiple roles and there are conflicting rights between roles (specifically, conflicting permissions or CRUDO settings), the higher rights always take precedence. (For example, if a user has a permission of Approval Required for a privilege in one role, but a permission of Full for the same privilege in another role, the Full permission is granted.)

Example 2: Using Record Ownership

To understand how you might use record ownership to restrict rights to specific sets of records, consider the following example: Suppose your library has three locations and you want to restrict access to bib and authority records by location. You might define owners, roles, and groups this way:

Figure 5-2: Ownerships

In this example, the two roles include CRUDO settings to provide access to bib and authority records. One provides full rights for accessing and editing records; the other provides view-only rights. Notice the “Role/Owner Pairs” assigned to groups 1 and 2. As shown in Figure 5-1, you associate a role with an ownership when you add the role to a group. For processes that use record ownership, this restricts the rights defined in the role to specific sets of records (specifically, records owned by the owner you associated with the role). Notice that you can assign a role to a group multiple times, but only once per ownership.

In this example, Mary and Bill have editing rights for bib and authority records owned by libraries A and B, and view-only rights for records owned by Library C. Hosea has editing rights for records owned by Library C, but has view-only rights for records owned by libraries A and B. Notice that Jane is assigned to both groups, which means she has editing rights for all records. Jane’s higher privileges take precedence. Her full cataloging roles for libraries A and B in the Group 1 override her view-only cataloging roles in Group 2, and her full cataloging role for Library C in Group 2 overrides her view-only cataloging role in Group 1.

Hierarchy of Rights

In the new security system, Horizon uses the following order of precedence to determine whether or not a user has access to processes and data:

1. Privilege
2. Permission
3. Ownership
4. CRUDO

First, Horizon determines whether the user has rights to the privilege. Second, Horizon may limit the privilege based on permission (Full or Approval Required). Third, for processes that use record ownership, Horizon determines whether the user has rights for the current record based on the user’s role/owner pairs. Finally, Horizon may further restrict rights for editing the record based on CRUDO settings.

Security Levels

In general, security levels limit the privileges that can be granted to users via roles and groups. You assign security levels to role privileges, users, roles, and groups. Here are the security levels, shown in order of most access to least access:

Sys Admin. Intended for the library system administrator only. When assigned to a user, gives the user full access to all role privileges and to all data immediately. No other setup is required except to give the user access to processes controlled by passkeys. This security level is unique in that it grants rights; the other security levels simply limit the privileges that can be granted to users.
Local Admin. Intended for local system administrators who need access to privileges that require a high level of security.
Supervisor. Intended for supervisors who need access to certain privileges not available to general staff.
Staff. Intended for general staff who need access to only basic, job-related functions.
Guest. Intended for individuals to whom you want to grant only very limited access. (For example, a college library may use this security level for faculty who need to perform a limited number of tasks, such as entering purchase requests in Acquisitions or checking on the status of orders.)

The security level you assign to a role limits the privileges that can be assigned to the role. (For example, a role with a security level of Staff means that only privileges with a security level of Staff or Guest can be assigned to the role.)

The security level you assign to a group limits the users and roles that can be assigned to the group. (For example, a group with a security level of Supervisor means that only users with a security level of Supervisor or Local Admin can be assigned to the group. Users with a security level of Sys Admin could also be added to the group, but this is not necessary since these users are given rights to all role privileges and all data automatically. Also, only roles with a security level of Supervisor or lower can be added to the group.)

 


© 1998-2017 Sirsi Corporation