Oracle Enterprise Manager (OEM) provides robust capabilities for managing your Infrastructure environments, including user access, roles, and target credentials. While creating users and roles is pretty straightforward, managing privileges across the targets is cumbersome. Let’s explore how we can leverage Secure Credentials and Private roles to manage access.
Users & Credentials
It is important to spend the time to understand the requirements and plan appropriately. In this example, let’s try to design a setup to allow developers to analyze performance on he development databases. Firstly we will create an account on the databases we want to monitor and grant the appropriate privileges. E.g. to generate AWR, the user must have the execute privileges on the dbms_Workload_repository. Similarly, to create SQL tuning set, the user must have the OEM advisor role
create user oem_dev_user identified by dev_password ;
grant connect to oem_dev_user;
grant select_catalog_role to oem_dev_user;
grant execute on DBMS_WORKLOAD_REPOSITORY to oem_dev_user;
grant oem_advisor to oem_dev_user;Once we create the database account, we will proceed to create a Global credential. However, if you prefer different passwords for all targets then, create separate credentials and limit the scope to a particular target.
Unfortunately, when the scope is restricted to “Target,” we are unable to choose multiple targets simultaneously. To create the credential navigate to Security -> Named Credentials -> Create Credential and provide the required details to create the credential.
Roles & Credentials
The next building block of this setup is the role. To create the Role navigate to Security -> Role -> Create Role. You can manage the five sections on the role creation page as follows:
- General: Provide the Name & Description of the Role, the important thing to note over here is that the role should be marked as private. This is required to access Named Credentials
- Roles: Here we provide the Generic EM_ALL_VIEWER Role
- Target Privileges: This is the most important section, where you can control the targets to which the role applies, as well as the privileges on the particular targets.
- Groups/Targets – You can leverage groups instead of choosing individual database targets. This increases the manageability of the setup. Developers receive necessary privileges when a new database is added to the OEM DEV group.
- Privileges – The other thing to choose is the privileges of the target. For example, we have chosen the “Database Application Developer” Privilege which grants the abilities shown below.
- Resource Instance Privileges: This is where you can select the credential you created. The very important thing to note here is that the VIEW_CREDENTIAL privilege does NOT allow the user to view the database password. Hence the database password is not available to the users for access from outside the OEM. In this we we can securely restrict access to the required functionalities. You can also grant
- Administrators: Grant the role to the administrators.
Hence, a role can be granted to Developers, to help them analyze performance without compromising database passwords. When a developer attempts to connect to a development database they can use the Named credentials without having access to the password as shown below.
Similarly, roles can see setup granting users privileges to run reports or other functionality. By implementing Secure Credentials and Private roles, we can effectively control user access and protect sensitive information, such as database passwords.