Best practices for Oracle Access Manager deployment

Readers,

It is very important to follow best practices for OAM deployment for either single DC setup, or MDC setup or HA functionality etc., Some of the best practices are mentioned below and I will keep updating this post based on comments/feedback.

1. Verify the certification matrix for OAM deployment before beginning installation.
2. Use the latest Java, WebLogic Servers based on certification matrix.
3. Use the same path for Weblogic Home, Oracle Home and Oracle Common Home across environments.
4. For WebServers, use environment specific instance names rather than default names. For eg., while installing and configuring OHS instances, the default instance name is ohs1. It is suggested to use name denoting environment name and server name such as DEV_OHS1 or PROD_OHS1. 
5. For WebServers in HA, if you are installing OHS on multiple boxes then it is suggested to use different OHS instance names. For eg., PROD_OHS1 (on 1st box), PROD_OHS2 (on 2nd box). This will help associating OHS instances with unique instance names in EM console for monitoring purpose. 
6. Ensure that Non-Prod (or QA) and Prod environments identical for all IAM components in order to reproduce Production issues and make future deployments easier and better for operations.
7. Ensure to configure OMSM, Policy Manager and OAM servers in different clusters during initial WebLogic domain configuration.
8. Use load balancers for backend LDAP servers for user store. 
9. Use custom authentication plugins only as per needs. Custom Plugins have maintenance nightmares for Ops team. 
10. Schedule regular backups for oam-config.xml, policy exports and partners export along with DB backups.
11. While configuring user store, specify Referral policy as FOLLOW. Also, specify Min/Max pool size and timeout parameters as per load testing results. 
12. Selectively configure required audit events only.  
13. Avoid creating sample cgi or server side pages that would print headers information. For eg., cgi-bin/printenv script is a common script that's protected through OAM for validation purpose. After Production go-live, remove those test pages. 
14. Exclude images, css files and other static contents in policies instead of using Unprotected policies. 
15. Try to update WebLogic CPU patches and JDK CPU patches based on sensitivity of the fixes. Thorough testing is required before pushing these patches to Production. Sometimes these patches may break OAM functionality. 
16. Use similar RCU versions across environments.
17. Use certain security headers X-XSS-Protection, Strict-Transport-Security etc., in Login WebGate WebServers for better protection. 
18. Use Log rotation for OAM and other WebLogic servers to prevent complete disk usage. 
19. Ensure that only required firewall ports are opened to and from OAM servers instead of opening it through entire subnets. This is to provide better security.
20. Use WebGate CERT mode only if needed otherwise it will degrade performance. 
21. Use SSL at Node Manager and WebLogic Servers are only as needed. 
22. Ensure that Login WebGate has SSL enabled.
23. Ensure that 3rd party cert is used for OAM deployment in Prod and non-prod environments. 
24. Do periodic rolling restarts of OAM server for better system performance.
25. Associate OHS and OAM components with EM 12c for performance and system alerts.
26. Use Min / Max Heap size for OAM tuning. 
27. Use appropriate number of processes, sessions etc., parameters in OAM DB schema.
28. If there are more IAM components in the architecture, it is suggested to use separate DB for OAM component since OAM uses APS for MDC synchronization where as other products requires DG or GG.
29. Ensure to grant admin privileges to LDAP users for OAM console instead of giving generic administrative access to all users.  

 That's it for today. Happy reading!!