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.

Samplecode is moving

The Oracle Sample Code site (samplecode.oracle.com) where we've published our samples over the past few years is being decomissioned:

IMPORTANT: This site will be decommissioned on Oct. 28, 2011. Please move your projects to alternative platforms before that date.

We have already downloaded the code and will move the following projects elsewhere at some point in the future:

• mutlirealm-authentication
• oes-jboss
• oes-spring
• oes-sspi-providers
• oes-ucm
• opss_sample_code
• owsm-11g-custom-assertions
• sample-identity-asserters

If you need the code in the meantime please let us know.

Why am I seeing SIGSEGV when I strace a Java application on Linux?!

A customer recently used strace on a WebLogic server that was having some trouble. The first thing that jumped out at them was hundreds of SIGSEGV, also known as Segmentation Fault, events showed up in the output. They opened a support incident and asked for more information on what might be causing all of those segmentation faults.

Most people that have used Unix for any amount of time are familiar with occasionally seeing "Segmentation Fault (core dumped)" from poorly written programs. If that's all you knew about Unix and you looked at the output of strace on a Java process you'd think something was seriously wrong ("Wow, look at all these segfaults. Those guys at Sun/Oracle must be terrible programmers and they don't know what the hell they're doing!").

The real story is quite different - SIGSEGV in a Java process is almost always perfectly normal and completely safe.

Why?

The “reassociation” business

Since Fusion Middleware 11.1.1.4, OPSS (Oracle Platform Security Services) support 3 types of security stores: file, OID (Oracle Internet Directory) and Oracle database. When a Weblogic server domain is first created, OPSS is “associated” to a file-based security store by default, which is ok for development purposes. But for production, that is not recommended (Please check Multiple Nodes Servers Environments section in OPSS docs). That would be ok if your whole environment is a single Weblogic domain with only one server in a single machine. But 99,99% of the cases are not like that. Usually, an SOA or WebCenter environment is composed of multiple servers in clusters spread across different machines. A file-based security store is not a scalable option. In these cases, you should look at OID or the database. Fusion Applications, a gigantic set of apps, adopt OID as the security store.

The OPSS security store is a composite of policies, credentials, keys and audit services. Notice that I am leaving the identity store service out. OPSS delegates the identity store service to the identity providers configured in WebLogic server.

As a side note, OPSS is not a product, but a set of security services used by Fusion Middleware. If you’re a Fusion Middleware user, trying to understand OPSS is a great idea.

This post is about the nitty-gritty details of configuring (or reassociating) a Weblogic server domain (or multiple domains) to a different type of security store. That’s where the term “reassociation” comes from.

The information presented here is a small subset, but complements and sometimes overlaps “Configuring OPSS Security Store” documentation (reading is strongly recommended).
Before going any further on reassociation, let me talk a bit about an important character: jps-config.xml.

jps-config.xml

This is the OPSS file that describes all its services. It is located through the –Doracle.security.jps.config system property, which is set in setDomainEnv.sh script in a standard JRF (Java Required Files) domain. By the default, the property points to ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml and it is defined in the variable EXTRA_JAVA_PROPERTIES. It is NOT a good idea to change it, since jps-config.xml holds several relative references to other files.

OIM 11g Localization Tips

As any other enterprise application, OIM 11g provides localization features: it detects user's browser language configuration and presents the UI to the end user accordingly to the configured language.
Customers can plug a lot of custom code and objects in OIM 11g in order to achieve their business requirements. While some customers don't care about localization, some of them do care, and this post gives tips on how to localize some pieces of OIM.

It is important to mention that this post does not show how to create custom fields (UDFs) or how to change request data sets.

The examples below use Brazilian Portuguese as the localization language. For other languages, check the other resource bundle files available in the exactly same folders.

Connector Request Dataset

The request data set field labels can be localized for any OIM connector deployed. The localized labels will show up when a user creates a request for that specific resource.

To localize a request data set, follow the steps below:

• Edit the file $OIM_HOME/server/server/customResources/customResources_pt_BR.properties
• Add the localization properties following the convention below:
• request.dataset.Resource.<Resource Name>.<Attr Name>
• Restart OIM Server

Notice that the property to be added to the properties file has to follow the naming convention described above. If the <Resource Name> or <Attribute Name> contains space, you must escape it like in "OID\ User".

Virtual Users in OIF, Weblogic and OWSM

One of the main strengths of SAML is the ability to communicate identity information across security domains that do not necessarily share the same user base. In other words, the authenticated user in one security domain does not necessarily exist in the target security domain providing the service.

Such concept is supported in all major Oracle products that consume SAML tokens: OIF, Weblogic Server and OWSM. The sole purpose of this post is to show how to configure it in these products. Setting up SAML services as a whole involves more than what’s showed here and I recommend the official product documentation for detailed steps.

I hope this can be helpful to someone out there.

OIF (Oracle Identity Federation)

OIF enables federated single sign on for users behind a web browser.

It calls the aforementioned concept “Transient Federation” and enables it via a checkbox (that should be unchecked) in Enterprise Manager OIF’s Console. Notice it also supports the concept of a "Mapped Federation", where the incoming identity is mapped to some generic user in the local identity store. But here I am talking about the case where there's no mapping. The user in the SAML assertion is simply trusted.

In order to enable a Transient Federation in OIF, simply make sure “Map Assertion to User Account” checkbox is unchecked in the Service Provider Common tab.

Weblogic Server

Weblogic server provides SAML services that can be leveraged by Web SSO as well web services.
Weblogic calls the concept Virtual Users and implements it in its SAML2IdentityAsserter along with the SAMLAuthenticator.

First, you need to enable your server as a SAML Service Provider. Notice this is done at the server level. Go to Environment –> servers –> <Pick server from list> to get into the screen below:



Then add a SAML2IdentityAsserter to the authentication providers list and add an Identity Provider (who does not need to be another Weblogic server) Partner to SAML2IdentityAsserter. Notice that you can add either a Web SSO partner provider or a Web service partner provider. In the case of Web SSO, Weblogic Console will ask you for the partner metadata file.

Understanding OAM Authentication Schemes, Modules, Step Orchestration, and Plug-ins

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.

I've been working on a post about plugging your own code into Oracle Access Manager (OAM) to "do" user authentication. Before I get to that post I thought it would be a good idea to explain all of stuff between when OAM collects a credential (for example a username and password entered on an HTML form) to establishing an authenticated session.

In OAM 11g the whole authentication flow from credential collection through session establishment is configurable by you the administrator, 99% of the time without needing to write a single line of code or by scripting anything. Out of the box OAM 11g ships with a bunch of sensible Authentication Schemes prewired for you which you can change or adjust to suit your needs. OAM also allows you to add additional Schemes or even upload your own code to do authentication your own special way.

To help you understand the process and terminology I'm going to start at the bottom and work my way up.

The lowest level component of the process is an Authentication Plug-in. An Authentication Plug-in encapsulates a single chunk of work, for example looking up a user based on their username, or checking the user's password against an LDAP directory.

Each plug-in does one very small thing, so you string some set of Authentication Plug-ins together to create an Authentication Module. The Authentication Module allows you to select one or more Authentication Plug-ins, each of which becomes a "Step". Then you configure Step Orchestration which is where you tell OAM which order to call those steps and what to do if each of those steps succeeds or fails.

For example the LDAP Authentication Module (the one used when you enter a username and password) has two steps:

StepUI is an abbreviation for User Identification (not User Interface!)
StepUA is an abbreviation for User Authentication.

And they are Orchestrated so that StepUI goes first and if that succeeds then StepUA follows. Here's what that looks like in the GUI:

Since a picture is worth a thousand words let's translate that into a flow chart:

OK, so what do we have so far?

A Plug-in does some work.
A Mechanism strings those Plug-ins together as steps and defines how they work together.
All that's left is a way to actually get the credentials from the user. To do that you have to define an Authentication Scheme. An Authentication Scheme has a few settings:

• Name and description
• Authentication Level - a number used to sort the schemes in order of most secure to least secure
• Challenge method - what kind of credentials and how does OAM collect them?
• Authentication Module - which authentication module is used to authenticate the credentials?
• a few other scheme-specific fields

This is what the Authentication Scheme looks like for LDAP:

And that's it!

When a user tries to access something protected with this scheme they'll have to enter their username and password into an HTML form. That data goes into OAM which calls the User Identification plug-in to locate the user in the directory, then the User Authentication plug-in to check their password against the one in the directory. If both of those steps succeed then they get an authentication session (for their DN) with a level 2.

I tried to draw a picture showing the relationship between these constructs. This is the best I could do:

Did this help?