As members of the Fusion Middleware Architecture Group (a.k.a the A-Team), we get exposed to a wide range of challenging technical issues around security and Oracle Fusion Middleware. We're using this blog to answer common questions and provide interesting solutions to the real-world scenarios that our customers encounter every day.
NOTICE: All our post and much more can now be found at http://www.ateam-oracle.com/category/identity-management/

Wednesday, February 29, 2012

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:

Friday, February 24, 2012

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.

Thursday, February 23, 2012

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:

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

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

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.

Check the "WebLogic Plugin Enabled" checkbox as we did in the previous blog post.

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.

Tuesday, February 14, 2012

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.

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.

Friday, February 3, 2012

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.

Wednesday, February 1, 2012

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: