Specifics of Multi Data Center using Oracle Access Manager

Readers,

This is a very generic post for understanding some specifications of designing and implementing Multi Data Center solution using Oracle Access Manager.

• If you are designing an IAM solution in a single Production data center involving multiple IAM products, then it is mandated for separate Database for OAM component alone. This is because OAM uses Automated Policy Synchronization feature to sync artifacts/policies from Master to Clone DCs without the need of database replication unlike OIM and OAAM etc., Therefore, if OAM and other products are using same database then OAM database should be separated before deploying a new OAM data center. 
• In a typical IAM deployment, login pages are either served from OAM or through DCC. In both case, front end web server is employed with WebGate. It is preferred to use Global LBR for OHS data center along with load VIP. Therefore, a global LBR will also be assigned as OAM server hostname. If N number of data centers are added in the future, a new local LBR can be assigned to Global LBR without changing the OAM hostname.
• It is advised to employ Global LBR for OAM servers (default 5575 TCP port) for WebGates to OAM server connections. 
• Server affinity and sticky session is mandatory for all Global LBRs in a MDC solution. 
• OAM to database connection should have direct connection instead of Global LBR for all databases since each OAM talks to its respective DC database.
• In the event of using Virtual Host concepts at web server layers, it is advised to have Global LBR with sticky session and server affinity for OAM server 14100 port too. 
• OAM LBR for 5575 port should be TCP and OAM LBR for 14100 port should be HTTP.
• If mod weblogic plugin is used in the deployment for MDC, it is advised to use OAM LBR for 14100 port using WebLogicCluster parameter. Some of the nuances of using WebLogicHost and WebLogicCluster for mod weblogic plugin will be explained in detail in separate post.
• Before running T2P commands on Master DC, it is mandated to remove IAMSuite agent password and mark Embedded LDAP as system /default stores.
• In an MDC solution, Primary DC OAM is designated as Master thus allowing write operations only in this OAM server. All the policy updates from Master DC will be pulled into Clone DCs using APS feature.
• When a new DC to be brought into the existing MDC deployment, perform T2P on master DC to generate binaries rather than using old T2P binaries because something might have changed since initial T2P deployment. 
• Ensure to run pasteConfig and pasteBinary only on Administrator node of OAM component and use pack/unpack for other OAM nodes.
• It is usually recommended to have single Middleware on a host to avoid jar conflicts etc., even though we had seen OAM and OUD binaries co-existing on same Middleware. 
• It is always advised to add a new OAM server on separate host instead of adding OAM server on an existing OAM host as this would provide better CPU and server performance. However, this can be decided after thoroughly analyzing performance metrics. 
• Attain due diligence with Transformation rules as incorrect rules or incomplete rules will result in abnormal behaviors and corrupt the Clone DC environment in the worst scenarios. Thus, thorough testing with APS is required.
• Session control parameters define the user behavior during run time in an MDC deployment. Therefore, thoroughly test the MDC solution using these parameters. Below parameter values allow users to access SSO protected applications even though the sessions are created in Remote OAM DCs by creating local sessions in the event of session retrieval failures. 

          SessionMustBeAnchoredToDataCenterServicingUser=true

          SessionDataRetrievalOnDemand=false

          Reauthenticate=false

          SessionContinuationOnSyncFailure=false

• Designing Global LBRs at every component OHS, OAM and LDAPs will provide 100% high availability and failover even when one of the component in a data center fails. 
• Ensure that firewall connectivity is open from one DC component layer to all other DCs as cross over functionality.
• Perform the load testing in MDC deployment before going live as this will provide the SLAs and response time for each and ever component and its LBR to fail over to other available local VIP.  
• There is no MDC support for OAM OAuth tokens. Therefore oauth access token generated in one data center is not validated by remote DC. 

As always, TEST, TEST , TEST the component MDC solution.