(*) - Needs further clarification
User Management Feature Overview
As Admin App moves towards incorporating a Multiple Instance mode (AA-602), the existing user management system for the app needs an upgrade to handle user access to different ODS instances. The vision is to allow Admin App for single instances to remain as-is, however if enabled for multiple instances via configuration, additional screens will be added to handle core administrative functions for the selected instance. The proposed user management solution takes into the account two main types of Admin App users: A Local Education Agency (LEA) Admin - A single admin who can have access to any number of ODS instances provided they have been assigned to them by the Collaborative Admin. Sometimes, multiple LEA Admins maybe assigned to a single district.
(*) Is "LEA Admin" an appropriate name, in general? Are these always at the LEA level, or should we use a more generic term?
...
- Super Administrator - A Super Administrator has the ability to explicitly assign ODS instances to a specific
...
- Administrator. A Super Administrator is intended for an IT Administrator at a collaborative who is responsible for setting up instances for individual LEAs. This type of user also has the ability to add/delete/update the connection of an ODS instance, add a new
...
- Administrator, assign a role to an
...
- Administrator and edit settings for an
...
- Administrator.
- Administrator - A single admin who can have access to any number of ODS instances provided they have been assigned to them by the Super Administrator. Sometimes, multiple Administrators maybe assigned to a single instance or multiple instances to an Administrator.
Current User Management System
The current Admin App is based on the assumption of a single ODS instance managed by one or multiple users.
...
A single login system approach via ASP.Net Identity may help in simplifying the user management process as it provides the following advantages:
- Provides control over the schema of user profile and other user-related information. Eg. Can add custom fields to the Users table.
- Allows for Unit testing of the Identity features of the application
- Has a built-in Role provider infrastructure
- Avoid binding the users to Active Directory authorization
- Avoid challenges faced in maintaining a 3-fold registration process. See Appendix for the issues faced with that approach.
Roles
As mentioned above the two major roles that arise in a multi-instance configured Admin App are Collaborative Admins and LEA Admins. Super Administrator and Administrator. Following is an overview of the permissions these roles can have:
1. Collaborative Admin Super Administrator (Default role for the first user)
Permissions
- Can add a User
- Can add/update/delete connection to an ODS Instance
- Cannot access all Student Data/ ODS Instance Data (*)
- Can change/assign an ODS Instance to an added user (*)
- Only serves as an admin for the users (*)
- Can change user settings for other users(*)
- Can delete a User User
- Permissions of Administrator below
2. LEA AdminAdministrator (Default role for subsequent users added by the Collaborative Admin Super Administrator)
Permissions
- Can only access the assigned ODS instance
- Can only change its own user settings
Discussion and Questions (*)
The following section contains discussion related to Roles and questions that arise related to their respective powers:
- The roles discussed above are not mutually exclusive. There might be cases where a single individual is assigned both the roles. Limiting the access of a collaborative admin to only user management aspects of the Admin App allows for a distinction between roles and avoids giving unwarranted access to all the ODS instance data using the Admin App.
- This raises a question of how far should the Admin App go to prevent an admin from granting themselves elevated access: Can Collaborative Admins assign themselves an LEA role and associate with a district? Can (PO: Yes) Can Collaborative Admins create other Collaborative Admins? (PO: Yes) Limiting such elevation may not be Admin App's responsibility, since the collaborative surely has its own policies in place governing access by admin personnel. However, Admin App could provide a simple check on admins: a possible requirement to consider can be to prevent Collaborative Admins from changing their own roles and ODS instance connection assignments. Therefore, having only the ability to add a new Collaborative Admin with a distinct email address who can in turn give the original Collaborative Admin the appropriate roles and ODS instances helps in curbing the administrative power of a Collaborative Admin. However, these measures could be circumvented via email aliases or simply by having malicious actors collaborate.
Expected user feature changes due to the proposed user management for Multi-instance mode
Assuming we take the one login system approach. Following sections give an overview of the expected changes:
...
Assign ODS instance to users: Assigning ODS Instance to a user. Save the information in the adminapp.UserODSInstances table.
Expected Architectural changes
Permission Enum: An enum is used to define the set of permissions for the Admin App in terms of ODS instance access, user management etc. An enum is used here to facilitate the use of a RequirePermission filter attribute allowing a controller action to forbid access when a logged in user lacks a given permission. This allows us to easily apply permission rules to any action. An example Permission enum for Collaborative Admin may look like this:
...
Tables:
- Since the ASP.Net identity schema being currently used already includes adminapp.Roles (Id, Name) table keeping track of a Role entity with a unique Name field, we don't need to create an additional table for roles.
- The adminapp schema also includes an adminapp.UserRoles (UserId, RoleId) table used to keep track of the roles assigned to a user. A single user maybe assigned multiple roles as discussed above. An alternative would be to hardcode the Roles/Permissions associations since there are few roles and permissions. We can pivot to a table once the complexity grows to warrant it.
- Each Role can have multiple Permissions associated with it. So, we need a new table adminapp.RolePermission(Id, RoleId, Permission) to associate roles to permissions. The Permission field here will be an INT mapping to the Permission Enum's explicit int values.
- A new table adminapp.ODSInstance (Id, InstanceName) to keep track of the ODS instance entity with a unique field InstanceName field. (*) The ODSInstance will likely have more fields besides the two mentioned
- A new table adminapp.UserODSInstances (UserId, InstanceId) to keep track of the associations between Users and associated ODS instances.
Migration Scripts (for both MsSql and PgSql):
- Creation script for the new tables
- Initialization script to populate the "Collaborative AdminSuper Administrator" and "LEA AdminAdministrator" roles in the adminapp.Roles table
- Assigning appropriate roles to the already existing users in the database (*) Can be ignored if the Admin App is always being installed from scratch
- Initialization script to populate the permissions along with their associations to "Collaborative AdminSuper Administrator" and "LEA AdminAdministrator" roles in the adminapp.RolePermssions table
Code Changes:
- A new RoleController containing an AssignRole action to assign a Role to the user.
- A UserController containing actions like AddUser, DeleteUser, EditUser and GetUsers to perform user management.
- An InstanceController containing actions like AssignInstanceToUser to assign ODS instances to the users.
- Models for entities like Role, UserRole and RolePermission
- ViewModels and Command Handlers for actions like AssignPermission, AssignRole, AddUser, EditUser, AssignInstanceToUser and GetUsers.
- Add unit tests for the command handlers added.
New Screens:
- A screen to list the admin app users along with their Roles, ODS Instances Assigned and Edit links for the Collaborative Admin. This screen will be similar to the ClaimSetEditor claimset index page
- A screen to edit user settings like Roles and ODS Instances assigned.
Appendix
Supporting Multiple Login Systems
Although, the ideal approach is to move towards a single Login system. If we consider supporting a multiple login system approach, we might face some challenges:
...