Planning an IDM Build Out for Fusion Apps Part 1 – Discussion Topics

Today I am kicking of a series of posts on planning an Oracle IDM build out for Fusion Apps. I will start by discussing a bunch of topics that should be discussed and worked through before you move forward with an IDM build out for FA.

I will then continue the series with a pre-install checklist and discussion of supporting characters that will need to participate in the install.

So, with that in mind I’ll dive right in to the topics for discussion:

My "enable debug logging" in OAM WLST script

I was on the phone with someone earlier today and mentioned in passing that I only need to run a simple script to turn debug logging on and off in my little test environment. The silence on the other end of the line told me either he didn't believe me or didn't realize how easy it is to do this sort of thing.

So here it is - enableOAMLogging.py

#!/home/oracle/Oracle/Middleware/Oracle_IAM1/common/bin/wlst.sh

connect('weblogic', 'ABcd1234', 't3://localhost:7010')
domainRuntime()

#Admin server:                                                                                                                                                                   
setLogLevel(logger="oracle.oam.plugin",level="TRACE:32", target="AdminServer", persist="0")
setLogLevel(logger="oracle.oam.extensibility",level="TRACE:32", target="AdminServer", persist="0")
setLogLevel(logger="com.oracleateam.iam.oamauthnplugin",level="TRACE:32",  target="AdminServer", persist="0",addLogger="1")

# OAM server                                                                                                                                                                     
setLogLevel(logger="oracle.oam.plugin",level="TRACE:32", target="oam_server1", persist="0")
setLogLevel(logger="oracle.oam.extensibility",level="TRACE:32", target="oam_server1", persist="0")
setLogLevel(logger="com.oracleateam.iam.oamauthnplugin",level="TRACE:32",  target="oam_server1", persist="0",addLogger="1")

listLoggers(pattern="oracle.oam.*",target="AdminServer")
listLoggers(pattern="com.oracleateam.iam.oamauthnplugin",target="AdminServer")


listLoggers(pattern="oracle.oam.*",target="oam_server1")
listLoggers(pattern="com.oracleateam.iam.oamauthnplugin",target="oam_server1")

disableOAMLogging.py is exactly the same except that it has lines like:

setLogLevel(logger="oracle.oam",level="", persist="1", target="oam_server1")

Setting level to the empty string toggles logging back to <Inherited>

SSL offloading and WebLogic server redux - client x.509 certificates

I recently had to revisit the subject of SSL offloading and WebLogic server to include the ability to do client certificate authentication. I was specifically doing this for use with Oracle Access Manager 11g, but the configuration steps are identical whether you are using OAM or just WebLogic.

Just to redraw the diagram so we're all on the same page, this is what a real environment with OAM in it might look like:

Note that I put "Apache" in front of the OAM server. That could be Apache, IIS, OHS or indeed any web server. In my case I happened to use Apache but the configuration is the same for Apache or OHS.

The first thing I had to do was configure Apache to support SSL. I'll leave that step up to you - just follow the normal instructions for your web server. Then I created a new VirtualHost for :443 that looks like this:

<VirtualHost *:443>  
  ServerName linux.ktest.oracleateam.com

  SSLEngine on  
  SSLProtocol all -SSLv2  
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW  
  SSLCertificateFile /home/oracle/simpleCA/linux.ktest.oracleateam.com.crt
  SSLCertificateKeyFile /home/oracle/simpleCA/linux.ktest.oracleateam.com.key
  
  <LocationMatch ^/oam/server/.*>
    SetHandler weblogic-handler
  </LocationMatch>
  
  <LocationMatch ^/oam/CredCollectServlet/X509.*>
    SSLVerifyClient require
    SSLVerifyDepth 1
    SSLCACertificateFile /home/oracle/simpleCA/ca.crt
    SSLOptions +StdEnvVars +ExportCertData
  </LocationMatch>
  
</VirtualHost>

There are a couple of interesting things in there.

1. The LocationMatch for "^/oam/server/.*" which routes any requests that match that regular expression on to the WebLogic plug-in so they can be sent to the OAM server
2. The LocationMatch for "^/oam/CredCollectServlet/X509.*" In OAM 11g the only URL that actually needs to require client certificate authentication is the x.509 credential collector. By putting "SSLVerifyClient require" on that Location we are telling Apache that unless the user presents a client certificate it should not process the request but instead demand a certificate from the user
3. The last item is the one that caused me grief - unless you add "SSLOptions +StdEnvVars +ExportCertData" mod_wl will not send the client certificate information down to the WebLogic server

That's all the configuration you need to do in Apache (or OHS). Now you need need to do a couple of steps inside WebLogic.

1. Check the "WebLogic Plugin Enabled" checkbox as we did in the previous blog post.
2. On the same page check the "Client Cert Proxy Enabled"

To reiterate where those are - go to the WebLogic Console (http://localhost:port/console), click on the domain name inside the left hand navigation tree, then click the Web Applications tab. You should find both of those settings towards the bottom of the screen.

That should be all you need to do.

Hostname References and Architecture Simplification in the IDM Build Out for Fusion Apps

In my last post, I discussed the reference architecture for the Identity and Access Management build out of Fusion Apps.

The reference architecture is pretty complex in that it is completely HA, separates all the IDM services into 3 tiers for maximum network security, and separate many of the services onto different physical nodes to account for load separation for high volume production environments.

There are reasons one might want to simplify this for development, QA, or even production environments.  Specifically, you may want to consolidate physical hosts, not do HA, or not use a load balancer for some traffic that does in the reference architecture.  

I will now discuss how to use the IDM EDG (Oracle Identity Management Enterprise Deployment Guide, Fusion Apps Edition) as a guide for your build out even if you want to deviate from the reference architecture in some way.  The key to this is understanding how the EDG makes hostname references and understanding how these references translate to the environment you are creating.

Identity Management for Fusion Applications Reference Architecture

As I’ve talked about in my last couple posts (here and here), Fusion Apps relies on an Oracle Identity and Access Management platform which must be created through a prescribed build out of Oracle’s IAM stack. The guide for the build out is the Enterprise Deployment Guide for Identity Management (Fusion Apps Edition), which we will refer to now simply as the ‘EDG’ for short.

The first chapter of the EDG includes a good diagram and description of Oracle’s reference architecture for the IAM platform for Fusion Apps. The rest of the EDG walks you through building out an IDM environment that fits this reference architecture.

In this post I’ll give a guided tour of this reference architecture and at the end discuss how you can still use the EDG to build out a simplified environment if that is the route that you want to take.

Interview with a Security Architect

Oracle is hosting a very interesting web event that I thought I would point our readers to.

The event is an interview with Balganesh Krishnamurthy who is the lead Security Architect for Agilent's Identity and Access Management program.

Balganesh shares his thoughts on creating an Identity & Access Management roadmap and how to build a business case for Identity Management.

With over 15 years of experience leading Enterprise software deployments, Balganesh has seen it all. In this session, he discusses his roadmap and provides guidance on how other architects can learn from his experience.

One reason I think that this event could be good is that in my experience customers that see IAM as strategic and therefore develop clear roadmaps that map to business objectives do achieve better results than customers that adopt an ad-hoc strategy to IAM.

With that in mind, here are the event details:

Webcast: Best Practices: Getting Started with an Identity Platform

Date: Wednesday, February 15, 2012

Time: 10:00 AM PST

Register for the event here.

Logging in your OAM plug-in

I've been playing around with the OAM plug-in API and working on putting together a very simple JDeveloper project that includes a custom login form and an OAM plug-in that demonstrates the basics of using the interface.

I'm going to get that blog post out eventually, but for right now I need to talk about logging inside your plug-in.

OAM uses the Java Logger (java.util.logging.Logger and related classes) to record all of the debugging information in an easily manageable way. When you write your first plug-in it can be a bit confusing to figure out how the heck you get your logging messages out. It's not at all complicated, but it does mean you need to understand how OAM manages its logging.

Let's start with the absolutely minimum amount of code you need to log:

package com.oracleateam.iam.oamauthnplugin;

// a bunch of imports go here

public class DemoAuthNPlugin extends AbstractAuthenticationPlugIn {
  public DemoAuthNPlugin() {
    super();
    LOGGER.finest(this.getClass.getName() + " constructor called.");
  }

  // other methods
}

That's it. The bare minimum needed to get logging working.

Of course you need to do a little more work... Click through to see what else you need to do.