Automated Security deployment : Oracle IAM Deployment Wizard

With the release of Identity & Access Management suite 11g R2 PS2 (11.1.2.2.0), Oracle has released a new deployment tool to automate the installation and configuration of products related to the IAM suite.

This tool is named Oracle Identity and Access Management Deployment Wizard.

Key insights –

1. Installs & Configures - OIM , OAM , OUD , OHS , Webgates etc.Also creates basic Users & groups in OUD , configures OUD as Identity store for OAM.
2. You will need to download a completely separate set of software for this. The normal Identity & Access Management suite download packages won’t work.If you go to Oracle Download page for 11.1.2.2.0, here, you will see at the bottom a section for the Deployment Repository
3. This 12GB package contains everything you will need: The IAM Suite, RCU, WebLogic, JDK, WebTier, WebGate (11g), SOA, OUD, and of course, the Deployment Wizard.
4.  If everything goes well, it will take approximately 6 hours to do everything. If this seems long, keep in mind that it’s installing OAM,OIM,OUD , configuring them, integrating OIM and OAM, setting up LDAPSync, SSL enabling some components, configuring OHS with Webgate, configures WebLogic Authentication Providers, performs some light performance tuning, does OUD reconciliation
5.  Supports both Single Node & HA configurations.

Checkout this blog for more details, limitations etc. !

OAM Single-Sign-On (SSO) Deployment Architecture : Best Practice

Recently I came across couple of OAM Deployment Architectures which have been implemented and can potentially cause multiple issues - 

• Using the same OHS Instance which has a webgate deployed on it for reverse proxy to OAM Servers in addition to the target application which needs to be protected (e.g. WebCenter)
• Front-ending OAM Servers directly with an external Load Balancer(LBR) skipping the Web Server layer altogether

Ideally, OAM should be front-ended by a web server/OHS instance of it's own to 

• Allow separate streams of HTTP traffic(in addition to one for Application) 
• Scale the SSO architecture to other target applications - 
• In case the same OAM Server is used for a new application which needs to be SSO enabled as well, the standalone OHS which just services requests to OAM (and doesn't have any webgate on it) is a must!
• This would also ensure that any files needed to be cached (like javascript, css etc) for any OAM related applications can be cached at the OHS layer

(Image Courtesy : A-Team Blog) 

If we have to use a Load Balancer(LBR) to directly front-end the OAM Server instead of an intermittent OHS(probably due to cost constraints), we should have this LBR within the corporate network (in addition to an external LBR which front-ends the other OHS instance(s) for applications) and not in the DMZ to prevent the security risk of an external LBR based in the DMZ exposing the OAM located in the Application Tier directly.

Courtesy  :
1) Forum Post which was logged as few items in the A-Team blog mentioned below were not crystal clear
2) A-Team Blog