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 17.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

    • 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

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 when

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

  • 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 authentication modes, over SSL, out of the box:

  • 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 and Oracle Identity Navigator 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 the same authentication mechanisms as Oracle Identity Navigator and you can configure the interface with Oracle Access Management.

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

Note:

Oracle Privileged Account Manager administrators and users will probably never have to use the Oracle Identity Navigator interface except during the initial set-up of Oracle Privileged Account Manager.

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

  2. The Oracle Privileged Account Manager Console and Oracle Identity Navigator call 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 and Oracle Identity Navigator make RESTful calls to the Oracle Privileged Account Manager server to execute Oracle Privileged Account Manager functionality, the Oracle Privileged Account Manager Console and Oracle Identity Navigator present 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 and Oracle Identity Navigator, but the Oracle Privileged Account Manager Console and Oracle Identity Navigator 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, Oracle Identity Navigator, 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.

Note:

For more information about Common Admin Roles, including the responsibilities of each role and the skills and expertise required to perform that role, refer to "Common Admin Roles" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator.

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 Common Admin Roles can administer Oracle Privileged Account Manager.

Note:

Authorized administrators must configure and assign roles from the Administration tab in the Oracle Identity Navigator Console. Refer to "Configuring Enterprise Roles" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator for detailed information.

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

Application Configurator
(OPAM_APPLICATION_CONFIGURATOR)

  • Configure 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.

  • Manage properties on the Session Manager Configuration page.

Security Administrator
(OPAM_SECURITY_ADMIN)

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

  • 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 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.

  • View the Session Manager Configuration page.

Security Auditor
(OPAM_SECURITY_AUDITOR)

  • Open and review Oracle Privileged Account Manager reports.

  • View Oracle Privileged Account Manager Audit reports in the Oracle Identity Navigator Reports portlet.

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.

Note:

The following information about the weblogic user is specific to working in a WebLogic environment. If you are using 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.

After installation, the default administrator is the weblogic user (also known as the bootstrap user) who is a member of the Administrators group. You must use the weblogic user to create and assign users to the Oracle Privileged Account Manager Admin Roles described in Table 2-1. Those users can then perform the administration tasks described in this table.

Note:

Although it is possible for the default administrator to assign all those roles to himself or herself, this is not typical.

After installation, use the weblogic user as the bootstrap user who can map users from the domain identity store to the Oracle Privileged Account Manager Common Admin Roles described in Table 2-1. Users mapped to the Security Administrator role can assign the Common Admin Roles to other users, and can later replace the weblogic user in your environment. After you complete the initial user mapping, replace the default administrator user by mapping the Security Administrator role to at least one administrator user that is defined in your domain identity store. Refer to Section 3.3.3, "Preparing the Identity Store" for more information.

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 12, "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.

The topics include:

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, there are two 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 15.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

There are two primary interfaces open to an Oracle Privileged Account Manager end user:

Oracle Privileged Account Manager's Console is hosted in Oracle Identity Navigator. However, Oracle Identity Navigator is also used for other purposes, so it can be deployed with SSL enabled or disabled.

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

Oracle recommends that if you use Oracle Identity Navigator to serve the Oracle Privileged Account Manager Console, you must deploy Oracle Identity Navigator in an SSL (and only SSL) -enabled mode.

Note:

For more information about configuring SSL for Oracle Identity Navigator, refer to "Configuring Secure Socket Layer" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator.

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.

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 displays 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 9.3.3, "Modifying the Default Usage Policy" or Section 9.3.4, "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 9, "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 C.3.10, "Oracle Privileged Account Manager End Users Gain Privileges They Were Not Explicitly Granted" for more for more information.

Note:

For more information about configuring and working with grantees, refer to Chapter 10, "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 9, "Working with Policies."

2.4.6 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. 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, visit these 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 9.3.4, "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 11.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 16.3, "Understanding the Plug-In API."