Administrator roles
There are three different administrator roles within tiCrypt; super-admin, admin, and sub-admin. Just like everything else in tiCrypt, there is a need for security which is implemented with an administrator hierarchy.
Super-administrator
A super administrator is the highest role in the system. This user can do ANYTHING in the system, however, the main purpose of a super-admin user is to manage global or system-wide settings such as deployment settings. Superadmins are also responsible for accessing and restarting system services. Super-admins can modify all types of users. This role is limited to a very select few administrators within the organization. Again, all admins (including super admins) do not have access to the user data unless a user explicitly shares the data with the admin.
Administrator
Admins are managers of the entire system. This role is defined as a traditional system manager role with no access to user data unless explicitly shared. Admins can only modify basic user and sub-admin permissions. Admins cannot modify super-admin permissions nor can they do the tasks specific to super-admins stated above.
Sub-administrator
Sub-admins within the system are the lowest level of administrators. A sub-admin role allows specific users to act as administrators within the tiCrypt system for their team. Admins in the system assign a managed object to the specific sub-admin.
The sub-admin has access to the Management tab within the tiCrypt system, just like the admins above, but sub-admins would only list members, VMs, projects, etc., associated with the admin’s assigned team. This allows for a sub-admin to activate team members, change team members' permissions, manage tiCrypt projects, or any other admin action for that specific team only.
Three guiding principles act as rules for a sub-admin.
If a user is deactivated and belongs to no team, a sub-admin can place this new user into their team. This allows for sub-admins to onboard and activates users without the need for a Super Admin/UMD IT Admin. This rule prevents the sub-admin from managing already existing members in the system that are not part of the defined team.
If a user explicitly belongs to a team, then the sub-admin of that team can manage that user. If a user is removed from a team and is no longer a member of any team, that account becomes deactivated, and default permissions are restored. Once the account is deactivated, a Super Admin/UMD IT Admin will need to change the role. This rule is in place to prevent possible malicious permission changes.
Sub-admins can create new teams, but new teams will have a default quota. The quota will need to be increased by the Super Admin/UMD IT Admin. This will prevent sub-admins from over-utilizing (or over-allocating resouUMD ITes) in the system without permission from UMD IT.