Understanding Commander Access Control
Commander provides role-based access control, which allows you to ensure that:
- administrators have the right level of access to the various parts of your virtual infrastructure
- data for the various groups of users that consume your IT services is appropriately segregated
Commander has both an administrative console and a Service Portal, with roles governing where users are permitted to sign in. You can assign both a Commander role and a Service Portal role to the same user. This is useful for administrators who want to sign in to the Service Portal to verify the effects of configuration changes.
This topic provides an overview of Commander access control and how to control administrative user access. Then we'll look at how to control Service Portal user access.
There are three things to set up for each administrative user:
- A user account
— A local user (created in Commander) or a directory service user or group. Commander integrates with both LDAP and Active Directory.
Note: Passwords for local accounts are stored in the Commander in encrypted format, using 256 bit AES encryption.
- A Commander role — A role is a set of permissions determining what tasks a user can carry out. Commander roles control what users can do in the Commander console. (Service Portal roles control what users can do in the Service Portal; we'll look at these later.)
- Access rights — Access rights determine what parts of your virtual infrastructure each Commander role may access. If an administrative user needs access to your virtual infrastructure, you must assign access rights. Access rights can't be assigned to users with Service Portal roles.
Note: The superuser administrative user account exists when you first install Commander. This user account can't be deleted. The superuser account is a local user account that allows the user access to the Commander console with the Commander role of Superuser. It has the highest level of access rights (Administrator) on all cloud accounts in your virtualized infrastructure
There are four things that you can set up for users in the Service Portal:
- Organizations — We recommend that you use organizations as the basis of Service Portal user access control. Organizations support multi-tenant environments by allowing customized configuration and data segregation for your groups of Service Portal users.
Tip: Using organizations is the easiest way to provide your Service Portal users with Service Portal access, because you can add users and groups and assign them a role when you create the organization.
- Parent organizations — When you have many organizations, it can be helpful to set up your multi-tenant environment with a hierarchy that uses parent organizations at the top level and then regular organizations grouped as children under those parent organizations.
- Single user account — This can be a local user, a directory service user, or a directory service group. (Commander supports both LDAP and Active Directory).
- Service Portal role — Service Portal roles allow access to the Service Portal.
Two Service Portal user accounts exist when you first install Commander: user and manager. These are local user accounts that have the Service Portal role of Delegated Admin and Manager, respectively, allowing access to the Service Portal only. They don't have access to your virtual infrastructure because users with Service Portal roles can't be assigned access rights.
Now that you understand the basics of Commander access control, you should do the following:
- Learn about Commander roles. Then add administrative users and assign them a Commander role. For those administrative users who need it, assign access rights.
- Learn about Service Portal roles. If necessary, customize those role or even create new roles.
- Set up organizations for your Service Portal user groups (when you set up organizations, you add users and assign organizational roles). This is the recommended usage for configuring Service Portal users. If you also want to use parent organizations, see Using Parent Organizations.