| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.4) Part Number E21032-11 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 1 (11.1.4) Part Number E21032-11 |
|
|
PDF · Mobi · ePub |
This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topologies.
This chapter includes the following topics:
Section 3.1, "Overview of Preparing the Network for an Enterprise Deployment"
Section 3.2, "About Virtual Server Names Used by the Topologies"
Section 3.7, "Managing Oracle Access Manager Communication Protocol"
You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.
The Identity Management enterprise topologies use the following virtual server names:
oimadmin.mycompany.com (split domain topology only)
Some of the virtual server names are used by some topologies and not others.
Ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.
You will define the virtual server names on the load balancer using the procedure in Section 3.3, "Configuring the Load Balancers"
The rest of this document assumes that the deployment is one of those shown in Section 2.1.1, "Reference Topologies Documented in the Guide."
This entry is only required if Identity information is stored in an Oracle Internet Directory and Oracle Virtual Directory is being used.
This virtual server is enabled on LBR2. It acts as the access point for all identity-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the directory tier. Traffic to both SSL and non-SSL is configured. The clients access this service using the address oididstore.mycompany.com:3131 for SSL and oididstore.mycompany.com:3060 for non-SSL.
This virtual server directs traffic received on port 3060 to each of the Oracle Internet Directory instances on port 3060.
This virtual server directs traffic received on port 3131 to each of the Oracle Internet Directory instances on port 3131.
Monitor the heartbeat of the Oracle Internet Directory processes on LDAPHOST1 and LDAPHOST2. If an Oracle Internet Directory process stops on LDAPHOST1 or LDAPHOST2, or if either host LDAPHOST1 or LDAPHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
This virtual server is enabled on LBR2. It acts as the access point for all policy-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the directory tier. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address policystore.mycompany.com:636 for SSL and policystore.mycompany.com:389 for non-SSL.
Note:
Oracle recommends that you configure the same port for SSL connections on the LDAP server and Oracle Internet Directory on the computers on which Oracle Internet Directory is installed.
This is a requirement for most Oracle 11g products that use Oracle Internet Directory through the load balancing router.
This virtual server directs traffic received on port 389 to each of the Oracle Internet Directory instances on port 3060.
This virtual server directs traffic received on port 636 to each of the Oracle Internet Directory instances on port 3131.
Monitor the heartbeat of the Oracle Internet Directory processes on LDAPHOST1 and LDAPHOST2. If an Oracle Internet Directory process stops on LDAPHOST1 or LDAPHOST2, or if either host LDAPHOST1 or LDAPHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
This virtual server is enabled on LBR2. It acts as the access point for all Identity Store LDAP traffic. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address idstore.mycompany.com:636 for SSL and idstore.mycompany.com:389 for non-SSL.
If your Identity Store is accessed through Oracle Virtual Directory, monitor the heartbeat of the Oracle Virtual Directory processes on LDAPHOST1 and LDAPHOST2. If an Oracle Virtual Directory process stops on LDAPHOST1 or LDAPHOST2, or if either host LDAPHOST1 or LDAPHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
If your Identity Store is in Oracle Internet Directory and is accessed directly, monitor the heartbeat of the Oracle Internet Directory processes on the Oracle Internet Directory Hosts. If an Oracle Internet Directory process stops on one LDAPHOST or one LDAPHOST is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
If you have an Oracle Internet Directory-only topology, idstore.mycompany.com points to the Oracle Internet Directory in which you are storing your identity data. If you are storing your identity data in a third-party directory or want to front your Oracle Internet Directory Identity Store with Oracle Virtual Directory, then idstore points to Oracle Virtual Directory.
If your identity store is in Oracle Internet Directory, this virtual server directs traffic received on port 389 to each of the Oracle Internet Directory instances on port 3060.
If your identity store is in Oracle Internet Directory, this virtual server directs traffic received on port 636 to each of the Oracle Internet Directory instances on port 3131.
If your identity store is in Oracle Virtual Directory, this virtual server directs traffic received on port 389 to each of the Oracle Virtual Directory instances on port 6501.
If your identity store is in Oracle Virtual Directory, this virtual server directs traffic received on port 636 to each of the Oracle Virtual Directory instances on port 7501.
This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address admin.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Directory Services Manager.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the admin.mycompany.com virtual host.
This virtual server is only required if a split domain topology is being used.
This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services in the OIM Domain. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address oimadmin.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Directory Services Manager for Oracle Internet Directory.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the oimadmin.mycompany.com virtual host.
This virtual server is enabled on LBR1. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address idminternal.mycompany.com:80 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services
Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the idminternal.mycompany.com virtual host.
This is the virtual name which fronts all Identity Management components, including Oracle Identity Manager, and Oracle Access Manager.
This virtual server is enabled on LBR1. It acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address sso.mycompany.com:443 and in turn forward these to ports 7777 on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.
Configure this virtual server in the load balancer with both port 80 and port 443.
This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.
Several virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.
There are two load balancer devices in the recommended topologies. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various DMZs. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.
The enterprise topologies use an external load balancer. This external load balancer must have the following features:
Ability to load-balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.
Port translation configuration.
Monitoring of ports (HTTP and HTTPS).
Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for OracleAS Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.
The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.
Ability to detect node failures and immediately stop routing traffic to the failed node.
Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.
Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.
SSL acceleration (this feature is recommended, but not required).
Configure the virtual server(s) in the load balancer for the directory tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between the Oracle Access Manager and the directory tier.
Ability to Preserve the Client IP Addresses: The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.
The procedures for configuring a load balancer differ, depending on the specific type of load balancer. Refer to the vendor supplied documentation for actual steps. The following steps outline the general configuration flow:
Create a pool of servers. This pool contains a list of servers and the ports that are included in the load balancing definition. For example, for load balancing between the web hosts you create a pool of servers which would direct requests to hosts WEBHOST1 and WEBHOST2 on port 7777.
Create rules to determine whether or not a given host and service is available and assign it to the pool of servers described in Step 1.
Create a Virtual Server on the load balancer. This is the address and port that receives requests used by the application. For example, to load balance Web Tier requests you would create a virtual host for sso.mycompany.com:80.
If your load balancer supports it, specify whether or not the virtual server is available internally, externally or both. Ensure that internal addresses are only resolvable from inside the network.
Configure SSL Termination, if applicable, for the virtual server.
Assign the Pool of servers created in Step 1 to the virtual server.
Tune the time out settings as listed in Table 3-3, "Ports Used in the Oracle Identity Management Enterprise Deployment topologies". This includes time to detect whether a service is down.
For an Identity Management deployment, configure your load balancer as shown in Table 3-1.
Table 3-1 Load Balancer Configuration
| Virtual Host | Server Pool | Protocol | SSL Termination | External | Other Required Configuration/Comments |
|---|---|---|---|---|---|
|
|
|
HTTP |
No |
Yes |
Identity Management requires that the following be added to the HTTP header:
|
|
|
|
HTTP |
Yes |
Yes |
Identity Management requires that the following be added to the HTTP header:
|
|
|
|
HTTP |
No |
No |
|
|
|
|
HTTP |
No |
No |
Split Domain Topology Only |
|
|
|
LDAP |
No |
No |
|
|
|
|
LDAP |
No |
No |
|
|
|
|
LDAP |
No |
No |
If you have an Oracle Internet Directory-only topology and are not using Oracle Virtual Directory, the server pool must contain Oracle Internet Directory servers. |
|
|
|
LDAP |
No |
No |
If you have an Oracle Internet Directory-only topology and are not using Oracle Virtual Directory, the server pool must contain Oracle Internet Directory servers. |
|
|
|
LDAP |
No |
No |
Only required if Identity Management users are stored in an Oracle Internet Directory and Oracle Virtual Directory is being used. |
|
|
|
LDAP |
No |
No |
Only required if Identity Management users are stored in an Oracle Internet Directory and Oracle Virtual Directory is being used. |
Footnote 1 For information about configuring IS_SSL, see "About User Defined WebGate Parameters" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.
A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure of the node where the IP address is assigned, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.
The following is a list of the Virtual IP addresses required by Oracle Identity Management:
adminvhn.mycompany.com
In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from IDMHOST1 to IDMHOST2, or vice versa.
oimadminvhn.mycompany.com
You need this virtual IP address if you are using a split domain topology. It serves a similar function to adminvhn.mycompany.com. This virtual IP address fails over along with the Administration Server from OIMHOST1 to OIMHOST2, or vice versa.
soahostxvhn.mycompany.com
One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration.
Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.
oimhostxvhn.mycompany.com
One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.
Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.
Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 3-1. For a split domain topology, configure them as illustrated in Figure 3-2.
Table 3-2 provides descriptions of the various virtual hosts.
Table 3-2 Virtual Hosts
| Virtual IP | VIP Maps to... | Description |
|---|---|---|
|
VIP1 |
ADMINVHN |
ADMINVHN is the virtual host name that is the listen address for the Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running (IDMHOST1 by default). |
|
VIP2 |
SOAHOST1VHN |
OIMHOST1VHN is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA1 process is running (OIMHOST1 by default). |
|
VIP3 |
SOAHOST2VHN |
OIMHOST2VHN is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA2 process is running (OIMHOST2 by default). |
|
VIP4 |
OIMHOST1VNH |
OIMHOST1VNH is the virtual host name that maps to the listen address for the WLS_OIM1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM1 process us running (OIMHOST1 by default) |
|
VIP5 |
OIMHOST2VNH |
OIMHOST2VHN is the virtual host name that maps to the listen address for the WLS_OIM2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM2 process us running (OIMHOST2 by default) |
|
VIP6 |
OIMADMINVHN |
OIMADMINVHN is the virtual host name that is the listen address for the Oracle Identity Manager Administration Server. It fails over with manual failover of the Administration Server. It is enabled on the node where the Oracle Identity Manager Administration Server process is running (OIMHOST1 by default). |
Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.
Most port numbers are assigned after installation. You can use different port numbers if you want to. The port numbers shown in Table 3-3 are examples that are used throughout this guide for consistency. If you use different port numbers, you must substitute those values for the values in the table wherever they are used.
Table 3-3 lists the ports used in the Oracle Identity Management topologies, including the ports that you must open on the firewalls in the topologies.
Firewall notation:
FW0 refers to the outermost firewall.
FW1 refers to the firewall between the web tier and the application tier.
FW2 refers to the firewall between the application tier and the directory tier.
Table 3-3 Ports Used in the Oracle Identity Management Enterprise Deployment topologies
| Type | Firewall | Port and Port Range | Protocol / Application | Inbound / Outbound | Timeout |
|---|---|---|---|---|---|
|
Browser request |
FW0 |
80 |
HTTP / Load balancer |
Both |
Timeout depends on all HTML content and the type of process model used for Oracle Identity Management. |
|
Browser request |
FW0 |
443 |
HTTPS / Load balancer |
Both |
Timeout depends on all HTML content and the type of process model used for Oracle Identity Management. |
|
Browser request |
FW1 |
80 |
HTTPS / Load Balancer |
Outbound (for intranet clients) |
Timeout depends on all HTML content and the type of process model used for IDM. |
|
Browser request |
FW1 |
443 |
HTTPS / Load Balancer |
Outbound (for intranet clients) |
Timeout depends on all HTML content and the type of process model used for IDM. |
|
Load balancer to Oracle HTTP Server |
n/a |
7777 |
HTTP |
n/a |
|
|
OHS registration with Administration Server |
FW1 |
7001 |
HTTP/t3 |
Inbound |
Set the timeout to a short period (5-10 seconds). |
|
IDMDomain Oracle WebLogic Administration Server access from web tier |
FW1 |
7001 |
HTTP / Oracle HTTP Server and Administration Server |
Inbound |
N/A |
|
Enterprise Manager Agent - web tier to Enterprise Manager |
FW1 |
5160 |
HTTP / Enterprise Manager Agent and Enterprise Manager |
Both |
N/A |
|
Oracle HTTP Server to WLS_ODS |
FW1 |
7006 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
Oracle HTTP Server to WLS_OAM |
FW1 |
14100 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
Oracle HTTP Server WLS_OIM |
FW1 |
14000 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the mod_weblogic parameters used |
|
Oracle HTTP Server WLS_SOA |
FW1 |
8001 |
HTTP / Oracle HTTP Server to WebLogic Server |
Both |
Timeout depends on the mod_weblogic parameters used |
|
Oracle HTTP Server management by Administration Server |
FW1 |
OPMN remote port (6701) and OHS Admin Port (7779) |
TCP and HTTP, respectively |
Outbound |
Set the timeout to a short period, such as 5-10 seconds. |
|
Oracle Access Manager Server 11g |
FW1 |
5574-5575 |
OAP |
Both |
N/A |
|
Oracle Access Manager Coherence port |
FW1 |
9095 |
TCMP |
Both |
N/A |
|
Oracle Coherence Port |
FW1 |
8000 - 8088 |
TCMP |
Both |
N/A |
|
IDMDomain Oracle WebLogic Administration Server access from directory tier |
FW2 |
7001 |
HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server |
Outbound |
N/A |
|
OIMDomain Oracle WebLogic Administration Server access from directory tier |
FW2 |
7001 |
HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server |
Outbound |
N/A |
|
Enterprise Manager Agent - directory tier to Enterprise Manager |
FW2 |
5160 |
HTTP / Enterprise Manager Agent and Enterprise Manager |
Both |
N/A |
|
OPMN access in directory tier |
FW2 |
OPMN remote port |
HTTP / Administration Server to OPMN |
Inbound |
N/A |
|
Oracle Virtual Directory proxy port |
FW2 |
8899 |
HTTP / Administration Server to Oracle Virtual Directory |
Inbound |
N/A |
|
Database access |
FW2 |
1521 |
SQL*Net |
Both |
Timeout depends on all database content and on the type of process model used for Oracle Identity Management. |
|
Oracle Internet Directory access |
FW2 |
3060 |
LDAP |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Internet Directory access |
FW2 |
3131 |
LDAP SSL |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
6501 |
LDAP |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
7501 |
LDAP SSL |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Identity Navigatory |
FW2 |
7001 |
HTTP |
Both |
N/A |
|
Load balancer to Oracle HTTP Server |
N/A |
7777 |
HTTP |
N/A |
N/A |
|
Session replication within a WebLogic Server cluster |
N/A |
N/A |
N/A |
N/A |
By default, this communication uses the same port as the server's listen address. |
|
Node Manager |
N/A |
5556 |
TCP/IP |
N/A |
N/A |
Note:
Additional ports might need to be opened across the firewalls to enable applications in external domains, such as SOA or WebCenter Portal domains, to authenticate against this Identity Management domain.
This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.
Oracle Access Protocol (OAP) enables communication between Access System components (for example, Access Manager server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.
Oracle Access Manager is responsible for creating sessions for users. When Oracle Access Manager is integrated with another Identity Management component, such as Oracle Identity Manager, authentication is delegated to those components.
A typical request flow is as follows:
The user tries to access a resource for the first time.
WebGate intercepts the request and detects that the user is not authenticated.
Oracle Access Manager credential collector is invoked and the user enters a user name and password in response to a prompt. Oracle Access Manager knows that password policy requires the password to be changed at first login, so the user's browser is redirected to Oracle Identity Manager.
The user is prompted to change password and set up challenge questions.
At this point, Oracle Identity Manager has authenticated the user using the newly entered password. Oracle Identity Manager creates a TAP request to say that Oracle Access Manager can create a session for the user. That is, the user will not be expected to log in again. This is achieved by adding a token to the user's browser that Oracle Access Manager can read.
The TAP request to Oracle Access Manager will include such things as:
Where the Oracle Access Manager servers are located.
What web gate profile to use.
WebGate profile password.
Certificates, if Oracle Access Manager is working in simple or cert mode.
The request flow when a user requests access is as follows:
The user requests access to a protected resource over HTTP or HTTPS.
The WebGate intercepts the request.
The WebGate forwards the request to the Oracle Access Manager server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).
The Oracle Access Manager server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.
Following authentication, the WebGate prompts the Oracle Access Manager server over Oracle Access Protocol and the Oracle Access Manager server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.
If the access policy is valid, the user is allowed to access the desired content and/or applications.
If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.
A domain is the basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server. You can define multiple domains based on different system administrators' responsibilities, application boundaries, or geographical locations of servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.
In the context of Identity Management, it is recommended that you deploy the Identity Management components, plus SOA, in a separate WebLogic Server domain from the one where SOA, WebCenter Portal and other customer applications might be deployed. In a typical enterprise deployment, the administration of identity management components such as LDAP directory, single sign-on solutions, and provisioning solutions is done by a different set of administrators from those who administer the middleware infrastructure and applications. Oracle Identity Manager can be deployed into a separate dedicated domain so that it can be patched independently of other products.
It is technically possible to deploy everything in a single domain in a development or test environment. However, in a production environment, the recommendation to use separate domains creates a logical administrative boundary between the identity management stack and the rest of the middleware and application deployment.
|
 Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
