Friday, July 22, 2011

High Availability OES 11g Admin

Setting up High Availability (HA) in OES means a lot of things: Redundancy at the data layer (typically database), the admin layer (WebLogic or WebSphere), and depending on the policy model, the decision layer (PDP). HA for the admin is probably the least important of the three, as the PAP isn't part of the runtime typically, but I wanted to address the admin (PAP) layer for the time as it is fresh on my mind and there is a missing parameter in the docs that makes this hard.

The idea is that you would have two WebLogic domains using the same policy store, so that if one domain went down, you could still make policy edits, enroll, distribute changes, etc. As part of the initial post-install configuration for your first OES admin (let's call it instance1), you have to associate the underlying security services (OPSS) with a datastore. Let's assume you want to use database. describes how to do this. The command is:


Table 19-2 shows that you can specify a domain here, but will default to 'oes_domain'. What I've found is that it doesn't really have to match the actual WebLogic domain for this to work, but it is important in the HA configuration. Now say we configure instance2 on the same physical server, say on port 8001. We need to associate this domain as well, but we need to have it join the same policy store as the first domain. The way you do this is to WLST into the second domain (t3://instance2:8001), and run the following:

configureOESAdminServer(servertype="DB_ORACLE", domain=oes_domain, join="true")

Here I explicitly call out the first domain that I am joining, NOT the WebLogic domain name that I am running in. Because I didn't specify domain in instnace1, it default to oes_domain, and so that is what I want to join. Once you restart instance2, then you should be making updates to the same policy store from both OES servers. The join option isn't mentioned on this install page. I'm sure they'll include it once the Enterprise Deployment Guide for is out.

Thursday, July 21, 2011

OIM 11g Notifications

Notifications are one of the multiple features that were improved in OIM 11g release. The previous limitation of sending text based emails (out-of-the-box emails) only is gone.

Out-of-the-box templates for events like 'Reset Password', 'Create User Self Servic', 'User Deleted' are available and custom templates can be defined and used to send notifications out of OIM.

OIM provides a notification framework based on events, notification templates and template resolver. They are defined as follows:
  • Events are defined in a XML file and must be loaded into MDS database in order to be available for use.
  • Notification templates are defined through OIM advance administration console. The template contains the text and the substitution 'variables' that will be substituted by the data provided by the template resolver. Templates support HTML and text based emails and multiple languages.
  • Template resolver is a Java class that is responsible for providing the data to be used to parse the template, it must be deployed as an OIM plugin. The data provided by the resolver class will be used by OIM in the template substitution variables.
The main steps for defining custom notifications in OIM are:

  1. Define the Event that will be used for triggering the notification
  2. Define the Template to be formatted and sent
  3. Create the Template Resolver class
  4. Trigger the event from the relevant spot in OIM

This post explain each of the steps above and give some tips on how to create the notifications.

Monday, July 18, 2011

5 Minutes or less: Kerberos

Every time I talk to someone about Kerberos I need to take a few minutes to go through the concepts. This post is intended to just write down what I usually say and draw with a white board.

If you want to know more about Kerberos there's a metric ton of info out there on the internet. I'll leave it to you to go read up. For those of you that are experts on Kerberos please note that I'm going to simplify some stuff and gloss over a few important things; don't judge me for that - I'm just trying to make this all easy to understand!

A Kerberos Domain can be thought of as an island of single sign-on. Anything in the domain can authenticate securely to anything else in the domain without ever transmitting a clear text password over the network.

Everything in Kerberos is a Principal - machines, services and even users. A Principal is identified by a simple string called a Service Principal Name or SPN in one of two forms - either PROTOCOL/hostname for services (e.g. HTTP/ for a web server) or username@DOMAIN for users (e.g. cjohnson@ATEAMDEMO.COM). The case of the string is important; the Protocol and domain name are always in CAPITAL LETTERS and the hostname and username are always in lower case.

There's a service on the network called a Key Distribution Center, abbreviated to KDC. The KDC has a list of every user and every service on the network and has a secret keys for each and every one of those Principals.

When a Service enrolls with the KDS the KDC generates a secret key for the service. That secret key is stored in two places - on the KDC and by the service (usually in a file).

When a user first logs in they use their password to the KDC prove their identity and get something called a Ticket Granting Ticket, abbreviated to TGT. Note that the password is never actually sent over the wire.

When a user wants to authenticate to a Service they go to the KDC and use their TGT to ask for a Service Ticket (ST) to talk to that service. The user asks for a ST for a particular service identified by the service's Service Principal Name (PROTOCOL/hostname). Note that, as usual, the user doesn't actually send the TGT to the KDC. Instead the client uses the TGT to prove its identity to the KDC, just as it did with the password.

In order to construct a Service Ticket the KDC takes the username, the service's SPN, a timestamp and a couple of other bits of information, puts them all together in a particular way and then encrypts that data with the Service's secret key and adds on some unencrypted data describing the ticket. Remember that only two things know that secret key - the KDC and the Service itself.

The KDC then securely returns the ST to the user.

Finally, the user sends their service ticket to the Service. To verify the Service Ticket the Service takes the encrypted ticket and tries to decrypt it using the secret key it got when it enrolled with the KDC. If the the ST decrypts correctly with that key then the service knows that the user was authenticated by the KDC; all the that remains is to check the timestamp and other information to make sure that the ticket isn't expired. If all of that checks out then the user is considered authenticated.

You'll note that the Service does not need to go to the KDC to verify the Service Ticket - all it needs is its Secret Key which it already has.

Here's a sequence diagram for you.

Remember when I said I was glossing over or simplifying a few things?

One of those things is how the Service gets its secret key. In my text above I said it gets that key when it "enrolls", but in the diagram I used the word "start" instead. That's one of those hand wavey places.

Another one is the TGT. A TGT is just a ST for the KDC itself. So if you look at a TGT you'll see that it's a special Service Ticket for krbtgt/DOMAIN.COM@DOMAIN.COM. For example here's mine:

Ticket cache: FILE:cjohnson.cache
Default principal: cjohnson@ATEAMDEMO.COM

Valid starting     Expires            Service principal
07/18/11 07:51:14  07/18/11 17:51:19  krbtgt/ATEAMDEMO.COM@ATEAMDEMO.COM
        renew until 07/19/11 07:51:14, Flags: RIA

Most of our posts here are pretty long and can take a while to digest. This one is intended to be read in 5 minutes or less. If you'd like to see more "5 minutes or less" posts please let us know in the comments below. If you DON'T want to see more of them please let us know that too.

Note: we may not publish the comments, but we promise to read them all.

Thursday, July 7, 2011

Enterprise Gateway (OEG) External Service Calls

I’ve had the opportunity recently to work with the Oracle Enterprise Gateway (OEG) for a DoD opportunity. For those that aren’t familiar, OEG is an OEM from Vordel. The definitive blog on Vordel is at where our old friend Josh Bregman writes. There were a couple of patterns that emerged in my work that I wanted to post.

One pattern is the need to make an external call to a service. In my case, I needed to call to an attribute sharing service (See Chris’ blog on XASP for more details on one approach for this) and a XACML PDP. Note, OEG has an embedded PDP solution using Oracle Entitlements Server (OES) that provides a faster service, but in my case, I had to stay with the standards-based solution. This is very easy to accomplish with OEG with a 3-step circuit:

The Set Message defines the parameters of the request. In my case, I have an attribute service that takes a user DN and returns specified attributes.

<SOAP-ENV:Envelope xmlns:SOAP-ENV="">


<orafed-arxs:AttributeRequest xmlns:orafed-arxs="" TargetIDP="SpaceFenceIDP">


<orafed-arxs:Attribute Name="mail"/>

<orafed-arxs:Attribute Name="clearance"/>




Notice the wildcards with ${variable}. These were attained earlier in the circuit with a “Retrieve from Directory Server” node after authentication to the Gateway. In the Policy Editor, create a policy and drag the Set Message onto the easel. Enter “text/xml” for the Content-type and optimally, import the request from a file, then save.

Setting the URL is very straightforward, just enter the URL and any trust certificates if necessary.

The response from the attribute service (Oracle Identity Federation in this case) is:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="">


<orafed-arxs:AttributeResponse CacheFor="1499" xmlns:orafed-arxs="">


<orafed-arxs:Subject>cn=Jane Wilson,ou=CDC,dc=service,dc=mil</orafed-arxs:Subject>

<orafed-arxs:Attribute Name="mail">



<orafed-arxs:Attribute Name="businessCategory">






Knowing this response format will help in parsing the response in OEG. When editing “Retrieve from Message”, re-name the node appropriately and select “Add” under the attribute location.

Name the attribute (arbitrary) and select magic wand button. Browse to the response file saved on disk, and you should see the contents in the XPATH Wizard. Select the node which you wish to have returned to the gateway.

Select “Use this path” and the XPath Expression should show up in the XPath field. Select OK. Name the attribute you want to populate in the gateway and save the node.

Debugging on OEG typically consists of adding a “Trace” node to your circuit and putting the listener in DEBUG or DATA mode. This gives you the “System.out” visibility into what’s going on in the Gateway.

Thanks to Dave Roberts from Vordel for getting me over the humps and for stealing second in 2004.