(*) - Needs further clarification
User Management Feature Overview
As Admin App moves towards incorporating a Multiple Instance mode (AA-602), the existing user management 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 the two main types of Admin App users:
A Local Education Agency (LEA) Admin - A single admin 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 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.
A user can log into the the system via the following 3 ways:
1. Windows Authentication
Admin App currently supports Windows Authentication which is used when the IIS server runs on a corporate network using Microsoft Active Directory service domain identities or other Windows accounts to identify users.
2. Azure Active Directory
Admin App also supports Azure AD for the Admin App cloud deployments.
3. ASP.Net Identity
The Admin App recently incorporated ASP.NET Identity system into the application based on Ed-Fi community feedback indicating a preference towards authorization approaches other than Active Directory. ASP.NET Identity offers secure web-form authentication as an alternative to the Active Directory support built-in today. ASP.NET Identity is expected to work seamlessly within different deployment environments, specifically including cloud deployments. The ASP.NET Identity feature is a preview feature for v3.4 and disabled by default with a new installation of the Admin App. Based on usage and field reports, we intend to publish a production-ready version in Admin App v1.9 for ODS / API v3.5 and beyond.
The first user registered via ASP.Net Identity also has the ability to add new Users on their behalf.
As mentioned above, the ASP.Net Identity system is the only currently supported Admin App login approach that facilitates addition of new users. With the multi-instance mode, there arises a need to overhaul the current user management system to accommodate assignment of ODS instances to different users and keep track of the associations between the admins and the student data they have access to. Furthermore, it is in the best interest to future-proof the application by laying the infrastructure for user role assignment to allow for easy addition of new roles to users.
A one login system approach via ASP.Net Identity may help in simplifying the user management process as follows:
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 permissions these roles can have:
1. Collaborative Admin (Default role for the first user)
Permissions
- Can Add A New 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 (*)
2. LEA Admin (Default role subsequent users added by the Collaborative Admin)
Permissions
- Can Add A New User (*)
- Can only access the assigned ODS instance
- Can only change its own user settings
Discussion and Questions
The following section contains discussion related to the roles and some questions that arise related to their respective powers:
- The roles discussed above may not be exclusive to users and there might be instances 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 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 Collaborative Admins assign themselves an LEA role and associate with a district?
- Can Collaborative Admins create other Collaborative Admins? If yes, this can also serve as a check to the power of the original Collaborative Admin in elevation of privileges.
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:
Existing Features to be modified
Registration Flow: New users would be assigned a default role as soon as they are registered. Changes in the Register command handler are foreseen.
Login Flow: Check for user role on startup to determine whether certain screens and features are enabled/disabled (shown/hidden). Adding a filter attribute to check for the permissions of the user logged in might be a good idea in this case.
Add User Flow: New users created by the Collaborative Admin would be assigned a role as soon as they are created. Changes in the Add User command handler are expected.
New Features to be created
Add Roles for users: Adding/Assigning a role to a user. Save the information in the adminapp.UserRoles table.
Add permissions to roles: Adding/Removing Permissions to/from a UserRole. (*)
Assign ODS instance to users: Assigning ODS Instance to a user. Save the information in the adminapp.UserODSInstances (UserId, InstanceId)
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 LEA 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.
- 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.
- A new table adminapp.UserODSInstances (UserId, InstanceId) to keep track of the associations between Users and associated ODS instances.
Migration Scripts:
- Creation script for the new tables
- Initialization script to populate the "Collaborative Admin" and "LEA Admin" roles in the adminapp.Roles table
- Assigning appropriate roles to the already existing users (*)
- Initialization script to populate the permissions along with their associations to "Collaborative Admin" and "LEA Admin" 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, 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.
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 field records 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.
How does moving away from Azure 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)
- Safe Removal/Refactor of Azure Active Directory infrastructure from EdFi.Ods.AdminApp.Web (AzureInstaller.cs, Infrastructure/CloudOdsAdminAppSettingsForAzure.cs, Infrastructure/CloudOdsAzureActiveDirectoryClientInfo.cs)