If your refridgerator needs to be cleaned out, everyone living with you probably knows it because the task is usually so far down on your to-do list, you might as well plan a trip to Mars first. The task moves up the list as the odor becomes worse with each door swing. Eventually it reaches crescendo when your friends, neighbors and significant other(s) can stand it no more. This is the point where the "smell" becomes the "stink" or for those of you counting yourselves as fans of Sir David Attenborough, it becomes titan arum.

Recently I've been thinking about smells in a typical Oracle Identity Manager implementation. As is true for any enterprise-grade software deployed to solve real-world problems (read: abused and exploited) there are patterns that work well and some that don't work so well.

Detecting Blue Cheese in your Oracle Identity Manager deployment:

- Encyclopedia-like User Profile (Xellerate User / USR). I've seen user profiles with as many as 50 attributes. Although this varies with context, I think 10-15 attributes is a reasonable max. If Xellerate User entity represents your "core" identity, you should not have attributes on it that are better placed with the resource/target. Regarding access policies that fire based on groups which are driven by rules that work only on Xellerate User fields, here's a hint: rules are not the only way to become a member of the group.

- Duplication of Adapters aka Copy and Paste Programming. The raison d'etre of adapter mechanism is reuse. If you spend time designing your adapters and (shock! horror!) thinking about a library of adapters just like there are class libraries and frameworks made up of class libraries in various class-friendly languages, you won't see 10 copies of AddThisStringToThatString.

- Large Adapters. Don't click yourself to death and force others to drill down on two pages worth of visual spaghetti that ends up being generated code anyway. If it's more than a screenful (and I don't mean you over there with a 52" screen), it's too much and should be refactored into smaller adapters and/or underlying code.

- Tiny Lookups. Lookups with a few records at the most, sometimes (adding insult to injury) with code (attribute) and decode (value) being the same.

- Bloated Lookups. Perhaps the most frequently encountered smell after Duplicate Adapters and JARs Everywhere. This is when a lookup contains more than 10-15 records, occasionally running into hundreds of lines. OIM can be somewhat blamed for this as there's no good alternative for persisting app-specific metadata in the database unless you want to do it in your own (separate from OIM) tables using your own method.

- Environment-Specific Data Outside of IT Resource. Environment-related data is often spotted as task attributes. In other words, the same logical data element (e.g. server hostname) is present in a number of places. Moving OIM to another environment makes this smell a lot of fun!

- JARs Everywhere.Same JAR in JavaTasks, ScheduleTask, <oim_home>/lib, app server classpath, and (for a truly good measure) a few different directories inside the JDK. Classloaders of the world, unite! You have nothing to lose but your already loaded classes.

All of the things above would work, but over time, these things will start to turn your Provisioning Perfume into something a bit more pungent.

What is your favorite (or dis-favorite) OIM smell?

I hear that the Age of Facebook is upon us. While I was busy tending to my identity and access tomatoes, the new dawn has been declared. Apparently right outside my window there be walking people whose identity has been sucked into a space-time deviation yet they're blissfully unaware of this. For those of you in the know (read: in the possession of a secret handshake), the Age of Aquarius is really where things have been happening for a while but I digress.

Astrology and social networking aside (wait, aren't they one and the same?) I think we're in the Age of Fast, Faster and Oops-Reboot-Button-Really-Works. The immediacy of content and the ease of access leads to different expectations versus those that existed merely 5-10 years ago. We want our movies streamed on demand with no network lag, our books in some digital iFormat, our identities to be portable yet private, our chicken wings to taste like 5-star French restuarant fare..

Who's to blame for this massive shift of the entitlement scale? I would like to blame the aliens but those folks at SETI are awuflly slow so I will blame Google. To be more exact, I will blame it on their unwavering belief that a simple search box can yield the answers to just about anything. Once they had consumers convinced, they started replicating the idea everywhere. Notably in GMail one can find emails by combining a few simple and easy to remember operators. For example, to find all messages sent to you from anyone at identigral.com with an attachment, you could enter from:*@identigral.com has:attachment into the search field and voila, you're showered with text.

Now transport yourself back to the land of identity management. A typical IAM application is a bunch of tomatoes on top of a large database (LDAP is only a protocol, don't fool yourself). The content in the repository has a lot of value but only when it's appropriately harvested, extracted and made available in a cupcake format. If there ever was an enterprise application ripe for a pervasive search-as-an-interface-to-everything disruption, IAM is it.

Have you ever had to run a report in your identity or access management tool? Say, give me all users who have been provisioned to Active Directory in the last week. Given a reporting requirement of any sizeable complexity the implementation task would end up being either a nasty SQL query directly to the database or a mini-marathon with a reporting solution.

Enter Scroogle (pronounced SCROO-gul), a kinder, gentler and an entirely textual solution to the reporting problem. Scroogle is a search engine that would be embedded into an identity or access management product. Instead of fiddling with reporting knobs or trying to decide between left and right outer join (both are charities for circus acrobats if you ask me), one would use a very compact domain-specific language a la GMail operators to get results. For example, the Active Directory report above might look like has:AD status:Provisioned when:last week. Right now Scroogle is a figment of my imagination but I am sure IAM product vendors reading this blog will take notice and "borrow" my idea. All I ask in exchange is a six-figure royalty check paid in gold bullion.

P.S. Scroogle is actually a very real and useful ad-free Google proxy service

On Tuesday March 2nd we'll be hosting a happy hour at a suitably trendy location within walking distance of Moscone. Come have a drink with us!

To make this a truly exciting evening, we'll be holding a contest for FREE consulting time where the winning organization will be treated to a 2-hour health check of their current or planned identity and access management implementation. To be eligible for the contest you will not have to come up with an alternative proof of the Fermat theorem or jump through rings of fire or spell your name backwards faster than a 5th grader. In fact, all you have to do to qualify is register, show up and put your name in the hat.

There was a jolly man named St. Nick
Who didn't know which IDM stack to pick
By the yule log
He read our blog
That well-rounded cheeky man named St. Nick

Happy Holidays!

More coverage of Oracle IAM 11g suite based on OpenWorld sessions. If Oracle Identity Manager 11g is an evolutionary step and Oracle Identity Analytics 11g is fresh air then OAM 11g is a shot heard round the world. Changes, they're a comin'.

The current release of Oracle Access Manager is based on the 2005 acquisition of Oblix. The Oblix product is written in C++ and is comprised of a number of independent components that all function, well, independently! In the late 90s-early 00s world of enterprise applications where CORBA was still considered a viable deployment option, J2EE was learning how to walk and .NET was yearning for acceptance, apps that could run on a particular platform without a container were still popular. Today, container-less apps are certainly still around but they're not a frequent occurrence in the enterprise landscape. Recognizing that the internal architecture of OAM was getting long in the tooth and chanting its Weblogic uber alles mantra,Oracle transmogrified Oracle Access Manager into a J2EE app.

I didn't ask whether 11g was a rewrite from scratch or a port of C++ codebase to Java; if I had to guess, I'd say the latter. Regardless of how the guts were engineered, the access management UI in 11g reflects the same asset taxonomy as the current 10g release. There are webgates, resources, resource types, host identifiers, policy domains (renamed to application domains), authentication and authorization schemes, and so on. Conceptually, the OAM policy universe and (broadly speaking) its access management pieces are still in place. The identity side of OAM is no longer there, it's been subsumed by OIM. No more Identity Server, funky workflow applets, IdentityXML interface and other identity-related stuff in OAM. Poof! (There are backward compatibility options available, see the end of this blog). Now OIM and OAM are clearly and cleanly separated, there's no longer any sizeable overlap between two products. Identity Administration is in the top drawer (OIM), Access Management is in the bottom drawer (OAM). (Why does OIM get the top drawer? This must be my subconscious speaking).

Being a J2EE app gives OAM a number of immediate advantages, the first and foremost being the ability to reuse a large swath of Oracle J2EE tech. The distributed cache housing stateful sessions is courtesy Coherence (ex-Tangosol), the UI is based on Oracle's Application Development Framework (ADF), the app server is obviously Weblogic with rock-solid J2EE app hosting/management features. When you align your products with your platform strategy, not only technology can be reused at a product level but a lot of development effort can be cross-sourced and shared. This goes for both internal Oracle development effort as well as effort expended by customers when customizing Oracle products. The knowledge gained when learning how to customize UI via ADF in OIM should carry over to OAM and to other Oracle products. Same goes for Weblogic and other pieces. Wunderbar!

Aside from JEEification of OAM, there have been a number of other significant changes and enhancements in 11g:

LDAP scoped to authN scheme is a nice enhancement, it allows for authentication against different directories, e.g. internal users against Active Directory and external users against, say, Oracle Internet Directory (OID). It's worth noting that segmenting user population and authenticating these segments against different directories is possible in OAM 10g with Oracle Virtual Directory (OVD). In general, we recommend that OVD is deployed alongside OAM. OVD is an elegant solution for a number of issues having to do with heterogeneous identity stores (directories, databases, Toys R Us) and by using OVD you automatically become part of the COOL crowd.

Agents are an interesting story. As y'all know, today Oracle ships two identity management stacks - a legacy stack based on Oracle App Server and the "current" stack with OIM, OAM et al. In the legacy stack, web SSO is engineered in a manner somewhat similar to OAM in that there's a front-end component that plugs into the web server and intercepts requests. In the legacy stack the web server is Oracle HTTP Server (OHS) that is based on Apache. Apache plugins are called modules and prefixed with mod, thus mod_osso. Despite being a few generations behind the curve, the legacy stack features prominently in one area: as an SSO solution for Oracle's e-Business Suite (aka Oracle ERP). Even though one can deploy OAM together with legacy SSO (OSSO) and hide OSSO behind OAM, you still need OSSO underneath the hood. Oracle ERP isn't the only product where OSSO is deployed, there are others but ERP deployments with OSSO is where the impact will be the greatest.

In 11g, Oracle wants to (finally!) kill the legacy identity management solution. If this was done as a straightforward hatchet job (no more mod_osso, migrate or die), Oracle ERP customers with OSSO would have screamed so there is a soft landing. OAM 11g will support three types of agents that intercept requests and forward them onto OAM for access decisions: "traditional" access gates (a webgate is a pre-fabricated access gate) from OAM 10g, same from 11g and mod_osso.

Sessions are now stateful. This is a huge change which has tremendous performance repercussions. When OAM starts an SSO session on the user's behalf, it will keep track of the conversational state between OAM and the user, i.e. there will be a concrete chunk of memory on the server that knows about you. Stateful sessions are highly problematic when it comes to scaling an application to higher transaction volumes. Oracle's solution to scaling with stateful sessions is embedding Coherence into OAM, an industrial strength distributed cache acquired from Tangosol. One of Identigral's partners spent part of his misbegotten youth working with various caches and he says Coherence as a session cache can certainly handle just about any kind of load but tuning the distributed cache is akin to black magic. (I must mention that Identigral has certified black magic experts. We know voodoo!) .

One benefit of stateful sessions is that use cases such as "login is allowed only from a single location" (think Yahoo Messenger) or "maximum number of concurrent sessions" can be implemented out of the box. The long-term vision for stateful sessions is to allow the session to be exposed to other Oracle IAM products, notably Oracle Identity Federation (OIF) that could populate the session with their own attributes. If so, OAM could then use these "foreign" attributes to make authorization decisions. This is a lightweight example of data virtualization at the session level (front-end) versus data virtualization at the directory level via Oracle Virtual Directory (back-end).

The policy model change from a default of "allow all" to "deny all" is to be applauded. If you have OAM and your default is allow all, I highly recommend changing it to a deny.

One of the more welcome changes dragged in by the new UI is the introduction of a built-in mechanism for promoting assets across environments, e.g. from Test to Production, a niche previously (and temporarily) occupied by OAM Configuration Manager (OAMCM). Oracle also promised an ability to templatize environments so that topology "definitions" can be reused in different promotion contexts. Along with that a mention was made of incremental promotion of policy changes. Anything that helps with a promotion of assets in a controllable fashion is good in my book.

If you squint at the architecture diagram, you'll notice a Token Processing component. I interpret this as a Security Token Service (STS), a future capability. No mention of that was made during OpenWorld session but I wouldn't be surprised if the STS that ships with Sun's OpenSSO served as the inspiration or basis for Oracle's implementation. The beauty (and weakness) of Open Source... Squinting at the OAM portion of product strategy diagram in the OIM 11g blog entry, I also noticed that OAM box contains services that are now represented by separate products. I take this as an indication that all of these currently separate products - OIF (federation), OAAM (adaptive access / strong authentication), OES (fine-grained authorization) will become services/modules that are part of a single OAM product. Smells like OpenSSO to me! In my Suncle access management blog entry, I said that I don't see this convergence happening at Oracle but I may have been wrong. (My time machine ran out of gas...). There are pros and cons to both approaches; sooner or later we shall see what OAM will have become. As for the rest of OpenSSO vs OAM debate, I stand by my initial assessment.

During the Q&A portion of the session, a number of questions were asked about "..but what about X" where X was custom plugins, IdentityXML, identity workflows and more. Front-end agents aside, I did not fully understand how backward compatibility with OAM 10g is supposed to work but something to the effect of "OAM 10g and 11g can coexist and run side-by-side" was discussed. The coexistence strategy was represented by the following diagram:

The OAM release plan is spread across multiple 11g waves (my term). OAM 11gR1 will target feature parity with legacy Oracle SSO stack and supporting mod_osso agents. If you want to rip out legacy stuff, 11gR1 is your ticket. 11gR2 is supposed to provide for feature parity with OAM 10g agents and deal with coexistence of 10g/11g services. 11gR3 will be convergence of R1 and R2 into a nice and shiny product. As is true for other 11g products, the only release date made available was "somewhere in calendar year 2010".