The Oracle Access Management Console is a Java EE application that must be installed and run on the same computer as the WebLogic Administration Server. Other key applications that run on the WebLogic Administration Server include the WebLogic Server Administration Console and Enterprise Manager for Fusion Middleware Control.
The Oracle Access Management Console might be referred to as the OAM Administration Server. However, this is not a peer of the OAM Server deployed on a WebLogic Managed Server.
The Oracle Access Management runtime instance deployed on Oracle WebLogic Managed Servers is referred to as an OAM Server. Each OAM Server must be registered with Access Manager to enable communication with registered agents during authentication, authorization, and resource access.
Administrators can extend the WebLogic Server domain and add more OAM Server instances whenever needed, using either:
The WebLogic Server Administration Console, after which you manually register the OAM Server instance using the Oracle Access Management Console
The WebLogic Configuration Wizard
Customized Oracle WebLogic Scripting Tool (WLST) commands as described in WLST Command Reference for WebLogic Server
The last two methods automatically register the OAM Server instance, which appears in the Oracle Access Management Console; no additional steps are required.
This section introduces OAM Server instance registration and management using the Oracle Access Management Console:
See Also:
Features Not In Access Manager 11.1.2.3.0 for a comparison of Access Manager 11g versus Oracle Access Manager 10g.
Administrators can add one or more Managed Servers to the WebLogic Server domain for Oracle Access Management.
When using the WebLogic Configuration Wizard, the OAM Server is automatically registered. However, if the configuration wizard was not used, the OAM Server must be registered manually to open a communication channel.
Alternatively. You can use custom WLST commands for OAM to display, edit, or delete a server registration Any changes are automatically propagated to the Oracle Access Management Console and to every OAM Server in the cluster.
Only OAM Servers are registered with Oracle Access Management. The Oracle Access Management Console (on the WebLogic Administration Server) is not registered with itself.
Regardless of the method used to register an OAM Server, details for each instance are located on the System Configuration tab, Common Configuration section in the Oracle Access Management Console, including:
Server name, Host, Port
Proxy: Performs as the legacy Access Server and defines the communication security mode. For more information, see:
Oracle Coherence: Provides a distributed cache for various OAM services, including session data.
Administrators can search for a specific instance registration, register a newly installed OAM Server, view, modify, or delete server registrations using the Oracle Access Management Console. For more information, see "OAM Server Registration Page".
Oracle Access Management server-side components include Proxy servers to maintain backward compatibility with Oracle Access Manager 10g policy-enforcement agents (10g Webgates and Access Clients) and OracleAS SSO 10g mod_osso (known as OSSO Agents in 11g), as well as OpenSSO Agents.
Legacy 10g SSO: The OAM Proxy can accept requests from multiple Access clients concurrently and enables all Webgates and AccessGates (known as Access Clients in 11g) to interact with Access Manager. For more information, see "OAM Proxy Settings".
Legacy OracleAS 10g (OSSO): The integrated OSSO proxy handles token generation and validation in response to token requests during authentication using OSSO Agents with Access Manager. The OSSO proxy needs no configuration. Simply register the OSSO agent as described in Introduction to Agents and Registration and Registering and Managing OAM 11g Agents.
You can upgrade OracleAS SSO to use Access Manager SSO when you have a legacy deployment where Oracle Access Manager 10g is integrated and used in combination with OracleAS (OSSO) 10g.
After upgrading OSSO to use Access Manager 11g, you can have 10g Webgates operating with Access Manager 11g SSO the same deployment. In this situation, the OAM Proxy forwards requests to either the 10g Access Server or to Access Manager 11g as needed.
The Oracle Access Manager 10g ObSSOCookie is an encrypted session-based single sign-on cookie that is generated when a user authenticates successfully. The 10g ObSSOCookie stores user identity information, which you can cache if needed.
The integrated OAM Proxy supports the AES encryption algorithm of the 10g ObSSOCookie to enable backward compatibility with release 10g Webgates. The 10g Access Server can decrypt the cookie created by the OAM Proxy (and vice versa). This allows Access Manager 11g to perform authentication and Oracle Access Manager 10g to perform authorization (and vice versa).
Note:
An Access Manager 11g ObSSOCookie created by OAM Proxy is compatible with the 10g ObSSOCookie created by Access Server.
For more information, see "OAM Proxy Settings".
The OAM Server communication mode can be changed after a successful agent registration. The Webgate mode needs to be at the same level as the OAM Server mode or higher for the server to continue communicating with the agent.
Communication modes for the OAP channel include:
Open: Use this unencrypted mode if communication security is not an issue in your deployment.
Simple: Use this Oracle-signed certificate mode if you have some security concerns, such as not wanting to transmit passwords as plain text, but you do not manage your own Certificate Authority (CA).
Cert: Use if you want different certificates on OAM Servers and WebGates and you have access to a trusted third-party CA.
On each individual OAM Server registration, the security mode is defined on the Proxy tab, as described in "OAM Server Registration Page".
Simple and Cert modes also require:
Security passwords that are common to all OAM Servers and WebGates, as described in "Managing the Access Protocol for OAM Proxy Simple and Cert Mode Security".
Appropriately signed X.509 digital certificates, as described in Securing Communication.
At least one OAM Server instance must be running in the same mode as the agent during agent registration. Otherwise, agent registration fails. After agent registration, however, you can change the communication mode of the OAM Server. Communication between the agent and server would continue to work as long as the Webgate mode is at least at the same level as the OAM Server mode or higher. The agent mode can be higher but cannot be lower. For example, of OAM Server mode is Open, agents can communicate in any of the three modes. If OAM Server mode is Simple, agents can use Simple or Cert mode. If OAM Server mode is Cert, agents must use Cert mode.
See Also:
Most Oracle Access Management functional services take up changes made through the Oracle Access Management Console without restarting OAM Server.
Table 6-1 identifies conditions that do require a server restart.
Table 6-1 Conditions Requiring Server Restart
| Event | Description |
|---|---|
|
Session persistence change |
A change from database to in-memory (or vice versa) session persistence requires an OAM Server restart. |
|
Oracle Coherence port number |
A change to the port number requires an OAM Server restart. |
|
Load balancer server definition |
A change requires an OAM Server restart. |
|
Managed Server port number |
A change requires an OAM Server restart. |
|
New Managed Server |
Adding a new managed server to the cluster requires restarting the AdminServer to policy enable uptake. OAM Servers must be restarted to reinitialize Oracle Coherence security configuration with the new server included. |