OAM 11g Single Sign-On and OAM 10g Cookies

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

In an earlier post I talked about how cookies work when you're using OAM 11g server with OAM 11g WebGates. But the OAM 11g server also works with OAM 10g WebGates and there are reasons you'd deploy 10g WebGates today. But OAM 11g and 10g have fundamentally different behavior when it comes to the cookies.

So how do cookies work when you're using 10g WebGates with the 11g server?

Planning an IDM Build Out for Fusion Apps Part 2 – Pre Build Out Checklist

In my last post I listed all of the architectural decisions that you’ll want to work through before diving into an IDM build out for Fusion Apps.

In this post, I’d like to take things one step further and put forth a checklist of tasks that you’ll want to accomplish before beginning the actual (onsite) build out.

Failure to complete these items before the build out will turn what is already a fairly long and intensive process into a longer and frustrating process. You want to make sure going into the actual build out that you have all the necessary hardware, software, and skill pre-requisites to ensure success.

The IDM build out for Fusion Apps and the Fusion Apps install in general is really a project where advance planning with pay off in spades.

So with that being said, I give you my list:

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.