(*) - 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 may are not be exclusive to users and there mutually exclusive. There might be instances 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 does not give avoids giving unwarranted access to all the ODS instance data using the Admin App. This distinction between the roles can, however, be ignored if the organization desires to assign the both the roles to the same user.
- Can
- 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?
- (PO: Yes) Can Collaborative Admins create other Collaborative Admins?
If Yes, this can also serve as a check to the power of the original Collaborative Admin during elevation of privileges. A possible (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. Although these restrictions can possibly be circumvented, we can rely on the Collaborative organization to ultimately handle any malicious Collaborators. On the other hand, if there is a need to have the Collaborative Admin as an all-encompassing super user, we can ignore such restrictions. 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:
- Since the current Admin App already supports adding users and assigning roles to the users under the ASP.Net Identity system, it makes sense to use the infrastructure for the other login systems as well. However, this poses a challenge as we don't have granular control over the other systems. For Eg. for each new user registered with the ASP.Net identity system, a record is created in the existing adminapp.Users table. However, we currently don't have a similar record for the Windows authenticated or Azure AD authenticated user. If we decide to create dummy records manually using the login information from these two login systems, we might not be given adequate access to all the information needed to have a complete record of the user. This might, further, create problems as the user table might have a mixed bag of users with empty fields in some cases. We also, then, have to keep track of the login system used by the user and make schema changes to accommodate that.
- Another approach to support multiple login systems can be to maintain an external Roles table and keep track of the different types of users there. However, this leads to several overheads of keeping an additional column to keep track of the login system as well as maintaining an extra Role table.
- ASP.Net Identity provides an easier way to customize the user schema and tailor it according to the requirements. Customizing the other login systems in a similar vein to ASP.Net Identity may prove to be challenging.
How does moving away from Active Directory affect the application code base?
- Safe Removal/Refactor of Azure Active Directory infrastructure from EdFi.Ods.AdminApp.Management.Azure and the corresponding tests from EdFi.Ods.AdminApp.Management.Azure.IntegrationTests
- Safe Removal/Refactor of Azure Active Directory infrastructure from EdFi.Ods.AdminApp.Web (AzureInstaller.cs, Infrastructure/CloudOdsAdminAppSettingsForAzure.cs, Infrastructure/CloudOdsAzureActiveDirectoryClientInfo.cs)
- Refactoring the Web.config transform files to set Windows authentication mode to false.
- Safe Removal/Refactor of unit tests testing Azure Active Directory integration.
- Thorough testing of the registration/login process on the On-Premise and Azure versions of the Admin App.
Expected Tickets
Following are some of the major expected tickets for the feature in the order of implementation (from start to finish):
...
Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-777 Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-778
(Create the User List pageJira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-779 - Implement/Refactor Add User
- Implement Delete User
- Implement Edit UserImplement )
(Implement Edit User)Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-780
(Implement "Assign ODS Instance to User")Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-781
(Implement Role Assignment in Edit User, Create Role and Permission models and required tables)Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-782
(Implement Role Assignment in Edit UserDelete User)Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-783
(Enforce Permission requirements on controller actions)Jira Legacy server Ed-Fi Issue Tracker serverId e04b01cb-fd08-30cd-a7d6-c8f664ef7691 key AA-785