Multiple Identity Providers with Oracle Identity Federation and Access Manager as Service Provider

Whew, that’s a mouthful for a title, but IdP N..1 SP [OIF+OAM] was probably too cryptic. Let me describe the use-case in a little more detail. Imagine if you will an education application that the state wants to surface to the various school districts. The districts want to manage user accounts and federate into the state’s application. In order to consolidate policy enforcement for both internal and external users, the state needs a single point of entry controlled by an access control system.

The documentation for Oracle Access Manager (OAM) and Oracle Identity Federation (OIF) integration on the service provider (SP) (http://docs.oracle.com/cd/E21764_01/doc.1111/e15740/oif.htm#CACJDDGE) implies that this can only be done with a single identity provider (IdP). By setting OIFScheme as the authentication scheme for the application, OAM can redirect to the service provider on OIF, which will trigger an SP-initiated Single Sign-On (SSO). There is no way to declare which IdP to use in this scenario, however. Thus, a different trigger mechanism is required for the multiple IdP scenario, plus we need to account for internal state users as well. One approach is to leverage OAM form authentication with hyperlinks to an IdP discovery page, or static links to each campus trigger for SP-initiated SSO. The format in OIF for this is http(s)://<oif>: <oif_port>/fed/sp/initiatesso?providerid=CAMPUS1&returnurl=<URL of destination app>. Once the IdP sends its SAML Response to the OIF service provider, OIF will make authentication & authorization request to OAM Policy Decision Point (PDP) based on the returnurl parameter. If successful, OIF will redirect client to the destination application with a token that the OAM Policy Enforcement Point (PEP) will honor.

One gotcha here is that the returnurl must be protected by the OIFScheme, not the form-based scheme used for internal users. That creates a challenge in that you essentially need two protected URLs for entry into the app, one to trigger the initial form authentication and one to map the external/federated users. If having all external users end up at the same portal site after authentication is acceptable, one can map the OIFScheme to a pseudoURL. You can then configure an OnAuthenticationSuccess redirect to the landing page. This pattern is only suitable if all external users come to the same page upon successful federation. I tried basing the federation policy on a query parameter, i.e. returnurl=/mysite?external=true, but OAM did not seem evaluate the query parameter, only the application context.

Another hitch is that I don’t think a 10g WebGate can consume the identity token set by the service provider. I haven’t tested to validate, but I suspect that only the 11g WebGate can consume the OAM_ID cookie. Thus, if you have a mixed environment, you will need an OHS 11g instance to handle external user traffic, while redirecting to other web servers only after an authentication cookie has been set.

Provisioning Users to Google Apps in Five Minutes

One exciting development (at least to me) in OIM 11.1.1.5 is the introduction of the Google Apps connector. Combine this with our existing SSO via Federation, it gives Oracle a nice lifecycle with Google Apps. Here is a quick primer on setting this up and a couple of gotchas on the docs. I wrote this a couple of months ago before the official announcement of the connector, so please correct me if there are any changes since.

There are a few 3^rd party libraries from Google required for the connector. It appears that Google has updated its libraries already from what we’ve published in the doc. If you hit the problem described in http://code.google.com/p/googleappengine/issues/detail?id=3008, you probably have a “too current” version of the Google jars.

Here’s the documentation gotcha: In section 2.2.2, there is a note that states:

“Before you run the Connector Installer, you must ensure that all third party jars must be in targetsystems-lib/googleapps-11.1.1.5.0.”

The point that is intended here is that the folder structure must match the structure of the connector that is deployed. The distribution is “Google_Apps_11.1.1.5.0”, so if you take the docs literally and don’t change the name, things won’t line up. What is happening is that OIM is packaging the necessary 3^rd party jars and importing them into the database. It’s important to get this right before installing the connector, or you get to go through a process of removing the jar from the database with scripts, repackaging, and re-importing.

Another confusing point is that the doc references the Java Connector Server. This might be a forthcoming solution, but for the time being, you can just substitute the OIM server anywhere it references the JCS. (This article didn’t have enough three letter acronyms (TLAs)).

Bottom line, what I think the packaging should be before the connector is deployed :

/Oracle_IAM1/server/ConnectorDefaultDirectory/Google_Apps_11.1.1.5.0/

/Oracle_IAM1/server/ConnectorDefaultDirectory/targetsystems-lib/Google_Apps_11.1.1.5.0/<3^rd party jars>

/Oracle_IAM1/server/lib/<3^rd party jars>

Deploying the connector from that point is standard fare. Here’s how I configured my IT Resource:

Once I assigned a resource and provisioned it, the user appeared in Google apps and I was able to SSO with that user via OIF immediately. I was also able to de-provision the user from Google by removing the resource entitlement from the user.

Using the OIF Business Process Plug-in

There are a few extension points in OIF that allow you to easily extend or tweak the product's behavior. The one you're most likely to use is the Business Process plug-in.

I recently completed a PoC where OIF was the Identity/OpenID Provider and the customer wanted to send a bunch of attributes along to the Service Provider/Relying Party. All that is out of the box behavior. What's not OOTB is that they wanted to prompt the user to fill in any values that weren't in the LDAP directory before the user was sent back to the SP/RP.

The Business Processing plug-in gives you the opportunity to do that.

Bridging federation protocols with OIF

I just wrapped up a project for a customer with a slightly odd federation use case.

On the one side was an IdP that could generate SAML assertions.
On the other side was an app that could only accept either a username+password or an OpenID.

We bridged the gap with OIF and a bit of config.

In broad strokes heres what you do...

• Install OIF
• Setup OIF as OpenID OP
• Setup OIF as a SAML Service Provider

For SP initiated:
You need to Configure OIF to use the Federation SSO proxy authn engine.

When the user reaches the OpenID enabled app the app will send the user to OIF. OIF will see that it needs to send the user to the SAML IdP and will redirect them there. The user goes to the SAML IdP, logs in and then comes back with SAML assertion. OIF consumes the assertion and generates an OpenID identity and redirects the user back to the OpenID Relying Party.

For IdP initiated:
You need to setup an SP Integration Module (abbreviated to SPIM).

The user stars out at the SAML IdP which generates a SAML assertion and sends to OIF. OIF validates the SAML Assertion and invokes the SPIM. The SPIM kicks the user into the OpenID flow and they get redirected on to the OpenID RP.

It's all actually pretty straightforward once you understand what's going on.

Exception when using an OIF Business Process Plug-in

If you write a Business Processing plug-in for Oracle Identity Federation (OIF) and follow the installation instructions in the documentation you may encounter NoClassDefFoundError looking for org.apache.commons.codec.DecoderException. Here's what that exception looks like:

java.lang.RuntimeException: javax.servlet.ServletException: java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
        at oracle.security.fed.controller.ApplicationController.processServletRequest(Unknown Source)
        at oracle.security.fed.controller.web.servlet.FederationServlet.doGet(Unknown Source)
        at oracle.security.fed.controller.web.servlet.FederationServlet.doPost(Unknown Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        Truncated. see log file for complete stacktrace
Caused By: javax.servlet.ServletException: java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
        at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:523)
        at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:253)
        at oracle.security.fed.controller.web.flow.URLContextTarget.perform(Unknown Source)
        Truncated. see log file for complete stacktrace
Caused By: java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException

This is easily fixed - just copy Oracle/Middleware/user_projects/domains/IDMDomain/servers/wls_oif1/tmp/_WL_user/oif-libs/i78h77/APP-INF/lib/commons-codec-1.2.jar to the same lib directory as your plug-in and other jars listed in the docs. PS: don't forget to copy the updated files in when you apply a patch!

Using the x.509 Attribute Sharing profile responsibly

I'm back, rested and I've had some time to think about the crazy (clever?) OVD adapter I wrote for last week's PoC. You know, the one that lets you do a search for certdn= the user's certificate DN and it makes a SOAP call over to OIF to get the user info?

I've talked to a few people internally about how this thing works and at first everyone has had the same reaction - that's kinda cool. Then we get to talking about the fine print warning:

Before you go further a warning: If you're going to try this at home make sure you test if for scalability. It's not entirely clear that this will scale up to thousands of concurrent users. OAM and OVD will easily support that, as will OIF (as both the SP and IdP). But the entire architecture relies on SOAP calls over the Internet and those are notoriously latency heavy. As a result the initial access by a user will be relatively slow and that could cause any number of issues. If a large percentage of your users visit for only a short time those problems will be worse.

Not everyone I've talked to is as concerned. At least not before seeing it run. Perhaps I'm a little more conservative about performance in large scale deployments. Or maybe I've seen one too many super clever solutions fall flat on their faces when faced with the real world. But in any case I cooked this crazy idea up and am still not convinced it's a good one.

Read on for why I'm a little gun shy.

Oracle Identity Federation (OIF) now supports OpenID 2.0

This news is a long time coming, but none-the-less, very cool. With the most recent patch set, OIF now supports OpenID 2.0.

In addition, OIF now supports “custom actions” by which you can create custom site specific operations that are executed during federated authentication at the service provider (consumer) and identity provider (producer).

You can read more about these recent OIF developments here: http://oracleaccessmanagement.blogspot.com/2011/01/openid-20-supported-by-oracle-identity.html

The documentation for configuring OIF as an OpenID identity provider can be found here: http://download.oracle.com/docs/cd/E17904_01/oim.1111/e13400/configoif.htm#BAJJDBHA

The documentation for configuring OIF as an OpenID service provider can be found here: http://download.oracle.com/docs/cd/E17904_01/oim.1111/e13400/configoif.htm#BAJGABBG

The chapter on custom actions can be found here: http://download.oracle.com/docs/cd/E17904_01/oim.1111/e13400/ppplugin.htm#BAJCEHIH

Edit:  Looks like I posted right after Alex did an excellent post on OAM/OES integration.  If you missed his post check it out here: http://fusionsecurity.blogspot.com/2011/01/custom-identity-assertion-for-oam-oes.html

My first custom OVD adapter

For a PoC I have been working on I wrote a (demo quality) OVD adapter that I thought might be interesting for others.

In my PoC I had OIF, OAM, OVD and DSEE and OES. In the main use case a user can come along to the SP with an x.509 certificate issued by an issuer known to the SP. The SP is expected to do the normal certificate authentication "stuff" (crypto operations, CRL & OCSP checking) and then make authorization decisions for URLs based upon the user identity including information about the user that the SP doesn't get in advance. To get that information the SP will need to make SAML attribute requests to an IdP.

Out of the box OAM and OIF support this use case via the Oracle Access Manager AuthZ Plug-in. That plug-in makes calls to OIF which in turn goes and gets the necessary attributes from the right IdP. This is great and answers most of the requirement.

The missing bit is that this customer wanted to go further... much, much further. They want to make very fine-grained authorization decisions deep down in their applications (by calling OES). And they want OES to make its decisions based on the attributes coming from the IdP.

My first plan was to write an equivalent to the OAM x.509 Attribute Sharing plug-in for OES. It should have taken me all of a couple of hours start to finish including deploying it in the PoC environment. Naturally I thought to myself "That's not all that interesting. Why don't you do something more clever?". I blame too much caffeine and inadequate sleep for that thought.

Everything in the environment (OAM, OES, WebLogic and a few other things) already make LDAP calls to get user info and make authorization decisions. Why not hide all of the SAML stuff down in OVD. Then there's only one place that needs to talk to OIF.

Click through to see what I did.

WebLogic Domain Models for Installing the Oracle Identity Management Suite – Part 2

A couple days ago I wrote what I consider to be an important post about whether different Oracle middleware packages (or bundles) should be installed together in a single domain or installed in separate domains.

I’ve received a few questions asking a logical extension of that topic which is what about the individual products within one package? Should individual products within one package be installed together in a single domain (which is really the default behavior) or be spread across several domains? For example, if you are deploying the Identity Management package with OID,OVD, and OIF, should you install them all in one domain or maybe put OIF in one domain and OID in a separate domain?

There are a number of things to consider in answering this question.

Let’s begin by looking at the issues that led me to recommend that you not install multiple packages/bundles in a single domain.

The first issue was the risk of incompatibilities between the packages and the difficulty in dealing with such issues when they arise. I would have to say that this issue does not apply to multiple products within one package. After all, the package was explicitly developed and tested with the idea that all the products would be running in same domain.

The second issue I raised was the notion that deploying multiple packages to one domain could complicate patching and upgrading; even potentially leading to a situation where you will be kept from upgrading due to version incompatibilities. Again, since we are now talking about products within one package, there is less of a concern about patching and upgrades. However, since even a single product patch could include components that are common across the entire package, having all the products from a package in a single domain means that you should really test every product that you use in the domain before deploying the patch to production. I don’t see this as being a huge deal but it is something to consider.

The next consideration which I did not address in my last post is delegation of duty or purpose for a domain. Some customers segregate certain WLS domains for certain purposes. Often this is seen as a security practice such as the case where a customer deploys all intranet apps to one domain , extranet apps to a second domain, and utility services to a third domain. If you are a customer that does this you may see some products in a package as falling in a different category from another. One example of this is that many customers will see OID and OVD as being “internal” or “utility” applications where as they might see OIF as being an “external “– end user facing application. This might lead them to deploy these applications from the Identity Management package into separate domains.

The last consideration is to note that some of the integrations between products in a package only work if the products are installed in the same domain. Two examples of this are the OAM/OIM integration and the native integration between OAM and OAAM. If you want to use the integrated functionality offered by these packages, you have to deploy them in the same WLS domain.