Authentication and Authorization User Story Summary

User Story Summaries are for capturing notes about broad user stories, or user story themes, related to a particular topic. These may be used as inspiration and source material for creating specific user stories, which may in turn be implemented in various system releases. Some of these broad stories, or themes, may not be implemented in the 1.0 release.

Go to Authentication Functional Requirements Home
Go to Authorization Functional Requirements Home

Security/Authentication

User can login to the system using a name and password

User can request a password reset (lost password)

Admin can create a user profile

Admin can link a user profile to the name authority

Admin can change a user's password

Admin can activate/inactivate a user account

Admin can view/export all user profiles

Roles & Permissions / Authorization / Access Control

Authorization is the process by which a properly appointed person or persons grants permission to perform some action on system resources on behalf of an organization.

Access control means protection of system resources against unauthorized access; a process by which use of system resources is regulated according to a security policy and is permitted by only authorized entities (users, programs, processes, or other systems) according to that policy.

User level permission (rare): User is working on collection object CO2 in collection ABC, and has set exclusive privileges on collection object. CO2. Object CO2 exists only for the specified user.

Tenant level permissions: User has complete administrative (super-user) privileges for ABC over its collection. However, user does not have any access to collection XYZ. Any attempt by user to access XYZ should be denied.

Admin can create one or more roles, e.g. Administrator, Data Entry Clerk Curator, Registrar

Admin can assign no access, read only, create/update, or delete permissions to a role at the collection level

• Happy scenario 1: Bob is authorized to access collection object CO1 from collection ABC. Bob's attempt to access collection object CO1 from collection ABC should be allowed.
• Happy scenario 2: Roger is a grad student at university XYU. Roger wants to access collection ABC. Without proper authorization from collection ABC, all requests by Roger to access any part of collection ABC should be denied.
• Bob wants to update collection object CO1. However, Bob has only read permission to access collection ABC. Bob's attempt to update collection object CO1 should be denied.

Admin can assign no access, read only, create/update, or delete permissions to a role at the procedural level

• Alice is in legal at ABC. She has permissions to access loans. However, she does not have any permission to access CO1. Alice should be allowed to access loan L1 but she should not be allowed to access CO1.
• Bob is authorized to access (view-only) loans. However, he is not allowed to see the transaction details of any loan.

Admin can assign no access, read only, create/update, or delete permissions to a role at the field level

• Carol has write access to collection object C01, but she has read only access to C01's accession number

Admin can assign no access, read only, create/update, or delete permissions to a role at the function level

• Ted can change the status of a vocabulary term from provisional to approved

Admin can assign no access, read only, create/update, or delete permissions at the item level (rare)

• Curator Calvin is working on collection object CO2 at ABC. Calvin has set exclusive privileges on CO2. He does not want anyone at ABC to access CO2. CO2 exists only for Calvin.

Admin can remove one or more roles assigned to a user

Admin can view all roles assigned to a user

Admin can view all users assigned to a role

Questions

What does it look like when a user has read/write permission for only five fields?