Definitions

• Role: A role is Alma’s term for a permission that can be assigned to a user.

• Role profile: A role profile is a group of roles, defined by a user administrator, that can be assigned to a user.

• Least privilege: An operating model in IT Security that means providing users access only to the resources (networks, systems, files and data) that are necessary to perform their assigned job functions.

• DUL Department head: Any individual listed as the head of a department at https://directory.library.duke.edu/dept

• Segregation of duties: Segregation of duties means dividing mission or business functions among different individuals, and ensuring that personnel who administer access control functions do not also administer audit functions.

• Just-in-time access principle: Administrative access to systems will be granted on a just-in-time basis, governed by a strict policy to ensure access is provided only when necessary.  E.g., having a role granted “just-in-case” is usually not sufficient justification for permissions.

Requirements for adding permissions to users

Follow a “least privilege” model

Assign only the permissions needed for someone to do their work in Alma, and no more.

In some cases, Alma’s roles do not allow us to do this because they are structured differently than we would prefer. In those cases, we may grant the broader role while establishing logging and monitoring of reports and other audit procedures to ensure that we are following university policy.

Assign permissions using Role Profiles

Permission requests for staff must be authorized by their manager or department head

Permission requests for staff should come from a staff member’s manager or department head.

This is for requests for all staff, including non-full time staff such as student employees, interns, volunteers, or practicum students.

If the manager or department head is not available, the request should come from their Executive Group member.

DUL Department head access

Department heads may request changes or additions to their roles for their own Alma account as long as:

• the requested permission is in their functional area;

• the requested permission provides for adequate segregation of duties

• the requested permission is not a full administrator role with read and write functionality;

  • note that some administrator roles can be assigned in a “read-only” mode (https://duke.atlassian.net/wiki/spaces/LIB/pages/edit-v2/252182529#Read-only-Administrator-Roles ) - department heads may request read-only administrator roles for their accounts

LSIS staff will evaluate the request. If there are concerns, LSIS will explain the concerns to the department head and attempt to resolve.

If the concern cannot be resolved, LSIS will escalate the issue via email to the Executive Group and notify the department head that they have escalated the issue. In these scenarios, the DUL Executive group would decide how to resolve the access issue.

Requests must be sent as a ticket through support.lib.duke.edu

Permission requests must be received in writing as a ticket request, assigned to the Alma queue, via https://support.lib.duke.edu.

Documentation of permission requests shall be retained

Documentation of requests for Alma permissions shall be retained, including tickets and/or emails.

Alma accounts must not be shared

Alma access is tied to your Duke NetID and password. Duke policy is that NetIDs and passwords are only to be used to be the NetID owner and may not be shared with others.

Roles for student employees, interns, practicum students, volunteers, and time-limited projects must have expiration dates

If a role is needed for a project that has a known end date, the role should be set to expire when the project ends.

Roles assigned to student employees, interns, practicum students or volunteers must have expiration dates assigned.

The expiration date will be set to May 15th of the current academic year, or the end of the student’s employment, if sooner.

Permission assignments must be reviewed periodically, annually at a minimum

When someone needs a specific role profile, plus additional permissions

The Libraries may have staff who fill a specific role, but need one or two additional permissions that are not covered in an existing role profile.

When evaluating these requests, LSIS:

• reviews the request in line with university best practices for IT security, including assigning the least amount of permissions necessary

• consults with subject matter experts to ensure that they have an opportunity to raise concerns with any expanded access or workflow changes;

• discusses any concerns about the request with the manager who asked for the additional roles.

If concerns about the request cannot be resolved, LSIS will escalate the issue to the Executive Group for resolution.

Alma Analytics

See https://duke.atlassian.net/wiki/spaces/LIB/pages/141984329 for guidance on granting Analytics roles.

Read-only Administrator Roles

Several Alma administrative roles have a “read-only” mode, that allows access to see settings without changing them. These can be useful for staff when troubleshooting or trying to learn more about Alma functionality.

Those read-only roles can be granted to staff at their manager or department head’s request.

Administrator roles for non-full-time library staff

Student employees, interns, practicum students and volunteers with Alma accounts should never be granted an administrator role (read-only or otherwise.)

Administrator roles for non-systems-administration staff

Some non-systems administrators may receive administrative roles if

• The role is requested by their department head (or themselves, if they are a department head);

• The role is required to carry out part of their day-to-day job, and cannot be done any other way;

  • For example, there are areas in Summon configuration that can only be managed if you have the Fulfillment Administrator role.

• Monitoring can be established, if needed, to address affective internal controls

In these cases, LSIS may establish reporting to periodically review activity to be in compliance with university IT policy.

Roles for supporting employee training

There may be cases where staff request roles for themselves to prepare for training other staff.

This would apply in cases where a staff member with a role scoped to one library needs to train a staff member scoped to another library, and they want to be able to see what the trainee would see on their own Alma account.

LSIS staff may support these requests by creating dummy accounts on the premium sandbox, if the following applies:

• The requested roles are at the same level, or lower level, than roles already assigned to the trainer (e.g., if the trainer has circulation desk operator, they could request circulation desk operator in another scope, but not circulation desk manager.)

• The requested roles are time-limited and set to expire after the employee training is complete.

When an employee remains in the libraries, but changes positions

The manager or department head in the new position must submit a service ticket at https://support.lib.duke.edu. Assign it to the Alma group.

The following information is required.

• Staff member name

• Staff member’s unique ID netid;

• Whether the new staff member is a student employee, intern, volunteer, or full-time employee;

• First day of starting in new position;

• Last day of employment (if known);

• Requested role(s) or role profile(s) (see https://duke.atlassian.net/wiki/spaces/LIB/pages/90702619 )

When an employee leaves a position

When a staff member is leaving or has left their position, the staff member’s manager, supervisor, or department head must submit a service ticket at https://support.lib.duke.edu to the Alma queue as soon as the employee’s last working date is known.

The following information is required. Please use a spreadsheet if you are notifying about more than three departing staff members.

• Staff member name

• Staff member unique ID or staff member netid;

• Departure date;

If the nature of the staff member’s departure requires urgent coordination of removal of access, managers should reach out to @Karen Newbery to discuss as far in advance as possible.

Note that if the employee is leaving Duke entirely, their Alma account will expire the day that their departure is recorded in the identity management system. Even so, we remove the role(s) in case the employee later returns to Duke.

Administrator responsibilities for updates to role profiles

Submit a ticket to the Alma queue (https://support.lib.duke.edu) with your proposed changes. Please explain why the changes are needed.

LSIS will evaluate the request according to IT security policies, and consult with appropriate subject matter experts as needed to ensure the proposed change is appropriate from their perspective.

Assuming no concerns are raised, the profile can be changed or the new profile can be created.

Once the profile is changed or created, it can be assigned to existing staff at the request of their department head.

If concerns cannot be resolved in discussion, the issue can be escalated to the appropriate members of the DUL executive group.

After the profile is changed, additional work is needed to ensure that the change propagates to other staff who need the role. Analytics can be used to identify those staff members.

Subject Matter Experts for Consultation

Subject matter experts listed below may be consulted by LSIS when updates to role profiles are requested, and when additional permissions are requested for staff outside of their specific role. Staff listed below will talk to additional colleagues, stakeholders, and interested parties as needed to make sure any permissions concerns are represented in discussions.

• User Management

  • Head, Access and User Services, Duke University Libraries (or DUL EG designee)

• Fulfillment

  • Head, Access and User Services, Duke University Libraries (or DUL EG designee)

• Acquisitions

  • Head, Monograph Acquisitions, DUL Collections Services (or DUL EG designee)

  • Head, Electronic Resources & Serials Acquisitions, DUL Collections Services (or DUL EG designee)

• Metadata Management

  • Head, Metadata & Discovery Strategy, DUL Collections Services (or DUL EG designee)

  • Head, Resource Description, DUL Collections Services (or DUL EG designee)

  • Head of Technical Services, David M. Rubenstein Rare Book & Manuscript Library (or DUL EG designee)

• Inventory

  • Head, Metadata & Discovery Strategy, DUL Collections Services (or DUL EG designee)

  • Head, Resource Description, DUL Collections Services (or DUL EG designee)

  • Head of Technical Services, David M. Rubenstein Rare Book & Manuscript Library (or DUL EG designee)

  • Head, Electronic Resources & Serials Acquisitions, DUL Collections Services (or DUL EG designee)

• Discovery

  • Head, Metadata & Discovery Strategy, DUL Collections Services (or DUL EG designee)

• Miscellaneous

  • Head, Library Systems & Integration Services, DUL Digital Strategies and Technology (or DUL EG designee)

Change log

Archive

Archived - Guidance for User Administrators