2 Understanding Oracle Privileged Account Manager Security

This chapter describes how Oracle Privileged Account Manager authenticates and authorizes different types of users by using the authentication and authorization framework provided in the Oracle Privileged Account Manager server. In addition, this chapter explains various methods that you can use to further secure Oracle Privileged Account Manager in your deployment environment.

This chapter includes the following sections:

2.1 Overview

The authentication and authorization framework provided in the Oracle Privileged Account Manager server provides the following features and functionality:

  • Supports OPSS-Trust tokens and HTTP-Basic Authentication.

    You can also configure the Oracle Privileged Account Manager Console to work alongside Oracle Access Management. Refer to Section 19.2, "Integrating with Oracle Access Management Access Manager" for more information.

  • Leverages the Java Authentication & Authorization Service (JAAS) for authentication.

    Note:

    Oracle Privileged Account Manager authentication relies on JAAS support in the J2EE container on which its deployed. Refer to "WebLogic Security Service Architecture" in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server for more information.

  • Defines different Oracle Privileged Account Manager-specific Admin Roles and their Oracle Privileged Account Manager-specific responsibilities.

  • Enforces authorization decisions that determine the following conditions:

    • Which targets and privileged accounts are exposed to an administrator or to an end-user.

    • Which operations (such as add, modify, check-in, and checkout) an end-user or an administrator can perform on targets, privileged accounts, and policies.

  • Supports Usage Policies and Password Policies for privileged accounts

2.2 Understanding Oracle Privileged Account Manager Authentication

This section also discusses the following topics:

Oracle Privileged Account Manager uses Security Assertions Markup Language-based (SAML-based) tokens as its authentication mechanism. SAML-based token authentication is provided by using the OPSS Trust Service in the J2EE container on which its deployed.

The following figure illustrates Oracle Privileged Account Manager authentication.

Figure 2-1 Trust-Based Authentication in Oracle Privileged Account Manager

Figure illustrating trust-based authentication in OPAM

Trust Service instances are typically configured to securely propagate user identities from the client application to the Oracle Privileged Account Manager server as part of the Oracle Privileged Account Manager installation and configuration process.

Oracle Privileged Account Manager requires authentication under the following conditions:

  • When users interact with Oracle Privileged Account Manager's web-based user interface (the Console) and the command line tool (CLI).

  • When users and clients interact directly with the Oracle Privileged Account Manager server through its RESTful interfaces.

In both cases, Oracle Privileged Account Manager supports the following predefined authentication modes, over SSL:

  • HTTP Basic-Authentication: The user sends the user name and password as unencrypted base64 encoded text.

  • OPSS-Trust Service Assertions: The OPSS Trust Service allows the propagation of identities across HTTP-enabled applications by providing and validating tokens. This service uses an asserter that is available through Oracle WebLogic Server.

In addition, Oracle Privileged Account Manager can support ADF-based authentication for UI-based interactions, which is done transparently against the domain-specific identity store.

2.2.1 Authentication for the Oracle Privileged Account Manager Console

The Oracle Privileged Account Manager web-based user interface, or Console, supports ADF-based authentication mechanisms and you can configure the interface with Oracle Access Management.

When a user interacts with the Oracle Privileged Account Manager Console, the following occurs:

  1. The user authenticates against the Oracle Privileged Account Manager Console by using ADF authentication.

  2. The Oracle Privileged Account Manager Console calls the OPSS-Trust Service to request a token that asserts the identity of the user logged into the Oracle Privileged Account Manager Console.

  3. Now, whenever the Oracle Privileged Account Manager Console makes RESTful calls to the Oracle Privileged Account Manager server to execute Oracle Privileged Account Manager functionality, the Oracle Privileged Account Manager Console presents the generated token to the Oracle Privileged Account Manager server.

  4. Because the OPSS Trust Service Asserter is configured by default, the Asserter examines the token presented in the previous step, validates the token, and then asserts that the identity performing the RESTful call against the Oracle Privileged Account Manager server is the one contained in the token.

    This process is called identity propagation. An end-user only authenticates against the Oracle Privileged Account Manager Console, but the Console can securely convey to the Oracle Privileged Account Manager server the identity for which they are making a request.

    The important point to note about identity propagation is that it removes the need for end users to authenticate themselves against the Oracle Privileged Account Manager Console and the Oracle Privileged Account Manager server.

    Note:

    If you deploy your own client applications against the Oracle Privileged Account Manager server, then you must have identity propagation. In such a context, it is recommended that you use OPSS-Trust Service based Identity Assertions. For more information, refer to the Oracle Fusion Middleware Application Security Guide.

2.2.2 Authentication for the Oracle Privileged Account Manager Server

The Oracle Privileged Account Manager server only exposes RESTful interfaces and supports HTTP-Basic Authorization or OPSS-Trust. In addition, the Oracle Privileged Account Manager server requires that all communication with that server occurs over an SSL-secured channel.

The Oracle Privileged Account Manager command line tool client uses HTTP Basic-Authentication over SSL to connect to, and authenticate against, the Oracle Privileged Account Manager server.

2.3 Understanding Oracle Privileged Account Manager Authorization

This section describes Oracle Privileged Account Manager authorization.

The topics include:

Note:

If you are using Oracle Privileged Account Manager on IBM WebSphere, refer to "Differences in Oracle Privileged Account Manager Authorization" in the Oracle Fusion Middleware Third-Party Application Server Guide for Oracle Identity and Access Management for information about this topic.

2.3.1 Administration Role Types

Common Admin Roles are a set of predefined, standardized application roles for securing administrative access to Oracle Identity Management applications. These roles encapsulate the common administrative tasks across the Oracle Identity Management suite.

Oracle Privileged Account Manager uses Admin Roles to manage access to targets and privileged accounts and to control which operations administrators can perform. Specifically, the Oracle Privileged Account Manager server renders different user interface components based on the Admin Role assigned to the user logging in.

Only administrators who are assigned the Oracle Privileged Account Manager-specific Admin Roles can administer Oracle Privileged Account Manager.

Enterprise roles must be created in the domain identity store to support the Oracle Privileged Account Manager Admin Roles.

The following are the prerequisites to configuring enterprise roles for the Common Admin Roles:

For more information about supported identity and policy store configurations for Oracle Privileged Account Manager, refer to Section 3.1, "Before You Begin."

The following table describes the Common Admin Roles that are specific to Oracle Privileged Account Manager.

Table 2-1 Supported Admin Roles

Admin Role Access Rights Responsibility Skills and Expertise Required

Application Configurator
(OPAM_APPLICATION_CONFIGURATOR)

  • Configure and manage Oracle Privileged Account Manager Console and servers.

  • Manage plug-in configurations (create plug-in configurations, modify configuration attributes the plug-in needs to work, and delete the configurations).

    Note: When a new plug-in configuration is created, the status is disabled and the plug-in cannot be executed. This role cannot enable a plug-in configuration. Only the Security Administrator (OPAM_SECURITY_ADMIN) role can enable plug-in configurations and determine under which conditions those plug-ins can be executed.

Use Identity Management applications to support business requirements within an assigned business scope.

  • Strong knowledge of product features.

  • Good knowledge of business requirements.

Security Administrator
(OPAM_SECURITY_ADMIN)

  • Manage accounts (add, edit, and remove accounts) and view the Password History for an account.

    Note: This role cannot assign grantees to privileged accounts.

  • Manage targets (add, edit, and remove targets) and view the Password History for a target.

  • Manage resource groups (create, edit, and remove resource groups and users or groups with delegated access privileges).

  • Manage Password and Usage Policies (create, edit, and delete policies).

  • Assign Password Policies to accounts.

    Note: This role cannot assign Usage Policies because they are always associated with a grant. Only the User Manager (OPAM_USER_MANAGER) role can assign grants and Usage Policies.

  • Edit plug-in configurations, enable or disable plug-ins, and configure Filter Rules (such as enabling users or groups) to decide under which conditions a plug-in can be executed.

    Note: This role cannot create or delete a plug-in configuration. Only the Application Configurator (OPAM_APPLICATION_CONFIGURATOR) role can create or delete a plug-in configuration.

  • Search for and edit Plug-In Configurations and Connector Server Configurations.

  • View properties on the Server Configuration and Session Manager Configuration pages.

  • Configure Identity Management application roles and approve role grants.

  • Configure Identity Management applications to work with corporate infrastructure and applications.

  • Maintain system credentials for identity stores, key stores, databases, and other repositories.

  • Grant administrative roles and permissions.

  • Strong knowledge of corporate infrastructure and Identity Management security architecture.

  • Strong technical knowledge to troubleshooting infrastructure access rights.

Security Auditor
(OPAM_SECURITY_AUDITOR)

Open and review Oracle Privileged Account Manager reports.

  • Provide audit reports to upper management.

  • Verify permissions and generate access reports.

  • Verify proper configuration of Identity Management applications.

  • Strong knowledge of access management processes.

  • Strong knowledge of the risks associated with unauthorized access.

  • Good understanding of information security and system architecture.

User Manager
(OPAM_USER_MANAGER)

  • Assign end users with grants to privileged accounts.

  • Manage Usage Policies (create, edit, and delete Usage Policies).

  • Assign Usage Policies to grants.

    Note: The relationship between an account and a grantee (end user) of that account is called a grant. The User Manager can assign different Usage Policies to different grantees of the same account.

    This role cannot assign Password Policies to accounts.

  • View the Plug-In Configuration page and search for plug-ins.

  • Terminate all Oracle Privileged Session Manager sessions for a selected account.

  • Create, modify, and delete users and groups.

  • Reset passwords and unlock accounts.

Strong knowledge of corporate identity infrastructure.

2.3.2 End Users

Oracle Privileged Account Manager End Users or Enterprise Users are not assigned any roles, so they have limited access to Oracle Privileged Account Manager user interface components. These users are only entitled to perform certain tasks; which includes viewing, searching, checking out, and checking in privileged accounts for which they have been granted access.

Note:

Refer to Chapter 14, "Working with Self-Service" for more information.

2.4 Securing Oracle Privileged Account Manager

You can implement the recommendations described in this section to further secure Oracle Privileged Account Manager in your deployment environment.

This section includes the following topics:

2.4.1 Securing the Network Channel

As part of its normal functionality, Oracle Privileged Account Manager performs remote password resets on target systems. Because these passwords allow access to those systems as privileged identities (Oracle Privileged Account Manager manages privileged accounts and identities) you must ensure that these remote password resets occur over a secured network channel.

After being reset, Oracle Privileged Account Manager propagates these passwords to end users who are requesting access to the target system as a privileged account. Again, you must ensure that these newly reset passwords are propagated to the end users over a secured channel.

Considering these points, the two following aspects of an Oracle Privileged Account Manager deployment that must be closely examined and secured:

2.4.1.1 Connecting to Target Systems

Oracle Privileged Account Manager leverages ICF connectors to communicate with target systems. These connectors are highly flexible and they can be configured in several ways. To allow flexibility in testing (and even production), Oracle Privileged Account Manager does not mandate that this connectivity always occurs over a secure channel.

Except for the Generic UNIX targets, which mandates SSH, the Generic LDAP and Generic DB targets allow connections through both secured (encrypted) and clear channels. Therefore, it is important for an Oracle Privileged Account Manager administrator to consider all relevant factors when deciding what type of channel to use when connecting to target systems.

Oracle recommends that you always use secured channels to mitigate the risk of password compromise due to packet sniffing. If the target system (either LDAP or DB) supports SSL and is listening on an SSL port, then Oracle Privileged Account Manager can communicate with that target over SSL.

Consult your target systems' product documentation for information about configuring your targets so that they are listening on an SSL port. To configure Oracle Privileged Account Manager to communicate through SSL, refer to Section 17.1, "Configuring Oracle Privileged Account Manager to Communicate With Target Systems Over SSL." Securing these connections through SSL ensures that the password reset operations performed by Oracle Privileged Account Manager occur in a secure manner.

2.4.1.2 Securing the End User Interface

The following are the two primary interfaces open to an Oracle Privileged Account Manager end user:

Oracle Privileged Account Manager's Console can be deployed with SSL enabled or disabled.

If you deploy the Oracle Privileged Account Manager Console with SSL disabled, even if the Console communicates with the Oracle Privileged Account Manager server over an SSL secured channel, then the connectivity between the Console and the end user browser is not secured, which can cause security concerns.

Oracle recommends using the Oracle Privileged Account Manager Console SSL-enabled mode because it is more secure.

Because the Oracle Privileged Account Manager server mandates SSL connectivity, the Oracle Privileged Account Manager command line tool always uses SSL and communicates over a secure channel. Consequently, when the Oracle Privileged Account Manager server propagates a password to an end user through the command line tool, it always uses a secured channel and prevents compromises from packet sniffing.

2.4.2 Securing Shared Accounts

Oracle Privileged Account Manager enables you to specify whether a privileged account is shared or not shared. This section defines shared accounts, explains some security considerations, and describes how to improve security for a shared account.

This section also discusses the following topics:

2.4.2.1 What is a Shared Account?

By default, Oracle Privileged Account Manager allows only one user to check out an account at a time. If a second user tries to check out an already checked-out account, an error message is displayed stating the account is already checked out.

Oracle Privileged Account Manager also enables you to configure a shared account, which enables multiple users to check out the account at the same time.

When multiple users check out a shared account, Oracle Privileged Account Manager shares the password generated by the first user instead of generating a new password for each user. Setting a new password would affect the existing check out. Oracle Privileged Account Manager does not reset that password until all users have checked in the account and the last person has checked in the password.

Oracle recommends that you designate an account as shared only if there are compelling business reasons to do so. For example, sharing a database account might be advantageous if that account is being administered by multiple people.

2.4.2.2 Security Limitations

When you configure a shared account, keep in mind the following security limitations:

  • Users can still use the password after checking in an account because Oracle Privileged Account Manager does not reset the password until the last user checks it in.

  • Sharing accounts presents a problem with achieving a fine-grained audit. Oracle Privileged Account Manager can provide an audit trail that shows when the account was checked out and which users had access to that account at any given time. However, if multiple end users have the same privileged account checked out at the same time, then Oracle Privileged Account Manager cannot isolate the actions taken by an individual end user.

2.4.2.3 How to Secure the Account

If you do have a compelling reason for sharing an account, its useful to take the following steps to secure that account:

  1. Configure the Usage Policy to automatically check in the privileged account after a specified period of time. Automatic check-ins ensure that shared privileged accounts get checked in and that passwords get cycled in a timely manner.

  2. Limit the number of users to whom you assign the privileged account and try to further segregate these users by specifying when they can access the account. You can configure the Usage Policy to specify which days of the week and what times of the day a user can access an account. These limitations can minimize overlapping checkouts, which improves Oracle Privileged Account Manager's ability to audit.

Note:

For more information about configuring a Usage Policy, refer to Section 10.3.4, "Modifying the Default Usage Policy" or Section 10.3.5, "Creating a Usage Policy."

2.4.3 Enabling Password Resets

Oracle Privileged Account Manager allows you to configure the Password Policy for a privileged account so that Oracle Privileged Account Manager automatically resets the privileged account's password when the account is checked-out, checked-in, in both cases, or in neither case.

At a minimum, Oracle recommends that you configure and apply a Password Policy to reset the privileged account's password on check in. Resetting the password on check in prevents end users from using that account after checking it in because the password they used is no longer associated with that privileged account. This feature is one of the fundamental innovations in Oracle Privileged Account Manager and should be used.

Note:

For more information about configuring and working with Password Policies, refer to Chapter 10, "Working with Policies."

2.4.4 Avoiding Assignments through Multiple Paths

In addition to directly assigning privileged accounts to end users, Oracle Privileged Account Manager allows you to assign privileged accounts to groups. For example, you might want to create a "Data Center Product UNIX Administrators" group and give that group access to certain privileged accounts.

When designing your deployment, it is important to ensure that a given end user is granted access to a privileged account through only one path (either directly or through a single group). When Oracle Privileged Account Manager discovers multiple grant paths, it picks the first path retrieved from its back-end, which leads to non-deterministic behavior. This behavior can cause the effective Usage Policy to be different from the intended Usage Policy.

On a related note, you must avoid creating groups with multiple naming attribute values or you might enable users to access groups for which they were not explicitly granted access. Refer to Section 20.3.10, "Oracle Privileged Account Manager End Users Gain Privileges They Were Not Explicitly Granted" for more information.

Note:

For more information about configuring and working with grantees, refer to Chapter 11, "Working with Grantees."

2.4.5 Defining Richer Password Policies

The primary purpose of an Oracle Privileged Account Manager's Password Policy is to ensure the success of an Oracle Privileged Account Manager-initiated password reset that occurs against a target system.

At a minimum, Oracle Privileged Account Manager requires the effective Password Policy on a privileged account to describe the Password Policy being enforced on the target system. However, Oracle Privileged Account Manager administrators are not restricted to this requirement. You can define a much richer Password Policy in Oracle Privileged Account Manager that generates more complex and secure passwords during Oracle Privileged Account Manager reset operations.

Note:

For more information about configuring and working with Password Policies, refer to Chapter 10, "Working with Policies."

2.4.6 Delegating Administration

Administrative privileges on some resources may need to be assigned or delegated to a particular user or role. In such cases, after the delegation of privileges from the administrator, the delegatee has delegated administration privileges on the assigned resource. However, the delegatee does not have any privileges on any of the other resources within the system. This is delegated administration.

For example, the security administrator may want to assign another user to administer a particular LDAP server. In this situation, the assigned user is not in the OPAM_SECURITY_ADMIN group of Oracle Privileged Account Manager, and so he does not have security administration privileges on all the other resources. However, he now have all the security administration privileges. In such a case, the security administration privileges for the LDAP resource are delegated to him. This is the delegation of the security administration privileges. Similarly, "User Management" Privileges can also be delegated.

2.4.7 Hardening the Back-End Oracle Privileged Account Manager Database

Beginning with the 11gR2 11.1.2.1.0 release, Oracle Privileged Account Manager moved to using the Oracle RDBMS as its data store. As such, it is important to ensure that the back-end Oracle Privileged Account Manager database is locked down for production deployments.

Oracle recommends that administrators perform the following three tasks to effectively lock down a back-end Oracle Privileged Account Manager database:

Enable TDE

Oracle recommends enabling Transparent Data Encryption (TDE) mode on your back-end Oracle Privileged Account Manager database for all production deployments of Oracle Privileged Account Manager. Enabling TDE ensures that all sensitive information stored by Oracle Privileged Account Manager (such as account passwords) is encrypted on disk.

For security purposes, enabling TDE for Oracle Privileged Account Manager is a two-step process. You must

  1. Enable TDE in the back-end database

    Refer to "Enabling TDE in the Database" in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

  2. Use any of the two following methods to configure Oracle Privileged Account Manager to expect a back-end database that is configured to use TDE:

Note:

for more information about using Transparent Data Encryption, refer to the following websites:

Enable SSL

In addition to the on-disk encryption provided by TDE, Oracle Privileged Account Manager obfuscates all sensitive information that it stores. This obfuscation ensures that anyone gaining access to the Oracle Privileged Account Manager schema still does not have direct access to sensitive information. Furthermore, the obfuscation prevents any malicious elements monitoring network traffic from easily viewing sensitive information. However, Oracle recommends that you perform both of the following actions for production deployments of Oracle Privileged Account Manager:

  • Enable SSL on the back-end RDBMS used by Oracle Privileged Account Manager.

  • Update the OPAMDS data source to use the SSL endpoints on your back-end RDBMS.

Note:

Refer to "Enabling SSL in Other Authentication Modes" and to "SSL-Enable a Data Source" in the Oracle Fusion Middleware Administrator's Guide for instructions.

These actions encrypt network traffic between Oracle Privileged Account Manager and the back-end Oracle Privileged Account Manager database. They also ensure that the database is not vulnerable to exploitation by malicious elements.

Use Oracle Database Vault

Using Oracle Database Vault for production deployments of Oracle Privileged Account Manager secures the Oracle Privileged Account Manager schema and ensures that only the Oracle Privileged Account Manager application has access to the schema.

Note:

Refer to "Configuring Secure Application Roles for Oracle Database Vault" in the Oracle Database Vault Administrator's Guide for instructions.

Thus, you prevent inadvertent or malicious access to the Oracle Privileged Account Manager application schema (and associated data) by database administrators and other implicitly authorized users. You also ensure that only the Oracle Privileged Account Manager application can access the sensitive information it maintains in the back-end Oracle Privileged Account Manager database.

2.5 Understanding Session Management Security

Currently, Oracle Privileged Account Manager only provides Session Management on SSH-enabled targets. Accessing a target through the Oracle Privileged Session Manager (Session Manager) prevents the end-user from being exposed to the password associated with the privileged account in use. Therefore, for all use-cases where the end-user does not require knowledge of the password associated with a privileged account, granting access to just the session, as opposed to the password or both the session and password, is recommended. Refer to step 3 in Section 10.3.5, "Creating a Usage Policy."

SSH Session Management support requires that the Session Manager perform the tasks associated with an SSH server. For server authentication and data privacy (such as encryption), Oracle Privileged Account Manager generates a new DSA 1024 bit (such as FIPS 186-2 compliant) SSH server key for every Oracle Privileged Account Manager instance. This server key is configurable and it can be changed by using Session Manager Configuration for key rollover.

2.6 Understanding Plug-In Security

The Oracle Privileged Account Manager plug-in framework provides for significant extensibility and customizability. However, this framework also allows custom code to interface closely with Oracle Privileged Account Manager functionality. Therefore, protecting Oracle Privileged Account Manager against malicious custom code is very important.

Because custom plug-in code can interface closely with internal Oracle Privileged Account Manager functionality, it is important that you closely scrutinize all custom plug-in code that is deployed on Oracle Privileged Account Manager. To prevent a single malicious entity from deploying malicious custom code, Oracle Privileged Account Manager enforces a requirement that two different Oracle Privileged Account Manager administrators (with different roles) are involved during the process of deploying custom plug-in code.

First, an administrator with the OPAM_APPLICATION_CONFIGURATOR Admin Role can add a new custom plug-in and configure it. However, the action of enabling the plug-in and determining the conditions under which it can run must be done by a second administrator with the OPAM_SECURITY_ADMIN Admin Role. For more information, refer to Section 13.3, "Creating a Plug-In Configuration." This design ensures that a single malicious entity cannot deploy a malicious plug-in by himself or herself.

Furthermore, because the custom plug-in code runs within the context of the Oracle Privileged Account Manager server, internal Oracle Privileged Account Manager APIs could potentially be accessible to the custom plug-in code. To pro-actively prevent this access, the Oracle Privileged Account Manager plug-in framework uses a custom class loader that explicitly prevents access to all internal Oracle Privileged Account Manager server APIs. Therefore, the custom plug-in code must interface with internal Oracle Privileged Account Manager logic through the well-defined APIs described in Section 18.3, "Understanding the Plug-In API."