Thursday, December 30, 2010

My Final Post at the Fusion Security Blog - It's like he was never here ;)

All,

December 31,2010 is my last day at Oracle. This blog has been a really amazing experience for me, and truly one of the most interesting and rewarding parts of my job at Oracle during the past three years. It represents a significant amount of work to build consistent quality technical content, and actively work with customers on solving their most challenging problems. Thank you for everyone who has made this blog such a success.

But wait....the blog will continue on. Brian and Chris are redoubling their efforts to continue what we started on into the coming year.

I've started a new blog at http://xmlgateway.blogspot.com. I hope that you'll check it out.

Thanks, Good Luck and Happy New Year,

Josh

Wednesday, December 22, 2010

Creating OES SM instances on 64 bit systems

I've already opened a bug on this against OES 10gR3 CP5, but in case anyone else runs into it before it gets fixed I wanted to blog it too. (NOTE: CP5 is when official support was introduced for running OES on a 64 bit system with a 64 bit JVM)

When you run the ConfigTool on a 64 bit Linux host you may see an error like this:

Check completed succesfully.
Starting to make changes ...
Creating SSM instance...
2010-12-22 14:36:46,952 [Main Thread] ERROR com.bea.security.SsmConfigTool.AlesConfig - Instance wizard returned error: 255
Done creating SSM instance.
Loading ALES Policy using policyloader. Please wait ...
2010-12-22 14:36:46,956 [/software/oracle/middleware/ales32-ssm/wls-ssm/instance/irmssm/bin/policyloader.sh] ERROR com.bea.security.SsmConfigTool.Daemon - Error During execution of requestd command 
java.io.IOException: java.io.IOException: /software/oracle/middleware/ales32-ssm/wls-ssm/instance/irmssm/bin/policyloader.sh: not found

As you can see the first error is that the instancewizard failed. THAT problem is probably occurring on your system because when you applied the CP you chose a 64 bit JVM but the instancewizard.sh script has a hard coded JAVA_HOME pointing to a 32 bit JVM. When the instance wizard runs (under the covers) the JVM is trying to load a 64 bit JNI library that the CP installed.

The fix?

Edit instancewizard.sh and change JAVA_HOME to point to the right JVM. Like so:

JAVA_HOME="/usr/java/latest"

Incidentally I found the root cause by running instancewizard.sh with the -log= and -log_priority= flags. You can run ./instancewazard.sh -h to get the command line help.

Thursday, December 16, 2010

A Quick Note about Oracle Access Manager 11g and WebLogic


A lot of people have been asking me lately about how Oracle Access Manager (OAM) 11g integrates with WebLogic.  The answer is very straight forward.  OAM 11g integrates with WebLogic using the very same components used to integrate OAM 10.1.4.3.  Under most circumstances, that means using the OAM Identity Asserter (the same one used with OAM 10.1.4.3) which asserts the OAM_REMOTE_USER header as the user principal in the JAAS subject.  This is used in conjunction with an authentication provider (usually an LDAP provider) which looks up the user in the identity store and builds the rest of the subject based on the group memberships of the user.

You can read more details about integrating OAM and WLS here: http://fusionsecurity.blogspot.com/2010/01/integrating-oracle-access-manager-oam.html

Again, it is important to fully understand how to use the OAM Identity Asserter in a secure solution.  I talked about the security of the Identity Asserter a while ago in this post: http://fusionsecurity.blogspot.com/2010/04/security-clarification-oam-identity.html

Thursday, December 9, 2010

Fusion Middleware and Certificate Expirations

I wanted to take a moment to blog about one of the most common, yet most easily preventable causes of middleware system outages. The cause is the expiration of digital certificates used in middleware infrastructure.

Certificates are used throughout many Oracle Fusion Middleware products for purposes of authentication and encryption. This includes:

  • Server certificates for SSL in OHS and WLS
  • Certificates used for intra and inter product transport communication in WLS, OAM, OAAM, OID, OVD, OIM, OSB etc…
  • Certificates used for signing and authentication in OWSM, WLS, OSB, OIF, and Oracle STS.

Despite the fact that digital certificates are such an integral part of middleware infrastructure, you might be surprised how many customers are not well organized about their PKI and in particular about when the different certificates in their infrastructure expire.

It is such a little, simple thing, but all it takes is one expired certificate in one middleware component to bring an application down.

I encourage you today to “not be that customer”, stay organized and keep track of when your certificates expire so that you can issue updated certificates before that happens.

A Note about OAM and the certificates used in Simple Mode

OAM has three different security “modes” for the communication done between the webgate (web server plug-in) and the OAM server component which processes authentication and authorization. These 3 modes are:

  • Open: Unencrypted communication
  • Simple: Communication over SSL using certificates generated by OAM using an Oracle CA certificate that comes with OAM. Simple mode is popular with customers who want to secure webgate to OAM server communication but don’t feel the need to use their own PKI infrastructure.
  • Cert: Communication over SSL using certificates issued by a third party CA.

The mode most relevant to this discussion on expiring certificates is simple mode where the certificates are generated automatically and may be out of sight and mind.

In OAM 10g the certificates are only issued with a validity period of one year by default. If you want to extend the validity period for the certificates generated in simple mode (and I recommend that you do), then follow the instructions in appendix F, section 2.9 of the OAM Identity Admin Guide: http://download.oracle.com/docs/cd/E12530_01/oam.1014/b32419/trblsht.htm#BABDDBJF

In OAM 11g, the validity period of the certificates used in simple mode is 10 years, making early expiration of the certificates less of a problem.