Staff Permissions

1
Staff Permissions

• Design Review
• Focus Group Conference Call
• October 6, 2005

2
Design Review Session Objectives

• Outline the problems
• Review solutions introduced in version 18
• Present additional development solutions
  scheduled for version 19
• Discussion

3
Design Review Introduction

• Two phase implementation
• Management of users
• More information
• Control
• Reports
• Access rights and UI workflow
• Task-oriented framework
• Roles
• Limitation by administrative unit (sublibrary,
  order unit)

4
Staff Permissions The Problems

• Granularity of the permitted actions makes it
  difficult to assign user permissions.
• Permissions are transaction-oriented and not
  task-oriented.
• Role structure includes both the role and the
  administrative unit (sublibrary).
• Lack of management procedures and reports.
• Request for enhanced personal details and
  additional password attributes.

5
Alternatives and Solutions

• Implement a mechanism that is task-oriented and
  not transaction-oriented (changes in the UI,
  creation of profiles, changes in the
  infrastructure).
• Add standard administrative attributes to the
  staff account.
• Implement standard password management practices
  and polices.
• Provide detailed documentation.

6
Task-Oriented vs. Transaction-Oriented

• Example
• Permission for Order Update requires separate
  additional permissions for
• View List of Orders
• Retrieve Order Information
• View Summary Information
• View Order Indexes
• Items Control
• These permissions should be implied within the
  Order Update permission.

7
Task-Oriented vs. Transaction-Oriented

• Examples
• Some permissions are not limited enough.
• When Items Control permission is assigned for the
  ACQ Order librarian, the user has more
  permissions for items than intended.
• Delete permission should always assume update
  permission.

8
Task-Oriented vs. Transaction-Oriented

• The intention is to change the sets of
  permissions, following a task-oriented structure,
  instead of the current action/atom structure.
• The Focus Group can provide insight and
  guidelines on task workflow and the permissions
  required.
• Two-pronged attack
• Re-organize access privileges grouping.
• Provide logical well-defined and documented roles.

9
Task-Oriented vs. Transaction-Oriented

• Following is an example of a simplified set of
  privileges within a task-oriented structure
  (Acquisitions)

10
Permissions Mechanism

• The permissions check is currently performed when
  an update action is attempted.
• The intention is that the system will determine
  the users rights upon sign-in or when accessing
  a function, rather than each time the user
  attempts to perform a task (for example, check
  before filling a form, not after it has been
  filled and is submitted).

We dont want our users to look like him
11
Roles

• Ex Libris will create sets of roles (profiles)
  with pre-defined privileges.
• For example, for Acquisitions we could provide
  profiles for the following roles

Acq. Manager
Acq. Librarian (Ordering)
Acq. Librarian (Financing)
Acq. Student
12
Roles

• In addition to the pre-defined set of roles,
  libraries will be able to create new roles,
  according to the institutions needs.
• The user account for a role will be identified by
  a new flag Group (Yes/No). If the flag is set
  to Yes, the account will serve as role, and not
  as an actual account.

13
Permissions View

• The Users will be displayed in a hierarchical
  view, in order to graphically represent the
  accounts

14
Permissions Interface

• The privileges that can be/have been assigned
  will be displayed in a window divided into tabs
  for each major function / module

15
Administrative Unit Identification

• Enable assignment of the administrative
  environment of the users sphere of activity.
• Assignment at the level of the user, instead of
  at the level of each particular activity.
• This implies that user must login separately for
  each different environment.
• A user can be empowered for all units (i.e. by
  being empowered for the ADM library).

16
Administrative Unit Identification

• Administrative unit identification is determined
  by the contents of the USER-LIBRARY field.

17
Permissions Assignment

• Users that create new users will be able to
  assign only the permissions which they themselves
  have been assigned.
• For example
• if the administrator was not assigned
  cataloging access rights, he will not be able to
  assign cataloging privileges to the users he
  creates.
• If the administrator was not assigned
  permission for re-indexing, he will not be able
  to assign this privilege to the users he creates.

18
Password Management v. 18

• Additional staff details and password attributes
• Personal information
• Blocking
• Expiration
• Password structure
• Administrative reports
• Staff GUI changes

19
Password Management

• In version 18 additional fields for staff details
  have been introduced

20
Fields Added in Version 18

• OPEN-DATE
• UPDATE-DATE
• EXPIRY-DATE
• LAST-ALERT-DATE
• LAST-LOGIN-DATE
• BLOCK (Y/N)
• BLOCK-REASON (200).
• NO-FAIL (login failures)
• OLD-USER-PASSWORD

• NAME (100).
• DEPARTMENT (100).
• EMAIL (100).
• ADDRESS (200).
• TELEPHONE (20).
• NOTE-1 (200).
• NOTE-2 (200).
• PRINTER-IDs

21
Standard Password Structures (optional)

• Each site will be able to set the minimum length
  for passwords.
• System can be set so that passwords must be a
  combination of alpha and numeric characters.
• The system can require a password change
  immediately after first login of new users.
• Users can be locked/disabled after not in use for
  a specified period of time.

22
Standard Password Structures (optional)

• The system can require passwords to be changed
  periodically. Features are
• The period will be set by a system variable.
• A message will be provided informing the user of
  the approaching expiry date.
• Forced password renewal will be implemented after
  the expiry date.
• It will not be possible to re-use old passwords
  (up to five).

23
Standard Password Structures (optional)

• It will be possible to set an expiration date to
  the users account (Z66-EXPIRY-DATE).
• It will be possible to immediately block a users
  account by setting the new Block field to Y.

24
Standard Password Structures (optional)

• System can be set so that three failed login
  attempts will automatically block the users
  account.
• The functionality currently available under the
  tab_file_aut table (this table determines the
  users Print IDs) will be integrated into the
  users record.

25
Administration Enhancements

• The following will be developed for reports and
  tracking
• Logging and auditing the changes in users
  authorization records.
• Summary report of access rights by
• User (by individual users or by a group of users)
• Department
• Library/sublibrary
• Reports of users by
• Expiry Date
• Blocked users
• Access rights

26
Administration Enhancements

• Reports will be viewable online and printable.
• Export of data into external programs such as
  Excel and Word will be enabled.
• The Staff Privileges list will enable
  listing/sorting by Username, Name, Department
  Name, Groups.