How to Configure a SOA Suite 11g Domain with OES

This is likely to be the first of many posts for an upcoming POC that I'm working on. I actually have to travel to Europe to go work with the local Oracle team there. This means lots of being awake at the wrong time, so I'm sure they'll be posts-a-plenty.

This POC is a realization of the "pre-cache" entitlements architecture that I discussed previously. To that end, I need to get the OES WLS SM (embedded PDP) running inside of a SOA Suite 11g domain.

DISCLAIMER: This is not a supported configuration at this time.

Part 0 - Setting up the Environment

1. Get SOA Suite 11g Domain configured (1 admin server, 1 managed server)
2. Install OES 10.1.4.3 and apply CP2. Make sure that you install CP2 before you try to start the admin server - it won't work. If you don't the admin server will come up, but you'll get an error like "Admin Service Not Available." Save yourself the trouble, and upgrade to CP2 first.
   

Part 1 - Configure the WLS SM for the SOA Suite Domain Admin Server

1. Run the configtool and set-up the domain with the OES realm - set-up the ARME port as say 28000
2. Now you'll need to make some changes to the security realm created by the configtool. By default, the config tool doesn't include the DefaultAuthenticator and the DefaultIdentityAsserter in the realm.
3. First, you'll need to change the server to use the old realm - called my realm. Go into the config.xml and change the value of <default-security-realm> to myrealm. Now you can start the admin server.
   
4. Next, log into the weblogic console http://localhost:7001/console, and create the DefaultAuthenticator and the DefaultIdentityAsserter. Set the JAAS Control Flag on both the DefaultAuthenticator and the DatabaseAuthenticator to SUFFICIENT and order the DefaultAuthenticator first (I'll explain why in a second).
5. Before you restart the admin server, make sure to force a policy distribution from OES. The 100% way to do this is as follows:

• Clean out the ARME cache - this means deleting the state.chk and all of the contents of the PolicyA and PolicyB directories under SSM-HOME/wls-ssm/instance/<instance_name>/work/runtime
• Delete the instance from the OES Admin console. All that this will do is remove the entry from the database...it will get recreated when the ARME starts-up and contacts the admin server.
• From the OES Admin console, push a policy distribution.

Finally, restart the SOA Suite Domain Admin Server.

Part 2 - Configure the WLS SM for the SOA Suite Domain Managed Server

1. Run the instancewizard again, but this time for the managed server - use the same config name, but a different ARME port - say 28001
2. Modify the set-wls-env.cmd in the SSM-HOME/wls-ssm/instance/<managed_server_instance_name>/bin to not include the xml-api.jar, xalan.jar, and xercesImpl.jar in the system classpath. If you don't make this change, then SOA Deployments will not work.
3. Next, you need to create special start-up script for the managed server that ensure that a different instance is used for the managed and admin servers. If not, then the ARME ports will conflict. This can be done as follows:

• Copy DOMAIN_HOME/bin/startWebLogic.bat to startWebLogic_ManagedServerSM.bat
• Modify the DOMAIN_HOME/startWebLogic_ManagedServerSM.bat and change the call to the set-wls-env.bat from SSM-HOME/wls-ssm/instance/<admin_instance_name>/bin to SSM-HOME/wls-ssm/instance/<managed_server_instance_name>/bin
• Copy DOMAIN_HOME/bin/startManagedWebLogic.bat to startManagedWebLogic_ManagedServerSM.bat
• Modify the startManagedWebLogic_ManagedServerSM.bat from calling DOMAIN_HOME/bin/startWebLogic.bat to DOMAIN_HOME/bin/startWebLogic_ManagedServerSM.bat

Part 3 - Working in this Environment - Discovery Mode is Your Friend

The configtool secures enough of the adminserver so that it can start. It makes sense to run with in DiscoveryMode - at least at the beginning. Remember, there are two instances of the SM, so you'll need to modify the set-wls-env.bat of both SM. If you don't have the internal resources of SOA Suite protected, then bad things happen - i.e. composites don't get deployed.
Once you get everything starting and deploying smoothly, use the policy import tool to load the policies, and then change out of Discovery Mode

Oh, so the reason for having to have a specific ordering on the authentication providers, and having the DefaultAuthenticator first and sufficient is that the DatabaseAuthenticator adds a special IdentityDirectoryPrincipal, that JDeveloper doesn't have the classes - so I simplified this by "tweaking" the realm. In practice, the DatabaseAuthenticator is not really used, but it is the authentication provider that is created by default in the configtool. This is really just a minor issue, but I wanted people to understand why the change.