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.

The topics include:

• Section 2.1, "Overview"

• Section 2.2, "Understanding Oracle Privileged Account Manager Authentication"

• Section 2.3, "Understanding Oracle Privileged Account Manager Authorization"

• Section 2.4, "Securing Oracle Privileged Account Manager"

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 user interface to work alongside Oracle Single Sign-On (SSO).

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

  Note:

  Oracle Privileged Account Manager authentication relies on JAAS support in WebLogic. 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 check-out) 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

SAML-based token authentication is provided by using the OPSS trust service in WebLogic Server. The OPSS Policy Store stores all of the meta data required by the authorization decision engine.

The following figure illustrates Oracle Privileged Account Manager authentication.

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

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 and clients interact with Oracle Privileged Account Manager's web-based user interface and Oracle Identity Navigator

• Users and clients interact directly with the Oracle Privileged Account Manager server

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

• HTTP Basic-Authentication

• OPSS-Trust Service Assertions

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 ID Store.

2.2.1 Authentication for the Oracle Privileged Account Manager Graphical User Interface

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 Single Sign-On (SSO).

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, see the Oracle Fusion Middleware 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:

• Administration Role Types

• End Users

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, see "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 servers.
Security Administrator (OPAM_SECURITY_ADMIN)	Manage targets (add, edit, and remove targets). Manage accounts (add, edit, and remove accounts). Note: This role cannot assign grantees to privileged accounts. Manage Password and Usage Policies (create, edit, and delete policies). Assign Password and Usage Policies to accounts. Note: This role can only apply a Usage Policy at the account level.
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.

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, you can use the weblogic user, as the bootstrap user, to map the users from the domain identity store to the Oracle Privileged Account Manager Common Admin Roles detailed 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 defined in your domain identity store.

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 Section 5.2, "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:

• Securing the Network Channel

• Securing Shared Accounts

• Enabling Password Resets

• Avoiding Assignments through Multiple Paths

• Defining Richer Password Policies

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:

• Connecting to Target Systems

• Securing the End User Interface

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 always using 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 3.3.2, "Configuring SSL Communication in Oracle Privileged Account Manager." 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:

• Console (see Section 3.4, "Navigating Oracle Privileged Account Manager's Console" for more information)

• Command line tool (see Appendix A, "Working with the Command Line Tool" for more information)

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, see "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 that 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 5.1.1.4, "Modifying the Default Usage Policy" or Section 5.1.1.6, "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 Section 5.1.1, "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.

Note:

For more information about granting privileged accounts, see Section 5.1.4, "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 Section 5.1.1, "Working with Policies."