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.
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 c/r/u/d permissions to a role at the collection, field, record, or function level
- Collection level: Scenario 1: Bob is authorized to access collection object CO1 from collection ABC. Bob's attempt to access CO1 from ABC should be allowed. Scenario 2: Roger is a grad student at XYU. Roger wants to access collections of ABC. Without proper authorization from ABC, all requests by Roger to access any part of ABC should be denied.
- Field level: e.g. read permission only for accession numbers, but write permission for the rest of an object record.
- Procedural/Record level: e.g. user can view loan records, but cannot update them. User cannot view valuation records. Scenario 1: Bob wants to update CO1. However, Bob has only read permission to access ABC. Bob's attempt to update CO1 should be denied. Scenario 2: 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. Scenario 3: 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.
- Function level: e.g. user can change the status of a vocabulary term (e.g. provisional add to accepted term).
Admin can assign one or more roles to a user
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?
0 Comments