(*) - 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.
...
A Collaborative Admin - A collaborative admin has the ability to explicitly assign ODS instances to a specific LEA admin. This type of user also has the ability to add/delete/update the connection of an ODS instance, add a new LEA admin, assign a role to an LEA admin and edit settings for an LEA admin.
Current User Management System
The current Admin App is based on the assumption of a single ODS instance managed by one or multiple users.
...
Trying to incorporate the multi-instance user management across all the existing registration systems can be challenging and may yield future complications.
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. Following is an overview of the permissions these roles can have:
1. Collaborative Admin (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
2. LEA Admin (Default role for subsequent users added by the Collaborative Admin)
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 Collaborative Admins create other Collaborative Admins? 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:
...
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:
...