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.
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 repsonsible 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.
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 subadmin permissions. Admins cannot modify super-admin permissions nor can they do the tasks specific for super-admins stated above.
Subadmins within the system are the lowest level of adminstrators. A subadmin 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 subadmin.
The subadmin has access to the Management tab within the tiCrypt system, just like the admins above, but subadmins would only list members, VMs, projects, etc., associated with the admin’s assigned team. This allows for a subadmin to activate team members, change team members' permissions, manage tiCrypt projects, or any other admin action for that specific team only.
Three guiding principles that act as rules for a subadmin.
If a user is deactivated and belongs to no team, a subadmin can place this new user into their team. This allows for subadmins to onboard and activate users without the need for a Super Admin/UMD IT Admin. This rule prevents the subadmin 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 subadmin 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.
Subadmins 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 subadmins from over-utilizing (or over-allocating resouUMD ITes) in the system without permission from UMD IT.