(*) - 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?
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.
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. Azure AD is a multi-tenant cloud based identity and access management solution for the Azure platform to provide secure access for organizations and individuals.
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. This provides a chance to look at ASP.Net Identity closely and lay the foundations of a move towards user management for a multi-instance Admin App.
The first user registered via ASP.Net Identity also has the ability to add new Users on their behalf. 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 provides an opportunity to future-proof the application by laying the infrastructure for user role assignment to allow for easy addition of new roles to 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:
Existing Features to be modified
Registration Flow: New users would be assigned a default role as soon as they are registered.
Following changes in the Register command handler are foreseen.
- The existing logic to check whether the user has AllowUserRegistration feature can be safely removed as we move towards role-based users
- Assigning the default role for the first user (Collaborative Admin)
- Assigning the default role for the subsequent users (LEA Admin)
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
Permissions: Adding a Permissions based filter attribute to allow a page/action to be protected with a RequiredPermission attribute. If the required permission for an action is contained within the list of permissions for users based on their roles, the user is allowed to access the page/action. This would involve adding a RequiredPermission attribute over the actions that are needed to restricted.
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. (*) This is a future concern as currently the list of Permissions is fixed (with an enum) at development time
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:
public enum Permission
{
AddUser = 1,
AssignODSInstance = 2,
DeleteUser = 3,
AssignRole = 4
}
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 Admin" and "LEA Admin" 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 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, 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.
Expected Tickets
Following are some of the major expected tickets for the feature in the order of implementation (from start to finish):
- AA-777 - Getting issue details... STATUS
- AA-778 - Getting issue details... STATUS
- Create the User List page
- Implement/Refactor Add User
- Implement Delete User
- Implement Edit User
- Implement "Assign ODS Instance to User"
- Create Role and Permission models and required tables
- Implement Role Assignment in Edit User
- Enforce Permission requirements on controller actions