Authorization overview
In BMC Server Automation, access control is managed through role-based and object-based authorizations.
The definition of a role includes a set of authorizations and other information that reflects the capabilities of an organizational entity, such as QA engineers or web administrators. When a user is assigned to a role, he or she is granted the authorizations defined for that role.
The definition of a system object includes a set of authorizations specifying roles who can access the object and the actions those roles can perform. You can set authorizations for all system objects in BMC Server Automation, including objects that function as resources, such as servers and components. Performing any action in BMC Server Automation typically requires three levels of authorization:
The combination of role-based and object-based authorizations determines a user's effective authorizations — that is, the actions a role can perform on a system object. For more information about effective authorizations, see #Effective authorizations.
Role-based authorizations
Authorizations are granted to roles so they can perform certain types of actions.
To grant authorizations, you define an access control list for each role. Entries in that list specify a class of actions, such as Server.Read, which lets a role read servers, or DeployJob.Execute, which lets a role execute Deploy Jobs. Authorizations that are granted to a role should mirror the responsibilities of an organizational entity. For example, a JuniorAdmin role might be granted limited authorization to perform actions such as reading servers, components, and jobs. A SeniorAdmin role might be authorized to perform all types of actions on servers, components, and jobs.
To perform an action such as running a Deploy Job on a server, a role must be authorized to perform that class of action, such as DeployJob.Execute. However, to actually run a Deploy Job, the next level of authorizations — object-based permissions — must also be granted.
Object-based authorizations
When you create any system object in BMC Server Automation, you must define an access control list for that object. Each entry in the access control list grants permission to a role to perform a certain type of action on that system object. For example, if you are creating a Deploy Job, you might grant a role Read and Execute authorizations for that job.
To perform some actions in BMC Server Automation, role-based authorization and object-based authorization are sufficient. However, if you are taking action on any server object that functions as a resource, such as a server, device, or component, you must also be authorized for that particular resource.
Resource-based authorizations
Authorizations at the resource level are granted in the same manner as object-based authorizations.
Resources are system objects. For each resource, you must define an access control list. However, the permissions you can set on resources are different than permissions on other system objects. For a server, device, or component, you can grant special-purpose permissions such as Browse, Snapshot, and Audit.
To perform actions on resources, you typically need three levels of authorization:
- Role level
- Object level
- Target level
For example, to run a Deploy Job on a server:
- Your role must be granted the authorizations DeployJob.Read and DeployJob.Execute.
- At the object level, your role must be granted DeployJob.Read and DeployJob.Execute authorizations for the Deploy Job you want to run.
- On the server that is the target of the Deploy Job, you role must be granted Server.Read and Server.Modify.
Any time you run a job that modifies a target server, your role must be granted Server.Read and Server.Modify on that server.
Effective authorizations
The combination of role-based and object-based authorizations (including resource-based authorizations) determines a user's effective permissions to perform actions on any system object.
For example, consider a JuniorAdmin role, which is granted a full set of authorizations on servers (that is, Server.*) at the role level. For a particular server, however, the JuniorAdmin role is only granted Server.Browse and Server.Read permissions. Those authorizations are object-based authorizations. A role can only perform an action that is authorized at both the role level and the object level. Because the JuniorAdmin role is limited to Server.Browse and Server.Read for the server in question, the JuniorAdmin role can only read and browse that server. Those are the role's effective permissions.