Managing authorizations

To manage authorizations, you must use the functionality of the RBAC Manager folder as well as the ability to set permissions for any system object throughout BMC Server Automation. When setting up and using authorizations, BMC recommends the work flow described in the following section.

To manage authorizations

1. Set up authorizations.
   Authorizations are permissions to perform specific types of actions in BMC Server Automation. The following types of authorizations exist. For more information about these types of authorizations, see Setting-up-authorizations.
   • System — Grants permission to perform a certain class of action, such as creating a particular type of job or creating components.
   • Command — Grants permissions to perform Network Shell and nexec commands.
2. Create authorization profiles.
   An authorization profile is a group of system and command authorizations. After you create authorization profiles, use them to assign complex sets of system and command authorizations to roles, objects, and access control list (ACL) templates. For more information, see Creating-an-authorization-profile.
3. Create ACL templates.
   An ACL template is a collection of authorizations granted to one or more roles but not associated with a specific object. After you create ACL templates, use them to repeatedly assign complex sets of authorizations to system objects throughout BMC Server Automation. For example, you can define an ACL template that grants an architect role the right to create jobs, an administrator role the right to run jobs, and everyone else the right to view jobs. An ACL template can consist of individual system and command authorizations, authorization profiles, and ACL policies.
   When you define a role, you can specify an ACL template that functions as the object permissions template. This ACL template defines a set of authorizations that are automatically assigned to any object created by this role.
   ACL templates are also useful when transferring responsibility for an object between functional areas of an organization, such as when a development team completes work on a job or BLPackage and promotes it to QA. In a situation like this, permissions for the object must be redefined. An ACL template can encapsulate all the necessary changes, with the new permissions replacing the object's existing permissions.
   For more information, see Creating-an-ACL-template.
4. Create ACL policies
   Like an ACL template, an ACL policy is a collection of authorizations granted to one or more roles but not associated with any specific object. Unlike ACL templates, however, the changes made to an ACL policy automatically take effect for any object where the ACL policy has been applied. This allows you to centrally manage ACLs for multiple objects, which is useful for organizations that employ many server objects with complex sets of permissions.
   Like ACL templates, ACL policies can be used to transfer responsibility for an object between functional areas of an organization. An ACL template can encapsulate all necessary permissions for an object. When you apply the new ACL policy, the new permissions can replace the object's existing permissions.
   For more information, see Creating-an-ACL-policy.
5. Create automation principals.
   An automation principal defines a user credential that can be used for accessing external systems. The most typical use for automation principals is Windows user mapping, a process that maps an RBAC role to a local or domain user on a managed server. Automation principals can also be used for accessing Active Directory servers, configuring BMC Atrium Orchestrator, and other purposes.
   For more information about using automation principals for managing Windows and UNIX servers, see Automation principals and server management
6. Create LDAP connections and queries.
   To synchronize the users in the RBAC user database with an LDAP user registry such as Active Directory, you must set up connections and queries that are used for obtaining information from the LDAP server.
   For more information, see Creating an LDAP connection and Creating an LDAP query.
7. Create roles.
   A role defines a set of permissions that reflect the responsibilities of an organizational entity, such as QA engineers, application developers, or web administrators.
   To define these permissions you assign system authorizations, command authorizations, and authorization profiles to the role. In addition, a role provides information that determines how a user establishes a connection to an RSCD agent on a remote server. A role definition lists the users assigned to the role. A role definition can also specify an ACL template that functions as the object permissions template. If you plan to synchronize an LDAP user registry with RBAC, you can associate a role with LDAP connections and queries. For more information, see Creating-roles.
8. Create users.
   Creating a user in the RBAC Manager folder sets up a user account so an individual can access the BMC Server Automation Console. When you add a user, you provide the user with a password and you specify the roles that the user is assigned to. You can also optionally provide some SRP security settings. For more information, see Creating-users.
   BMC Server Automation also provides a set of BLCLI commands that can synchronize your RBAC user database with Active Directory. For more information, see Synchronizing-users-with-LDAP-servers.
9. Assign object-based permissions.
   For each system object in BMC Server Automation, you must define a set of permissions specifying which roles have access to the object. Object-based authorizations let you make fine-grained decisions about access to individual system objects, including the sharing of objects. For more information, see Object-based-permissions.
10. Update permissions for multiple objects.
    After you establish permissions for objects in your system, changes are inevitably necessary. For example, if you add a role, you must modify the permissions for some or all of the objects in your system to accommodate the new role. To accomplish this, you can group objects in a folder, define new permissions, and then apply those permissions to all of the objects in the group. For more information, see Updating-permissions-for-one-or-more-system-objects.