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:
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
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.
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
The following figure illustrates Oracle Privileged Account Manager authentication.
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 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.
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).
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.
The user authenticates against the Oracle Privileged Account Manager Console and Oracle Identity Navigator by using ADF authentication.
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.
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.
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.
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.
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 topics include:
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.
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.
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.
|Admin Role||Access Rights|
Configure Oracle Privileged Account Manager servers.
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.
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.
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.
Refer to Section 5.2, "Working with Self-Service" for more information.
The topics include:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
For more information about configuring a Usage Policy, refer to Section 220.127.116.11, "Modifying the Default Usage Policy" or Section 18.104.22.168, "Creating a Usage Policy."
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.
For more information about configuring and working with Password Policies, refer to Section 5.1.1, "Working with Policies."
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.
For more information about granting privileged accounts, see Section 5.1.4, "Working with Grantees."
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.
For more information about configuring and working with Password Policies, refer to Section 5.1.1, "Working with Policies."