Identigral, Inc. - Identity and Access Management Experts

A Hybrid Identity Management (IdM) Migration Approach

Xiaofang Chen — Sat, 14 Apr 2012 01:19:16 +0000

I see an Oracle Waveset Identity Manager (previously Sun Identity Manager) Migration project as a cooking challenge where you need to recreate a given dish in a particular time frame. You are going to be using different tools and techniques in your reconstruction but it has to resemble the taste and look-and-feel of the original dish. I could guarantee that almost everyone knows how to approach the challenge. First you carefully observe the original dish by tasting and feeling its texture, then identify the individual ingredients, and finally design a recipe by choosing the right tools and applying appropriate techniques. Your satisfaction with tasting the final product might vary but we are able to have the approach nailed down. I wish choosing the right IdM Migration approach could be as simple!

Let me explain what I mean. Some companies we know view the Migration effort of their Sun IdM solution as another infrastructure application upgrade. Their approach is driven by the Migration Toolkit released by the vendor (Oracle). We call this approach “Migration by Objects” since the list of various resources / components / assets inside the Sun tool is generated by the Vendor Migration Toolkit, then analyzed and migrated. The problem of this bottom-up approach is similar to the problem of recreating the original dish by starting with the list of ingredients. The overall taste and feel (i.e. business requirements) might be lost during such "translation". Consider the following situations:

There are duplicate solutions implemented in the existing Sun IdM implementation (e.g. manual vs. scheduled) due to historical reasons. Only one of them needs to be migrated
There are existing objects (e.g. workflows, reports) that are never referenced/used in current system
There are obvious improvement opportunities in certain areas of business processes
There is existing customization that could be easily replaced by the latest advancement in Identity Management (e.g. customized java classes vs. Out-Of-Box Password Synchronization Adapter)

The opposite of “Migration by Objects” approach is to focus on re-designing the new system based on business requirements and processes. We call this approach “Migration by Use Cases”. The potential risk of this approach is overlooking functionality details and not fully leveraging the existing implementation. This is similar as to recreating the original dish without analyzing the detailed ingredients. Imagine realizing the end product is missing some key ingredients after the solution is delivered.

What we need is a well-balanced hybrid Top-Down (“Migration by Use Cases”) and Bottom-Up (“Migration by Objects”) approach. Overlooking one or the other introduces risks to the success of Migration. Unfortunately, most of Sun IdM Migration tools in the market nowadays are designed to facilitate the Bottom-Up (“Migration by Objects”) approach. They could be used to generate a catalog of existing Identity Objects and even to auto-migrate some simple objects (e.g. users, security objects) onto a particular Identity Management platform. But they fail to provide information from the perspectives of business processes/use cases.

Thus we, Identigral, have created our own Sun IdM Migration Toolkit to facilitate a hybrid Top-Down (“Migration by Use Cases”) and Bottom-Up (“Migration by Objects”) approach. This Toolkit could be used to auto-discover use cases by analyzing the implementation objects (e.g. Java class, XML objects) in an Identity Management solution repository. It fills the gap missing in other IdM Migration tools by establishing the connection between the business view and the underlying implementation. We have started applying this Toolkit in our current Sun IdM Migration projects and have received positive feedback from clients after seeing how much value it brings. Feel free to contact us if you want to learn more about the Toolkit. And stay tuned -- this toolkit will soon be available for OIM 10g Migration projects as well.

Doraemon to the Rescue

Xiaofang Chen — Mon, 20 Jun 2011 00:35:00 +0000

Doraemon - you’ve seen him even if you don’t know his name, the cutest robotic cat from the future! He was my favorite cartoon character when growing up and he's going to help us today.

When attempting to visualize this (magic) migration tool from Oracle Waveset/Sun Identity Manager to Oracle Identity Manager 11g, (see previous blog entry "Grown Kittens Need a New Home"), I can’t help but to think of Doraemon. He has a 4-dimensional pocket from which he produces gadgets and tools from the future. The Take-copter (a propeller which can be attached to anything to enable flight) is my all-time favorite. So what will come out of Doraemon’s pocket if his next mission is to migrate a solution based on Waveset/Sun Identity Manager to Oracle Identity Manager?

Recently I had a chance to take a closer look at the to-be-released Sun Identity Manager/Oracle Waveset (SIM/OW) to Oracle Identity Manager (OIM) migration toolkit. Here are highlights of what I have learned.

1. OW objects that can be directly mapped to their equivalents in OIM. These will be automatically or partially migrated
Not too many surprises here. A good portion of OW objects could find direct mappings in OIM:
- Enterprise Identity Data Objects (e.g. Organization, Role, User, and Resource)
- Schema Templates and Policy Objects (e.g. IDM Schema Configuration, Email Templates, and Password Policy)
- Administration and Authorization Objects (e.g. Capabilities and Admin Roles)
- Business Logic and Process Data Objects (e.g. Process/Object Forms)

But not all features of these objects could be directly mapped to OIM. For example, dynamic variables in OW Email Templates need to be manually configured in OIM once these templates are automatically migrated. How much these OW features are used in your OW/SIM implementation will determine the amount of automatic translation that could happen.

2. OW objects with no direct equivalent in OIM. There will be a report capturing these objects and they will require manual migration
Again, this is what we expected. As a general rule of thumb, any customized XPRESS scripting will likely require re-implementation. The migration toolkit will not be able to translate XPRESS logic into SOA composites or OIM adapters or Java code underlying adapters. User Interfaces and Workflows fall into this category.

3. Audit trail / historical data. These records will not be automatically migrated
As OW and OIM employ different schema for persistence of audit records, Oracle advises customers to follow a co-existence strategy. In this approach, audit artifacts would be generated from either OW, OIM or both depending on context / need.

4. Identity Connector framework will be leveraged by the migration toolkit
Oracle plans to build both OW and OIM resource connectors on top of the new Identity Connector Framework (ICF). It’s already available to OW customers as long as they upgrade their installation to 8.1.x. This not only enables them to leverage new features and enjoy updates to the connectors provided by Oracle but also unifies the underlying infrastructure for a seamless transition by the migration toolkit.

Overall, the OW to OIM migration toolkit by Oracle is a respectable attempt at automating the migration tasks. It pays attention to details regarding product differences and focuses on identifying customizations that require manual effort to migrate. For example, the toolkit takes care of passwords and challenge questions/answers when migrating OW users such that end users won’t need to reset passwords or re-enter their challenge answers in OIM.

On the other hand, no magic tool could solve real life problems in a quick and easy way. (This was one of the lessons taught in Doraemon’s stories). Take “User Termination” use case from our previous example. The pre-migration analysis produced by the toolkit (third column in the table below) needs to be reviewed by subject-matter experts who understand both the product and the business process the product implements so as to come up with an accurate estimate of the migration effort (fourth column in below table).

And that’s how we, Identigral, are able to help. Our team combines leading expertise in various Identity Management products (especially Sun Identity Manager/Oracle Waveset and OIM) with a proven track-record for successfully delivering and migrating Identity Management solutions. Feel free to contact us if you're interested in having Identigral help you by bringing proven methodology, best-of-breed migration tools and extensive knowledge base.

Grown Kittens Need a New Home

Xiaofang Chen — Tue, 31 May 2011 00:18:00 +0000

When Oracle announced that “Oracle Identity Manager will be the strategic Identity Administration and Provisioning product moving forward" and with Oracle Waveset going into ‘sustain and converge’ mode, I was ready to offer all of my Waveset knowledge for adoption. Having delivered Sun Identity Manager projects all the way from when it was “Waveset Lighthouse” (Sun acquired Waveset in 2003), I am personally attached to everything I engineered on top of Waveset throughout the years. For the time I spent getting to know my Waveset customers, taking care of their needs and trying to build/customize the best home possible for the growth of their business, it’s difficult to see them become homeless. But as a person who believes in change (or sifting a sieve full of unsifted thistles), I am optimistic that it will be a change for the better and a better home is out there. Maybe.

While not all Waveset customers face the challenge of migrating their solution to a completely new platform, quite a few will consider this option. Migration is a far more complicated task than simply porting software to a different platform or deploying applications in a new runtime environment/container. Imagine migrating a very common “User Termination” use case from Oracle Waveset to Oracle Identity Manager. A typical scenario goes like this:

1) a user’s record is updated with a future termination date in company’s HR system (the authoritative source),
2) IdM system detects the update and tags the user for termination on that day,
3) when the termination day comes, IdM system automatically de-provisions user’s access in connected resources and emails appropriate parties to manually remove user’s access in non-managed resources. A simplified version of Oracle Waveset implementation might look like this.

Few objects such as Connectors could be mapped directly from Waveset into Oracle Identity Manager as the same concepts exist in both platforms. Email Templates and Task Scheduler could be migrated with minimum effort. But the majority of objects with heavy dose of business logic require significant effort to re-develop in Oracle Identity Manager. They could potentially be replaced by out-of-box and customized Process Forms, Adapters and Provisioning Processes with features split or merged from different Oracle Waveset objects. Sounds quite sticky and rightly so. In my opinion having automated tools do this re-engineering for you is certainly possible but it would be very difficult to achieve with reasonable precision and accuracy. These "translations" are really a case-by-case battle, not to mention having to ensure performance and scalability in newly generated code. Y2K tools and vendors should enter this market!

The success of migration is not determined by being able to map every single Oracle Waveset object onto its Oracle Identity Manager equivalent but rather by having the business process successfully implemented on the target platform. The termination example is a relatively simple use case. For example, if you have scenarios involving approval workflows (and most customers do have them), they add a few more layers of complexity to the picture.

Besides the migration effort itself, there are also other challenges that Oracle Waveset customers need to keep in mind when moving to a new platform:

1. A smooth operational transition
The migration effort calls for both implementation of a new solution and the operational transition. Customers of Oracle Waveset need to ensure a smooth transition while at the same time continuing to support the existing solution and even investing further to meet evolving business needs. Tall order.

2. Consider migration with improvements
Companies often choose to leverage the migration opportunity to find ways of adding new features and improving existing implementations. Some say they do this in order to streamline business processes, reduce operational costs and improve performance. Others say they do this to justify the budget. The truth is in between (and out there). Improving life while moving to a new platform is even a taller order.

3. Select the right implementation partner
Due to the nature of work and above challenges, migration projects call for professional business planning and execution, subject matter expertise and deep product knowledge. To have a well-designed plan and resources from the right implementation partner with both old and new product knowledge is the key to success. (Our supercomputers borrowed from the National Security Agency) tell us that you, dear reader, might be interested in hiring us to hep you with migration. Kittens are optional).

There is no rush to take on the migration, but it’s never too early to start planning. Now is the time to know your options. It's also interesting to widen the scope of inquiry a bit and take a look at the latest advancements in Identity Management marketplace. To help you get started, we will review some of the available migration tools and discuss best practices of pre-migration preparation. Stay tuned.

The Blue Cheese Effect

Deborah Volk — Thu, 03 Jun 2010 22:01:00 +0000

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.

Back in the 1990s, Kent Beck coined the term "code smell" to refer to symptoms in code that could point to a deeper underlying problem. Typically these symptoms don't break the code and they work, but over time the "smell" can become a "stink". Since Kent, developers have been documenting "code smells" for different languages, contexts, and methodologies. And like any smell, what is perfume to one is blue cheese to another.

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, /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?

The Age of Scroogle

Deborah Volk — Wed, 28 Apr 2010 23:27:00 +0000

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

Holiday Pundemonium

Deborah Volk — Thu, 24 Dec 2009 11:45:00 +0000

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!

Oracle Access Manager 11g

Deborah Volk — Wed, 21 Oct 2009 18:18:00 +0000

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".

Oracle Identity Analytics 11g

Deborah Volk — Mon, 19 Oct 2009 23:40:00 +0000

UPDATE (Feb 2010): The product described in this post is dead. Sun Role Manager has been renamed to Oracle Identity Analytics and the end result is NOT the same as the product announced at OpenWorld. Stay tuned for more details in another blog post.

------

Another session at Oracle OpenWorld I attended was for Oracle Identity Analytics (OIA), a new product Oracle built from existing parts for 11g. The product was first announced in early summer of 2009 but if you were reading Oracle tea leaves, you knew about it even before that.

Oracle Identity Analytics is a "classic" BI solution circa 2009 with features specific to identity and access universe sprinkled throughout. Oracle calls it a "unique, BI-centric approach" to identity and audit compliance. The ingredients of this cake are:

1) a slick BI front-end (thank you, Oracle BI suite)
2) a data warehouse (read: Oracle database optimized for reporting and analysis)
3) a way to extract and transform data from various sources for loading into OIA (thank you, Oracle Data Integrator)
4) a way to make sense of the data and discover hidden patterns (thank you, Oracle Data Mining)
5) tight(er) integration with neighbor products in the IAM suite, namely Oracle Identity Manager

Functionally OIA is a mashup of three slices: reporting, analytics and attestation. Segregation of duties is also part of OIA and it could be considered a fourth slice but let's pretend it's part of analytics. (If we wanted to be classification purists, we'd note that reporting is also an analytical feature, usually referred to as descriptive analytics. Attestation, on the other hand, doesn't fit as neatly into an analytics sandbox). A picture is worth (less than) a thousand words in the previous paragraph:

Reporting, analytics and attestation deliver on challenges surfaced in Governance and Risk areas of IT. Is OIA then a GRC product? Well, it's 2/3 of one! If you consider attestation a compensating control, then one could say it's a narrowly defined GRC solution. Furthermore, OIA took over role mining and some other features of Oracle Role Manager (ORM) that were left on the floor after identity administration aspects of ORM were surgically removed and donated to Oracle Identity Manager 11g.

From the reporting perspective, OIA's raison d'etre is easy to grasp. All Oracle IAM products have reporting features yet reporting on identity or access events in a silo fashion (each product does its own thing on top of its own data store) is not the best solution. It's a good solution in that it meets the needs of many customers, especially customers who start with a particular product such as Oracle Identity Manager and may not deploy other pieces of the Oracle IAM suite. While it is true that there are single-product customers out there, it is also true that there are plenty of customers who own and deploy more than one Oracle IAM product. Comparing the number of single- vs multi-product deployments, multi-product installs win, at least this has been our experience. For customers deploying multiple Oracle IAM products the question of consolidating reports and making sense of data across products is a very real one.

Oracle acknowledged this issue in 10g by providing for an optional consolidation of reporting across IAM stack via BI Publisher. The reporting slice of Oracle Identity Analytics is a direct evolution of this need. For an enterprise-wide take on reporting, you have to have both appropriate infrastructure (e.g. star schema, ETL tools, etc) and, more importantly, data collected from various operational stores. Having properly denormalized data from everywhere is necessary but not sufficient to be useful by itself. You need domain-specific interpretation of this data. In the IAM world, this is bubbled up via two intertwined aspects: compliance / audit and risk mitigation. In plain English: stop the auditors or regulators from fining us for having poor controls that may lead to attacks/breaches OR reduce the likelyhood of attacks/breaches so that auditors and regulators will have a chance to fine us for something else.

In the analytics context, correlation across identity and access events in various silos creates the coveted synergistic effect where 1+1 = 3. As Security and Information Event Management (SIEM) vendors will tell you, successful correlation is 80% perspiration of having to come up with rules / criteria for correlation and associated alarms (is it a malicious attacker or merely a clueless user who can't remember his password, forgot his door access code and borrowed a card key from a friend) and 20% of having the data in one place. Thus, having some pre-packaged correlation reports covering Oracle IAM suite products as data sources would be nice to have.

The mention of SIEM is not entirely accidental. Oracle Data Integrator is a general-purpose ETL tool and as such it can be used to grab data from any target be it an Oracle IAM product, an Oracle application or a 3rd party app. The target doesn't even have to be a database, the data could come from flat files offloaded from a mainframe, for example. This 'digest and correlate all data' approach is reminiscent of SIEM products and someone in the audience at OpenWorld asked if Oracle is moving into SIEM territory with OIA. The answer was no or, to be more precise, the answer was "not now". OIA won't deal with data sources that have tradtionally been part of the SIEM landscape, e.g. network devices. Nevertheless, the distinction seems to be purely technical to me since OIA is clearly capable of dealing with any kind of data.

Attestation is the second slice of OIA and it's probably the slice that's going to be the driver for deploying this product. With attestation targets covering the entire range of possibilities - user accounts, roles, entitlements, membership sets (both role and group) - and attestation workflow appearing to be quite flexible (multi-level AND event-based with advanced support for reminders, escalations and delegation), on paper OIA meets 80% of attestation requirements out of the box. This is a shot across the bow of vendors such as Aveksa and Sailpoint as well as many other identity audit / compliance solutions that have been sold to the line of business.

It's worth noting that attestation generates actionable events, i.e. if an employee left the company but his account and associated access is still alive and well, attestation could kick-off a de-provisioning workflow. With entirely contained in Oracle Identity Manager, both reporting and action steps of attestation process were in OIM. In 11g, reporting side of attestation will be in OIA but action will remain in OIM. Oracle promises to have 2-way integration so that when someone attests in OIA, OIA will call OIM to execute an appropriate action on the target of attestation.

Segregation of Duties (SoD) is another interesting piece of OIA. OIA will have its own SoD engine which could be used to centralize an entire SoD policy lifecycle in OIA, including policy definition, preventive SoD simulation (detect conflicts at design-time), detective SoD check (detect conflicts at run-time), and mitigation. SoD checks and violations are recorded as events in OIA data store so that they could be reported on or sliced and diced along with other data. Since Oracle owns a powerful SoD capability from its acquisition of Logical Apps, the distinction between OIA SoD (aka SoD for Enterprise IT) and Logical Apps SoD (aka SoD for Oracle e-Business Suite) was carefully painted. (Another reason for this distinction is OIM 10g integration with Logical Apps).

If I read between lines, the SoD engine in OIA may be used by other IAM products in the Oracle stack for, well, dealing with SoD issues. If OIA contains data from many apps in the IAM suite, then SoD could be truly a killer app since (perhaps for the first time) one can truly consider toxic policies or business rules based on events that span IAM products. I suppose there's nothing to prevent any app from querying OIA's SoD engine so that OIA may eventually morph into more of a decision engine rather than just an analytics app.

Release date of OIA 11g is calendar year 2010. It will be aligned 11g releases of OIM and OAM.

Oracle Identity Manager 11g

Deborah Volk — Wed, 14 Oct 2009 02:00:00 +0000

Hot off the Oracle OpenWorld presses, I give you OIM 11g:

To expand a bit on the above highlights:

1) Shiny new web UI based on Oracle's Application Development Framework (ADF).

2) BPEL-based request/approval workflows. By using inference and set algebra, I can claim that provisioning workflows will stay "as is" (if there can be such a state as "as is" in 11g). To see is to believe so we shall see.

3) Embedded Oracle Entitlement Server (OES) that will deliver enough semantic firepower in rules that make up various authorization pieces. I am calling this an OES microcontainer (please send me a royalty check if you use the term). This should make it easier to implement real-world business processes in OIM. The primary use case enabled by this is attribute-level delegated administration where you can say that all users with department="Engineering" and cost center="123" can do or have access to function blah in OIM.

4) The identity administration pieces of Oracle Role Manager (ORM) will move to OIM. Management of roles, their relationship to various entities and associated lifecycle will be in OIM. To help with role-based stuff, a few classification nodes in the overall OIM asset taxonomy will be introduced, namely role categories, namespaces and owners. Since roles are now part and parcel of OIM, their membership can be managed via requests and there's a bunch of role-based use cases sprinkled throughout the product.

5) New reconciliation engine. Performance was Oracle's top goal when rewriting the recon engine. This was achieved by pushing a (larger) portion of the transaction to the database via stored procedures and horizontal table partitioning. For a performance-starved and scale-hungry customer, this is a declaration of love. Only time (and millions of reconciliation events banging against the glass) will tell. (Better get some DBAs on your team now!) As a bonus, reconciliation event manager is now available on the web, no need for Operations people to use Design Console. It's been improved as well with an eye toward helping out Operations. For example, it. allows the capture of justification for manual operations such as manual/ad-hoc linking of events.

6) SPML-based web services for identity administration. This is already available in 10g. I don't know if the guts have been changed but 11g reads like an expansion of the current SPML web service interface with coverage for operations new in 11g, e.g. role admin. This was touted as an example of "Identity as a Service" with OIM acting as an authoritative source of identity info for the rest of the products in IAM stack and beyond (collective moniker: Fusion Middleware and Apps)

Some of the request workflow gaps that currently require a bit more engineering than expected by customers from an out-of-the-box-product have also been fixed. Namely, account modification requests (generically "modify requests") are now available thanks to BPEL workflow (ok, human tasks in a BPEL process). Thanks to BPEL engine being quite a bit more flexible than the current "homegrown" workflow engine in OIM, a slew of workflow features are available when dealing with requests, including dynamic routing, retraction, bulk actions, assignment to groups and more.

So the SOA/BPM and IAM worlds have finally collided. I predicted as much all the way back in April (Yes, my crystal ball is very special) If I look at my crystall ball now, I think eventually OIM may be nothing more than a specialized application running on top of a SOA/BPM platform.

Oracle Role Manager has been sent to sleep with the fishes. Its turf is going to be taken over by OIM on the identity administration side and by Oracle Identity Analytics (OIA) on the reporting/analytics side.

It'll be interesting to see the deployment requirements. OES microcontainer is embedded but will the same be true of SOA Suite components necessary for BPEL workflows to work? I doubt it. We'll probably witness the pull-through conquest model employed by legacy Oracle Identity Management stack. OIM will drag SOA pieces along and plant the Oracle SOA Suite seeds whether you like it or not.

Connectors have been mentioned briefly as in "there will be new connectors". On the reconciliation side, backward compatibility was highlighted ("no change to existing connectors or existing reconciliation config data") but I wonder about the rest of the APIs and backward compatibility in general. I am sure there will be lots of twists and footnotes to this story as it develops.

Release date of OIM 11g is calendar year 2010, somewhere between January 1st and December 31st. Apparently all Oracle PMs have been threatened with the worst punishment imaginable - exile to Support - if they narrow it down to a time period less than a year wide.

Last but not least, I don't see any room for Sun Identity Manager or Sun Role Manager in this new world order. Perhaps certain pieces could be extracted from Sun products and dropped into OIM 11g but off the top of my head, I can't think of any. If someone knows better, please leave a comment. Although we're far from seeing the curtain rise (or fall) on the Sun/Oracle deal, when it comes to combining the identity administration products (identity and role managers), I can claim to be at least 50% correct in my Suncle forecast.

Oracle OpenWorld (Feeling Entitled)

Deborah Volk — Fri, 09 Oct 2009 04:02:00 +0000

Come see us at the Oracle OpenWorld 2009 Unconference on Monday Oct 12th at 4pm. We will be in Moscone West on 3rd floor in Overlook II. Our talk is entitled "Everything You Wanted to Know About Managing Entitlements with Oracle Identity Manager (OIM) But Were Afraid to Ask". Following our session, we'll be hosting a cocktail reception between 5:30pm-7pm. Please RSVP if you'd like to stop by and have a drink with us.

Naturally, we think our session will be very interesting but in case you want to see what else is out there, Oracle IDM marketing folks put together a nice "cheatsheet" that collects all IDM-related OpenWorld content in one place.

She moves in mysterious ways

Deborah Volk — Thu, 01 Oct 2009 23:59:00 +0000

I like to refer to Identigral as "she." Perhaps it is a subconscious reaction, similar to naming a car Clarice or perhaps not, it is a woman-owned company after all. She is celebrating her third year today and I thought it might be a good idea for the blog to recap our top 11 greatest blog hits. In order of decreasing popularity, they are:

1. The Rise of Suncle, Volume 1. The first article in the 3-part Suncle series looks at the Oracle acquisition of Sun and drills down into their respective identity and access management product lines, taking up identity and role manager products at both companies. When I started writing the Volume 1 post, I naturally thought of Volumes 2 and 3 but after finishing the post, I realized that it would be better to use functionally relevant titles. Thus, Volume 1 should have been named "Identity Administration" but just like you can't remove a product feature once it's released, you can't retract URLs once they're published. (Yes, I know about HTTP redirects and URL rewrites but I don't think of either as an ideal solution).

2. The Rise of Suncle, Access Management. Second article in the Suncle series that talks about Sun and Oracle access management product lines. Many mentions of fishes as in "sleeping with the fishes". Note to self: avoid watching "Sopranos" before blogging.

3. Authorization in Oracle BI Server (OBIEE). Oracle BI has been widely deployed in various incarnations so the number of visitors to this post is somewhat surprising. This fairly straightforward summary of how to go about integrating the BI Server with an external identity repository for the purpose of authorization proved to be very popular. Contains a bonus feature on how to solve the authorization problem with Oracle Identity Manager. Two for the price of one - read and save!

4. The Rise of Suncle, Directory Services. Third article in the Suncle series, narrowly losing to OBIEEeeeeeeeeeeeek (couldn't resist, sorry). This one is dedicated to (surprise, mystery, shock) directories on both Sun and Oracle side. I said that Oracle should keep Sun DS and make it available alongside Oracle Internet Directory (OID) but I now believe this was an optimistic assumption. My revised prediction is that eventually only OID will remain standing, at least as a commercial offering.

5. Generic Connector and the Temple of Doom. Appropriately titled post on connectors. This stream of consciousness could have easily rivaled Charles Dickens' "Great Expectations" and might have been serialized into a comic strip had I continued waxing poetic. There's enough material to be mined in this thread to sustain a small army of journalists writing for many tabloids. I can see the headlines already - BREAKING NEWS: CONNECTORS AND ELVIS DISCOVERED ON MARS, BOTH ALIVE AND WELL

6. Identity Management Is a Lifestyle, a guest blog by Tom Ebner. While having been out in the blogosphere wild for a short period of time, the meteoric rise in popularity of this blog can be easily explained by its manifesto-like message. From one man's 7 years of experience in leading the creation and deployment of IAM infrastructure and services for a Fortune 500 company to a 1-page collection of rules on how to succeed with such an effort. It moved up to the #6 in our Top 10 in just a few weeks.

7. Provisioning Active Directory - Best Practices. A guest blog by Martin Sandren talking about how to deal with that wonderful Microsoft product/service/pile of stuff we have come to know, cherish and love. Memo to Martin: when is the book coming out? Suggested book title: Active Directory: Alien Mummy Goes On Rampage! If you take me up on the title, it'll be placed next to other good literature at supermarket checkout counters and you'll be guaranteed a financial windfall. Don't forget to share the royalties!!!

8. The rise of Suncle: Solaris, Java, Ripple Effects. Apparently I had more to say about Sun/Oracle marriage. Quelle surprise.

9. Will the Real Oracle Identity Management Please Stand Up (Part III) . The first two parts of this 3-part series were a lengthy prologue to the blockbuster revelation in part III. Here I explained the difference between "legacy" Oracle identity management stack (OSSO, OAS, OID) and the "current" stack (OIM, OAM, et al). With 11g shipping, I will need to do a Part IV soon.

10. Virtual Truth, Chapter 1. I ran out of parts and volumes so I had to start using chapters as my sequencing device. This blog post was my paean to virtual directories as a neat architectural solution for whatever ails you (errr, enterprises). I continue to be impressed with Oracle Virtual Directory, it's like a Swiss knife that can slice, dice and cook you breakfast.

11. The Big Bite. A limerick commemorating the acquisition of Sun by Oracle, this is one of my better attempts at worldwide fame and I could not leave it out of the Top 10 so I changed the rules and called it Top 11. Dear Larry Ellison: I know you've read the limerick and you liked it so I would appreciate an invitation to the next regatta. Please do remember to bring champaigne and caviar. Toodles for now, Deb.

Honorable mention: Opt Me In, Opt Me Out. An essay response to a question posed by University of Rochester's Mike Conklin on his blog, this post deals with an identity management solution to managing the membership of a mailing list.

Identity Management Is a Lifestyle

Tom Ebner — Wed, 30 Sep 2009 09:44:00 +0000

After the Suncle series covering the Sun/Oracle identity and access portfolios, one of the most popular posts on our blog was an article talking about best practices for Active Directory provisioning by guest blogger Martin Sandren. To continue with the thought of providing interesting (and different from our usual ruminations) content I am pleased to introduce Tom Ebner as our guest blogger.

Tom Ebner has spent the last 7 years leading the creation and deployment of Identity and Access Management infrastructure and services for a Fortune 500 financial services corporation. Tom successfully delivered IAM in the real world despite the challenges of new technology risk, changing organizational objectives, scarce resources, and vanishing budgets. Tom is now helping other organizations to plan and execute IAM deployments.

----

Do you like solving tough problems? Enjoy working with new, evolving and often immature technologies? Like being dependent on new business processes and multiple data sources over which you have no control? Welcome to Identity and Access Management! After 7 years spent creating and deploying Identity and Access Management infrastructure and services for a Fortune 500 company, I recently took time to reflect on the experience. As a colleague of mine often reminds me – “Identity Management is a lifestyle”, minus the yachts and Rolls-Royces.

I started with a basic corporate directory and evolved to a full-blown Identity and Access Management infrastructure and services. We went from web single sign-on to provisioning of accounts to role management and entitlements. Here are a few things that I learned while living that lifestyle.

Rule #1. Understand the problem and the opportunity One of the smartest things we've done was to approach IAM as a fundamentally data-driven domain, even though the problem was initially framed in the context of security. Audit findings created high-level awareness of the need to do something, but the concrete dollar value we delivered was based on improved operational efficiency and better customer service. For example, the data required to answer the access control question “Is system access commensurate with job responsibility?” can also be used to route a customer call to the appropriate customer representative. We found we were able to deliver quantifiable business value using this approach.

Rule #2. Assess the quality of the identity data We were fortunate to have a unique internal identifier that had been established for each member of the workforce and this made it easier to correlate data across multiple sources. Having a single, preferably opaque, unique identifier is critical but not necessarily sufficient. Other attributes may be required for correlation but data sources may not have these other attributes or may not assign the same meaning to them. Furthermore, if you have an identity service that provides identity-related information to the rest of the enterprise, it is desirable to extend the data quality rule to each data attribute you expose. While the Identity services provider may not be the “owner” of the various attributes, the identity services are used by the enterprise as an authoritative source and you as the provider will be held responsible for any quality issues. Ensure your authoritative sources understand their responsibilities. We spent a lot of time educating and influencing in this area.

Rule #3. Create a strategic technical vision ..and stick to it! Early on the team created a one page vision for the identity lifecycle. We started with Burton Group’s representation and customized it for our business. This is the familiar on-boarding / registration, provisioning of accounts and associated entitlements, job change and transfer, and finally termination and de-provisioning cycle. We made it speak to our specific business process goals and systems. It was critical to help executives understand the “what” we were planning to deliver ...which brings me to the next rule.

Rule #4. Get (and keep) an executive sponsor IAM is an infrastructure play and with no readily discernible business value as such it is tough and risky from a sponsorship perspective. It involves change to operations and it is not a revenue generator BUT it's a critical enabler. As time went on, it became seen as essential to security and compliance but this wasn't true in the very beginning. You will need an articulate, visionary sponsor who can bring visibility, business reality, and funding. Don’t minimize organizational inertia and tension between different layers. Organizational communication and alignment of objectives still required constant time, attention, and adjustment. Make sure the overall program goals are in sync across security policy, access administration, operations and technology groups.

Rule #5. Build a great team I’m a huge fan of small, smart, creative, and collaborative teams. My core team included an architect comfortable with enterprise architecture and hands on product configurations, a data analyst (DBA quality but with business analyst savvy), a technical lead (expert in the IAM product suites), a business analyst (highly analytical and business relationship oriented), a security expert with software development background and PM skills, and a production operations specialist. We also had an offshore team of skilled production support and software development folks. The breadth and depth of specialized skills required should not be underestimated. Allocate time and money for training and mentoring of staff and offshore teams.

Rule #6. Add great partners to your team In keeping with the theme of “Identity Management is a lifestyle”, you will need significant help from product vendors and professional services all along the way. Make good choices...or they will come back to haunt you. You want partners that help you think creatively about solutions, will take the time to understand your use cases, and will stick with you in a long run. In my case, I worked with product vendors (from major players to startup), IAM services specialists, and offshore vendors. While deliverables are critical, I always looked for partners that I could work with. These relationships paid off when the going got tough.

Rule #7. Create a strategic technical architecture Another key to our success was our selection bias and approach to architecture. We created a domain boundary and clearly articulated what services belonged inside or outside the boundary. This was extremely helpful when it came to detailed design and product selection over the years. It also helped with our internal discussions in the technology enterprise. State your design philosophy. Our bias was buy rather than build, and never do both. We only created custom applications where no product fit our requirements. This meant we created our own White Pages presentation and custom developed web services to expose our identity info. This gave us the ability to control access to domain data and enabled us to control the release process (vs. being dependent on a vendor release schedule).

Rule #8. Deliver something valuable to the business Do it fast, often and preferably yesterday. For us it was making high quality data about the workforce available via a friendly web interface and via secure web services. This allowed us to deploy web single sign-on to virtually all intranet applications and eliminate many individual stores of identity data, providing tremendous operational value as a result. These early successes gave us credibility and paved the way to funding for the next steps… Be opportunistic. We kept our ears open for business problems that could be solved by our services AND would further our strategic vision. For example, instead of a large cross-enterprise role-based access control (RBAC) project, our philosophy was to avoid roles unless we had a very strong business partner with a very well-defined and limited number of roles to implement.

Rule #9. Manage your risk. IAM is a program or a portfolio with inherent risk. Monitor and manage your risk across the portfolio. As with all technology projects – especially those in new product or process areas – be sure to have a plan B (and a plan C, plan D, etc…). While our program was very successful overall, we did encounter significant setbacks in certain areas. One of the biggest lessons I learned had to do with provisioning accounts and entitlements to the mainframe. In this particular area we had a lot of heartburn and not many alternatives so our risk to contingency plan ratio was disproportionately high (high impact with high probability with inadequate contingency plans). While it is often convenient to think that in a buy vs build scenario, if you buy a product the risk has been offloaded to the vendor, this is a fallacy. You own the risk. Spend the time and energy to go through what-if scenarios and be fully prepared to switch gears if and when needed. Balance the opportunities for funding with product and business process maturity. Choose incremental steps carefully.

Rule #10. Understand and communicate “What does success look like?” Manage your stakeholders. Create an annual business plan with clear objectives, expenses, strategic vision (business and technical), and be clear about what is “not going to be done”. I also kept a slide that listed accomplishments in the prior year and to date. I carried this everywhere and used it to keep a persistent message flow on our accomplishments, plans, and value delivered. Never underestimate the communication required for a successful IAM program. It is not an easily explainable topic to most business and/or technical execs. Whatever amount you are currently doing I assure you that you need to do more!

One Policy to Rule Them All

Deborah Volk — Tue, 22 Sep 2009 22:49:00 +0000

Thanks to Anil John's tweets, I've been alerted to National Institute of Standards and Technology (NIST) workshop on Access Management. Having worked for DARPA a long time ago in a land far away, I am not afraid of terms such as Plenary Session or Hotwash, they make any proceeding seem important and rife with danger. Someone abused their access privileges or shared a password? Call the NSA to erase him. (Let's see if there are going to be any information security incidents after that..)

I know that some are not aware that NIST does good work in the information security realm. Among other things, they publish a series of documents called Special Publications (800 series) that cover many basic and not so basic security topics. While not particularly groundbreaking, they're thorough and vendor neutral and can serve as a good overview of technologies or approaches for just about any information security initiative. Unfortunately, the technology landscape evolves at a fast clip and there's a fair amount of dated material, ranging from slightly dated to ancient. Caveat emptor.

On the access mangement front, NIST is far from dated. Part of the workshop is a Survey of Access Control Models paper that looks at (drumroll, please) access control models and their evolution. According to the paper, there's the venerable Access Control List (ACL, resource-centric, doesn't scale), Roles-Based Access Control (RBAC, lacks granularity, doesn't scale beyond broad categories of people), Attribute-Based Access Control (ABAC, scale leads to maintenance and consistency issues), Policy-Based Access Control (PBAC) and finally Risk-Adaptive Access Control (RAdAC, complex to implement, requires a lot of computing resources).Surprisingly, the paper doesn't mention Mandatory vs Discretionary Access Control (MAC vs DAC) classification. ACL is a DAC, the rest of the model are MACs.

The pro/con analysis of different models presented in the paper is very good, I agree with most (if not all) of it. From an ontological perspective, I can support the paper's position of representing RBAC, ABAC and PBAC as three different classification nodes but really they're all variation on the same theme. At the implementation time, there are attributes (employee position, department, status, etc) that go into rules ("allow all employees to edit internal wiki", "deny wiki edits to all engineers between 2am and 5am") that make up a policy. In role-based access control, there are rules that define a role, in ABAC there are rules that float by themselves and in PBAC there are rules bound into policies. The paper acknowledges this by noting that the gap between PBAC and ABAC is mainly enterprise focus with PBAC being a "harmonization" of ABAC and that PBAC will extend the policy and access to many resources.

What I found interesting is a presentation by NIST's David Ferraiolo that talks about a universal Policy Machine or, to be more exact, a universal access control stack that can slice, dice and cook you breakfast. As the presentation notes, the main problem with access control today is very simple - the implementation is nothing like the policy. In other words, the policy might be a complex document with legal nuances but by the time the requirements filter down from the original policy document through the business to IT to implementation to delivered result, you might as well have asked for a submarine with nuclear warheads and instead gotten a toy hammer. The presentation refers to this transformation as "dismal state of affairs". (Something is rotten in the state of Denmark!) The reasons for the policy/implementation gap are many; the author cites lack of interoperability (i.e. a challenge in having application X and device Y and operating system Z all getting their "direction" from one central decision point) in heterogeneous environments as one key problem.

Furthermore, access control as defined in the paper is broader than just access to resources. It includes unauthorized dissemination of information, e.g. via a copy and paste into email and other out-of-band actions involving endpoints such as flash drives. From the author's perspective, access control should encompass the entire computing stack and then some - OS, devices, applications and data. To this end, the author proposes a universal Policy Machine that has "just enough" expressiveness in the "language" used to implement attribute-based rules so that this Policy Machine can become that one decision point all applications, devices and operating systems will use for access control. Reading this I had a science fiction flashback and my brain came up with this as a visual representation of a Policy Machine (hint: it zaps you)

The presentation closes with a promise of a working prototype of a Policy Machine that covers files and Open Office suite of apps, including copy and paste. In my next blog I will attempt to build the Policy Machine from stock parts, similar to what Jonathan Godwin (my personal hero) does with car engines.

No App Is An Island

Deborah Volk — Thu, 17 Sep 2009 22:09:00 +0000

...but perhaps it should be. A properly fortified island with double moats, crocodiles (or cheerleaders), molten lead showers, Spartan warriors and of course artillery straight from Guns of Navarone . (I don't know why you need artillery if you have crocodiles but I wanted to add it just in case. As the ancient Finnish proverb says, "backups never hurt").

In many an enterprise you'll find a network architecture where a lot of effort has been spent on protecting the perimeter, separating nice, shiny, internal TCP packets from mean, dirty and virus-laden external packets. (UDP packets are always lost and confused, no need to filter them out). As Gunnar Peterson writes in his "There Are No Firewalls" blog entry, imagine that there's no firewall separating inside from the outside. What would be the potential damage to the business assets previously thought safe? This is an excellent Gedankenexperiment for any enterprise architect but it's particularly interesting to examine in the identity and access context.

Firewalls are breached because the attacks evolve faster than perimeter security products. Even if the product has adequate protection against some very sophisticated threat, it's far from certain that it's configured and installed (and patched!) correctly to contain the threat. Thus, the conservative assumption is to assume that the firewall doesn't exist. Once the perimeter curtain drops, it can be quickly shown that identity and access management infrastructure can make a large difference in both keeping the bad guys at bay and at creating value by enabling collaboration between customers, partners and the company at the center.

If the application owners assume that they're all inside a fortress, the applications typically have an anemic authentication and authorization model. At best, authentication relies on a single factor, usually a username/password combo. At worst, there's no authentication and it's either derived from the fact that you're on the internal network with your credentials lifted from the desktop or the application doesn't even bother to authenticate you. The latter is common for content-based apps (hey, wer're on Intranet, whee).

Authentication is a binary state - you're either in or you're out. Authorization, on the other hand, is a much more fluid phenomena. You can be inside the fortress walls, even inside the building because the front door was poorly locked but you won't be able to do much after that if you need 50 different keys (privileges, permissions, broadly - entitlements) to open one more door leading to treasure. The role of entitlements and their place in an authorization model suddenly becomes crucial to reflecting the attack. Deploy adaptive access control on the front-end where transactions as benign as a page retrieval or a form submittal could be considered in a real-time risk score and deploy fine-grained entitlement attestation on the back-end to catch deviations and you've got a credible defense mechanism. (If you open the gates to the world and remove the firewall, what do you do about dirty packets, be they viruses or denial of service attacks? Gartner's Neil MacDonald says you virtualize and proxy everything).

Fortifying each app is expensive so why do it? Think about the parties you do business with, typically your customers and your partners. Your large customers and most valued partners will want to participate in your business processes, be they sales, order fulfillment, distrubution or garbage collection. How do you let them into your shop? Easy solution - require them to play nice with your perimeter, e.g. require them to use VPN or secure tunnel. Harder solution - deploy an app, usually a web app (e.g. a portal) that exposes relevant chunks of a business process. Hardest solution - don't do anything, your CRM, ERP, SFA and other apps already have your business processes implemented on top of them. All you need is for the process to extend beyond the perimeter, easy and secure collaboration. Why waste money on building yet another app or reinventing the wheel by changing the current process when you can take a few important apps, make them into islands and open the gates.

Webinar - Managing Entitlements with Oracle Identity Manager

Deborah Volk — Tue, 15 Sep 2009 22:40:00 +0000

To showcase some of the challenges and solutions of managing entitlements' lifecycle, we're putting on a webinar. The topic of entitlement management is broad so we're going to focus on what we think has the highest value proposition to the business - entitlement attestation. We're going to demo some of the design patterns for fine-grained attestation as implemented in Oracle Identity Manager. Take a look at our entitlement blogs and our whitepaper (registration required) for background information.

Much Ado About Entitlements

Deborah Volk — Tue, 15 Sep 2009 17:11:00 +0000

The popularity of entitlements, both as a noun and as a thing, is rapidly growing in the IDM world. Before entitlements became an oratorio impossible to ignore even with the best Jedi mind tricks, there was a flutter of butterfly wings. That is, 2-3 people in a hallway at a conference started whispering entitlements, entitlements, entitlements . Then came presentations, then whitepapers from analysts and vendors and finally the Market noticed that, wait, what about entitlements? The chaos theory refers to the initial whisper event as a butterfly effect, there's no other explanation for their sudden rise to fame. I mean, it's not like they didn't exist, they were just invisible to the human..err...auditors' eye. Hail Eris!

Much to the delight of those semantically inclined, the definition of the noun entitlement has proved hard to nail down in the identity and access management context. While we were feeling smug and entitled, we've written a blog post on the subject along with a whitepaper (registration required) that talked about the challenges of managing entitlements throughout their lifecycle. Let's see some popular definitions of entitlements:

Webster / Wikipedia: A right to benefits, esp. by law or contract
Burton: Object in system’s security model that can be granted or associated with a user account to enable the account to perform (or prevent performance of) a set of actions on the target system
BEA (now Oracle!): Set of privileges that govern what an application user can do
Identigral: A business rule expressing actions that can be allowed or denied

From our perspective, it doesn't really matter that the entitlement is granted to an account, a user, an application (yes, applications have entitlements too!) or some combination thereof. The act of granting and the subsequent association between an entitlement and its subject (owner) is not relevant to the definition of entitlement. Webster is closest to what we feel is the best definition. Let's consider an example somewhat divorced from technology.

In a mythical company Ourbont (pronounced oooor-BON, yes it's French) there are monthly management meetings. Everyone who manages other people is invited to the management meeting. The security guard at the door personally knows the managers (it's a small company) and on the basis of, well, your persona, does or does not let you into the meeting. You could say that being a people's manager is an entitlement. It was something that was made into 'law' by the contract between the employee and the company at the time of hire. You could also say that being able to attend management meetings is an entitlement, perhaps a derived one, since it follows from one being a people's manager. The latter entitlement exists due to company policy which (loosely speaking) is a form of law/contract.

We continue to believe that enforcing access based on entitlements is a relatively understood issue. Sure, there are implementation challenges but there's an embarassment of riches when it comes to picking products that enforce access. In the Oracle IAM stack alone, you can throw a dart at the wall and hit a product that can check entitlements and allow or deny access:

Oracle Access Manager (OAM) - authorization rules in a policy domain.
Oracle Virtual Directory (OVD) - access control rules
Oracle Internet Directory (OID) - access control policy points and privilege groups
Oracle Entitlement Server (OES) - role and access policies
Oracle Identity Federation (OIF) - in federation protocols; usually deployed with OAM
Oracle Web Services Manager (OWSM) - assertion-based policies
Oracle Adaptive Access Manager (OAAM) - rules-based policies

In order to enforce the entitlement, it (entitlement) must be first provisioned to the target system and second associated with a subject (user, group, application,etc). This is where a lot of painfully expensive steps happen because much of the workflow involves people from different teams. Throw in approval requirements, throw in eventual upgrades of target systems (Oracle e-Business Suite 11.x -> 12.x = potentially thousands of entitlement changes), throw in audit and compliance (does this person still need this entitlement) and you've got an unmanageable mess on your hands. We've seen and tackled this problem of managing entitlements' lifecycle so many times that we've got it down to science. Come to our webinar to find out more about managing entitlements and using Oracle Identity Manager as a platform for keeping them under control.

Super Agent 2.0

Deborah Volk — Wed, 05 Aug 2009 09:01:00 +0000

It has been years, literally, since I have heard anyone talk about agent vs agentless. Both sides have spoken, and I believe the resolution has been passed: Agentless (by that I mean nothing installed remotely from the server) whereever possible, then use agents. And in today's climate of open standards and secure communications, it seemed like "whereever possible" was everywhere. Thus, the debate died and it became an afterthought.

Then comes Microsoft Exchange 2008.From a remote java perspective, Microsoft Exchange was all figured out.Java applications utilized JNDI to communicate with the MS Active Directory Domain Server to set initial MS Exchange attributes, then the MS Exchange's RUS (Recipient Update Service) finishes the object.There are certainly some inherent problems in this approach (for example, latency from the service perspective), but it allowed a remote (from the AD/Exchange domain controller) application to provision MS Exchange.And that remote application did not even have to be running on a windows machine -- a truly agentless topology.

With the issues facing the Exchange RUS, Microsoft decided to remove part of this service in MS Exchange (for a good blog entry on this, read here) and make the user fully provisioned once they are created in the console GUI or by command line.Making the logical leap, we can then assume that the way to get users fully provisioned is through the console GUI (ADSI) or by command line (which in fact is true, as the cmdlets are the "API" to Exchange now). This is fantastic, your application is residing on a machine with the Exchange Management Shell(command line) or it has monkeys working in the background fat-fingering in data in the GUI.But if your application isn't in either one of these situations, then you are back to one less agentless connector in your pod.

For the IDM tools that are used to playing with older applications that didn't make it into the alphabet soup of communication standards, this isn't much of a problem as far as implementation of a solution is concerned.But for IT operations everywhere, the age-old, dead-horse beaten agent/agentless argument will start rearing its ugly head again.

Silence is Golden

Deborah Volk — Tue, 21 Jul 2009 09:32:00 +0000

Even with more daylight, I struggle with finding enough time to juggle family, work, and blog (not necessarily in that order, but pretty close most days). As a result of increased activity, I have been silent on the blogging front. This is not to say that I have not been thinking about all the interesting things to write about. With the workload increasing, the number of topics that I would like to discuss in an online forum also grows. Unfortunately entropy is hard to beat and without a perpetuum mobile as a source of energy, I have to find that elusive equilibrium between space and time. Thus we arrive at: How Authoritative is Authoritative?

If you have been reading our blog for a while, you will know this is not a new theme. It seems that a heretofore undiscovered sequence exists in Nature: skeptics -> identity management folks -> Identigral. For evidence, see Seek and Destroy (and its counterparts), Spring Cleaning, and Through the Looking Glass (our data quality entries)). In earlier posts we looked at these issues from a perspective of a specific use case with only one common underlying theme: checks and balances. If the IDM solution is told by the business "this is our authoritative source of information," is the IDM team supposed to take everything at face value, with no inspection?

At Identigral, we are proponents of checks and balances (ergo, the common theme in all of the aforementioned posts) ... but can the IDM program be proactive when it comes to "bad data" in the authoritative systems? After all, based on extensive, peer-reviewed identity management research that runs many volumes and comes with serious statistical analysis (read: anecdotal evidence gathered by Identigral), bad data is expensive. It is a broken spoke that stops the wheel from turning smoothly, causing exceptions to bubble up in an otherwise automated process. When exceptions happen, people become part of the process and that's expensive. In the IDM world, multiple teams of people spanning groups, applications and continents might become part of the process and that's VERY expensive.

Let's segregate the data into different types of "badness":

1) Typo or data entry error
2) Deterministic errror in systems which causes generation of bad data (e.g., a script that terminates everyone)
3) Malicious data change (e.g., an IT support person promoting himself 3 pay grades during a change implementation)

The first type of error is very hard to detect. It typically affects a few records and there might be very little correlation to any other event or data related to the user who was typoed (yes, that's a new verb). Obviously, there are some rules that might be applied to certain data fields: certain addresses are invalid, some job code, department code combinations are invalid, etc. But, for the most part, these will go unchecked and result in the necessity of "spring cleaning" and "checks and balances."

The second type of error is usually caught and the cost associated with these errors isn't in a failed audit or damages but rather in clean-up operation. The clean-up is a very manual and labor-intensive process because IDM solutions don't account for the mis-hiring or the mis-firing scenarios. They're not resilient to failure. There are two things the IDM solution designers can do: 1) Put in processes to deal with mis-hires, mis-fires, and mis-updates and 2) With some relatively simply analytics, a system could tell if 100 terminations in 1 hour is out of the norm, or if people are hired in California on Christmas Day (and you are a bank, as opposed to a grocery store). Fancy analytics is expensive and it's usually applied in scenarios with a lot of data, e.g. modeling the fraud risk on a credit-card transaction based on patterns detected in 100 million other transactions. But there are some simple threshhold-based checks that could be put in an IDM solution that could lower the cost of cleanup efforts when something goes wrong. If you want to get fancy, you can make your thresholds be adaptive by using a linear transformation. This technique (albeit in a different domain) is described in Traffic Jams blogs.

The third type of error is the hardest to detect, especially given the ubiquitous assumption that if you have the right to do something you are allowed to do it. So if a support person can adjust his pay grade, then voila! he has been adjusted. Segregation of Duties and, broadly speaking, GRC solutions are supposed to prevent this from occurring but how many companies out there have a working Segregation of Duties or GRC implementation? While you wait for that, you can catch some malicious events in the IDM land by analyzing the events coming from the data sources. In fact, the bulk of work in a GRC implementation is coming up with credible detection rules that reflect the business and not just flag generic "write a check, approve a check" type of scenarios. If you can come up with these rules, you can put them to work in IDM by looking at incoming events.

Rock around the clock

Deborah Volk — Thu, 11 Jun 2009 21:03:00 +0000

As the summer descends upon us, so have various industry conferences. With that raison d'etre, a rising tide of interesting discussions is sweeping across blogs and other assorted outlets of identity and access management sound and fury. Mark Diodati from the Burton Group weighed in on the ontological issue of privileged accounts and people who (ab)use them. The linguistic conundrum seems to be in differentiating Privileged Accounts from Privileged Users. The secret sauce of securing privileged accounts according to Burton is based on managing two ingredients: WHO has access to the accounts and WHAT the accounts can do.

In my experience, the WHO/WHAT (WW) aspects are important to know and manage with respect to Privileged Accounts...but they (aspects, that is) don't change often. If you give a storage administrator access to all storage servers on a particular production cluster via a privileged account, you don't want to restrict the capabilities of this account or the storage admin may not be able to do his job. This would leave all those database-hungry customers in a bind (pleeeeeease, Dear Sir/Madam storage admin, could I have another 50 GB of space on your Most Blessed SAN array today and 50 more tomorrow). Nor would the storage admin ever share his account with anyone outside the usual few people in the storage admin group, so the WHO essentially does not change. What is truly important to manage (choke with a kung-fu grip) is the WHEN of the privileged account. When is the storage admin allowed to make production changes? (If you answered 'anytime', remove yourself from these Internets).

Solutions from vendors such as Passlogix and Cyber-Ark attempt to address the when by limiting the check-out of the password to the privileged account owner. This works well if the privileged account is not the sole account of a user on that system. Unfortunately, this is not always the case. Let's take our happy storage admin as an example. He has an account BOBW on storage array bigwhopper.mycompany.com. He monitors various storage parameters on a regular basis via a few shell commands, so he needs read access every day. Unless you're looking at your CEO's paycheck, read access is not considered an elevated privilege by auditors. But anytime the byte-hungry database hosted on the storage array goes through a planned change, Bob needs to run a series of scripts to snapshot the database, create copies of certain storage volumes and clean-up the previous snapshots by moving them offline.

He now needs the ability to read files, create files, perform various storage array operations and eventually delete files. He only needs this access during the planned change window. At this point, you can either create a second account for Bob that has these specific privileges, but Bob can only use this account during the appropriate period (a password vault solution can work here), or you can grant the appropriate access and then revoke it after a given time period. The third approach is just to give him the access and to trust him.

The first approach, letting Bob have two accounts, would work, except now your audit processes have to deal with two accounts. If you have implemented an identity management solution and you had the amazing foresight to provide for this possibility, you will have both accounts show up as belonging to Bob, one temporarily belonging. There are organizations who elect to take this approach. They would rather keep the privileged accounts separate from the day-to-day, 'normal' accounts. The disadvantage of this option is that it increases the work that auditors and attesters have to do. They also have to have a razor-sharp knowledge of storage administrator group processes to recognize that account BOBW1 is the 'normal' account and 'BOBW2' is the privileged account.

The second approach (timeboxing the account use) truly mimics what the business case calls for but there's a technology catch. If you don't have an automated system that can enforce timeboxing, it would quickly become an administrative nightmare. Now, you might be thinking to yourself "isn't this the WHAT of an account?" In part it is, because you are changing what a person can do. But an equally or perhaps more than equally important factor is what the person can do relative to the context the person is in (the WHEN). Situationists of the world, rejoice.

All dreaming of cookies and milk aside, the third approach seems to be the one we encounter the most in the bright-lights world of IT. Mainstream adoption of sophisticated access management technology and business/IT change of related processes just aren't where they need to be at this point in human history. Thanks to Burton's opening shot in this novel, perhaps the software vendors will feel the anguish of security professionals and start developing products to help lock down access without jeopardizing the work that needs to be done.

...or perhaps the old ruler on the knuckles approach needs to be explored as an enforcement alternative. Contact us, we can help. (We'll bring our own rulers while supplies last).

Ask Identigral (Issue 6)

Deborah Volk — Fri, 05 Jun 2009 09:39:00 +0000

Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.

What is the best way to customize Oracle Identity Manager user interface?

When customizing any enterprise-grade product, the first question you (and your clients) should ask is what happens when the product is upgraded. Will you have to provide your own framework and process for maintaining your changes as the product is patched and upgraded? That is the question, as they used to say in ye olde England. Oracle Identity Manager is no exception to the rule. The approach you take for customization can have a signficant impact on the amount of time it takes to patch and upgrade your identity management infrastructure.

First, the basics. Oracle has a document that goes over simple customizations to the Oracle Identity Manager user interface, the document being Administrative and User Console Customization Guide. While there are numerous other ways to accomplish the same goals as those in the guide, following Oracle's suggestions will help you stay out of major trouble.

If you have a requirement where you deduced that a customization is necessary and the customization doesn't fit the norm, it is not addressed in the aforementioned Oracle Identity Manager documentation, then there are four generic approaches available to you:

1) Modify the JSPs to get the behavior you want
2) Write new JSPs (and/or action classes and/or other supporting code) to do exactly what you want. Have your new pages be called from somewhere in OIM web UI, e.g. a new menu item that you might have added
3) Extend the action classes to either override out-of-the-box OIM functionality or add additional functionality
4) Forgo the OIM web UI altogether and roll your own

To choose from these approaches, we have to agree on what's important to us. If we define our goal and key evaluation criterion as being able to draw a line in the sand between our changes and vanilla OIM so that we won't get hurt by patches or upgrades, then none of these are perfect. Our own user interface (approach #4) comes closest but even then there's a large underlying assumption that all interaction between the custom UI front-end and OIM would proceed via official, publicly documented APIs. This may or may not be true, it depends on the requirements.

Whenever you modify a JSP, you will have to merge those changes back into the post-patch or post-upgrade OIM codebase. Having a robust source control system with good merge tools will help speed this up and not make it too onerous but there's a catch. A merge might be easy to accomplish in terms of joining two text files and figuring out what line goes where, creating one physical whole with correct structure but that does nothing for the meaning of that new whole. The new code may end up behaving in a completely different way. Logically, the merge is not complete without regression tests that prove your new page works under the same set of inputs as prior to the merge. The only benefit of directly editing a JSP is that you may not need a server restart to see the changes although that also depends on your app server settings and your strategy for deploying the modified JSP.

Adding your own pages, or extending the classes, typically requires one or more changes to be done to xlWebAdmin.properties, struts-config.xml, tiles-def.xml (there are a couple other files). Modifying these files may require a restart depending on your application server and how it was configured. The advantage of this approach is that there's no code merge, only XML and properties so there's no need for regression tests on existing pages although running them never hurts. With this approach Oracle can add or change features on the web client and usually (but not always) those changes will not have any impact on your custom code.

Thus, our advice is to evaluate the requirement driving the change. I've seen great many cases where the UI customization was not necessary, another solution that did not require that was possible. If there's no way around the customization, think about the type of change you're going to be making. Consider the frequency of future changes to the same component, the size of the change and whether there are any major updates or revisions to the general area of the user interface planned by Oracle and placed on the roadmap. Come up with a policy and a process to deal with all types of customizations so your team follows the same approach for each class of changes. Last but not least, ensure you've got a build & release process to deal with merges and regressions.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc

Overcast weather

Deborah Volk — Tue, 02 Jun 2009 09:35:00 +0000

Toto, we aren't in Kansas anymore. I believe we have landed in Seattle where cloud cover is the norm.

At JavaOne they have a whole set of sessions dedicated to the Cloud. Soon, the Cloud (with a capital C, mind you) will be as pervasive as the web. (Wait, isn't it the same thing?!). I was fortunate enough to attend the standing-room only panel on Secure Cloud Computing this afternoon. The panel consisted of Michelle Dennedy from Sun, Joshua Davis from Qualcomm, Jim Reavis from Cloud Security Alliance, Tim Mathers (old timey (experience, not age) InfoSec guy), and David Hahn from Wells Fargo. The fact that it was standing room only (though the room was fairly small), says something about this cloud stuff, and the importance of security in it.

For those of us on the frontlines, this doesn't come as a surprise. The Cloud is just another permeable boundary across which credentials are shared and data is exchanged. What makes the cloud unique is the ownership of the process, data, credentials, and associated risk. The big points made by the panel were that in order to make Cloud Computing viable, vendors will need to be transparent insofar as their security practices are concerned.

Validation of these practices needs to be exercised, and not necessarily by a third party vendor. Customers should do their own due diligence. Without these two items, compliance at the corporate level may not be achieved, and the liability the corporation assumes might be too great a barrier for entry.

We heard the panel views about what belongs in the cloud (basically everything, including carrots and celery), who should use the cloud (everyone), what standards were good starting points for securing the cloud, and what vendors need to do to step up to the plate. Is this all really just lipstick on a pig though? It feels like a terrible case of deja vu. Haven't we been through all of these issues in some form or another? When we outsource our development to a third party vendor with an offshore presence, we have to worry about how they authenticate and authorize their developers (for that third party might also work for your competitor), you have to worry about import/export of your data and applications, you have to worry about privacy of your consumer data, and the list goes on.

If we are finding shortcomings in the security practices surrounding the Cloud, then we most likely already have holes of the same size or bigger in our current processes, Cloud notwithstanding. By addressing internal, Earth-y problems first, the inevitable slide towards the ever-economical, self-adapting, completely autonomous and very smart mass of Floating Water will become less painful for organizations.

Implementing Seek and Destroy (part 2)

Deborah Volk — Mon, 01 Jun 2009 01:00:00 +0000

In the previous blog post, I have described some of the best practices that are worthy of consideration when designing robust off-boarding processes. In part 1, I talked about how to implement some of these best practices using Oracle Identity Manager. This post is a continuation of the implementation discussion.

Trust but Verify. You need a system of checks and balances, at worst a single control where an alarm will go off somewhere if the terminated employee hasn't been off-boarded. In Oracle Identity Manager (OIM) this is best accomplished via attestation. Attestation tasks could be automatically generated for both the direct supervisor of the off-boarded employee as well as someone in HR. The attesters could be notified via email and they would also have open tasks show up on their OIM dashboard/self-service console in the web UI. (They'd have to login there first, thus email as a primary alert mechanism). Since it's possible to have the task escalate to the person's manager or a designated delegate if the task SLA has been breached (e.g. no action on the task in 24 hours), attestation is a potent weapon for ensuring that off-boarding indeed occurs...but there's a catch.

In order for OIM to generate tasks as part of the attestation workflow where the tasks are scoped (targeting) only the terminated person, it must know about the termination event. If the termination event makes it into OIM, whether via reconciliation or push from an authoritative HR source upstream or via another channel such as a web front-end or operator override, why do we need a redundant control in the form of attestation? We can Be Fast and revoke access right then and there when the termination event comes in or when its timestamp-based threshold is exceeded.

The catch is that OIM needs the termination event to act but in order for the termination event to come in from the upstream source, someone upstream needs to act first and this often doesn't happen as promptly as one would like. Sometimes it never happens. Without the termination event, OIM can't automatically revoke access BUT it can still schedule an attestation. This attestation will not be narrowly scoped since we assume that we don't know who was terminated and when. That's how many Oracle Identity Manager implementations deal with zombies - they have people in the supervisor capacity in the entire company attest every quarter that Joe Smith onis still there and breathing. The problem with this wide-ranging attestation is that it's an expensive process; you have to reduce its scope to make it cheaper...which runs into a Catch-22 described above.

This is why the Don't Get Stuck in Traffic is a best practice from a process perspective. If you've got a single source of termination events, that source may become a bottleneck and the best you could do is run a company-wide drill every quarter to clear out dead people. On the other hand, if you have multiple channels that can produce a termination event, you have a way out. This becomes particularly important if a person leaving the company, voluntary or involuntarily, had privileged access, be it to systems or data such as a worldwide sales forecast. The extra channels then become very handy since you can revoke this person's IT access without waiting for HR to complete the termination paperwork and enter the event into their system.

Last but not least, let's not forget that having OIM accept events from upstream source, usually an HR app, is far from a given. I've seen a number of deployments that attacked provisioning first (gotta have an Active Directory account to get onto the network!) with terminations and alignment with HR being further down on the list. In this case, we recommend having a web front-end that lets OIM know that a person should be off-boarded. Once the switch to HR occurs and all events start flowing from there, you still have your web front-end as a working backup channel.

Seek and Destroy. Physical access (entering gates, buildings, floors, offices) is just as important as logical access (entering network and various systems). Best-in-class off-boarding processes do not differentiate between physical and logical access. In Oracle Identity Manager, physical access can be revoked along with logical access. This starts with bringing physical access into OIM as a resource with a lifecycle to be managed.

There are two scenarios. One scenario is that physical access is managed by an application such as Manhattan Software's Centerstone with some factor such as a key card or a badge used to gain entry. The other scenario is that physical access is not managed by software. At best, there might be a spreadsheet with a list of Active and Terminated users and a person who owns the spreadsheet. These two scenarios might seem like extremes but surprisingly enough they represent the two most frequently encountered cases.

In the first scenario, a resource in OIM can be automatically disabled or revoked during off-boarding. This would then trigger a sequence of events that percolates down to the connector which in turn calls the physical access software. This is a worst case scenario - custom connector that talks to the app directly via the app's API or via a friendlier abstraction such as a web service sitting on top of an unfriendly app API. (Many physical access systems are indeed somewhat archaic in their internal architecture so the web service scenario is not uncommon). Some physical access management packages use LDAP-compliant directories as identity stores which makes this downright easy. Technically, there's nothing special about this use case. The details of the integration between OIM and the target application that manages physical access can be worked out.

In the second scenario, we can use a feature of OIM that few people know about - human-powered workflow tasks. The OIM workflow engine and application layers that use it were conceived to handle both programmatic (automated) tasks that many people think of simply as "tasks" and human tasks. The physical access resource still exists in OIM, its lifecycle is no different from the resource in the first scenario. When a human task is generated during the workflow, it's assigned to a human (with an OIM login, of course) and put on his or her queue. The workflow pauses and waits for the task to be completed. The human assigned the task gets notified via email, logs into OIM, sees the task on his task list (aka Open Tasks) and acts on it. The action occurs outside of OIM, e.g. moving the user from Active Users spreadsheet tab to Terminated Users tab, taking the office keys from the user and escorting him out of the building, but it's recorded inside OIM. When the task is done, the human task owner marks it as completed in OIM and the workflow proceeds.

In both scenarios, the user's physical access is revoked.

Ask Identigral (issue 5)

Deborah Volk — Fri, 29 May 2009 23:48:00 +0000

Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here

We have applied the latest patch to our Oracle Identity Manager installation. Does that mean that we have to reapply the previous patches too? What is the difference between a minor release and a patch?

This depends on your definition of the term patch. A publicly available Oracle Identity Manager (OIM) patch is not a stand-alone fix for a particular issue; it is usually a bundle of bugfixes for both public and "private" issues, enhancements and (rarely) new features. Public issues are generally reported by customers; they are available for viewing on Metalink by all customers. Private issues are usually reported internally by Oracle (or morph from a customer-reported problem) and are not available for viewing on Metalink by customers even though you may see an issue number and an issue description referenced in release notes.

Patches are cumulative. That is, the latest patch includes the previous patches. The patch documentation specifies which patches are accumulated in this patch, i.e. the cumulative effect does not go back for 100 patches, there's a baseline/cutoff.

Oracle Identity Manager patches have a build number. Releases have a version number and a build number. Unpatched release 9.0.1.5 is build 1000 (arbitrary number) which corresponds to a fully-qualified build number of 9.0.1.5.1000. The version of this build is 9.0.1.5. If you apply patch BP03 to this build, you rev up to the build of the patch. The patch is build 1700, making the fully-qualified build number be 9.0.1.5.1700 and the corresponding version 9.0.1.5 BP03

Starting somewhere around 2nd half of 2008, the informal concept of a "bundle of bugfixes" was formalized as a "bundle patch", the latter being abbreviated as BPXX with XX being the bundle patch number in a series of cumulative patches. For example, if the latest patch for release 9.0.1.5 is BP03 and you have currently applied patch BP01 to 9.0.1.5, if you apply BP03 on top of BP01, you will get patch content for BP01 ,BP02 and BP03, all for 9.0.1.5 release. Even though patches are cumulative, they may or may not include the one-off patches released to you by Oracle. Once you've applied a patch, you must reapply any one-off patches not included in the official patch and any customizations of your own that will have been blown away by the patch. Consult Metalink document 782321.1 for listing of 9.1.0.1 patches and 744663.1 for patches of 9.0.1.5 through 9.1.

Depending on the volume and type of customizations,we recommend a fully or semi-automated build deploy process that applies your customizations to a freshly patched installation of Oracle Identity Manager. Naturally, a type of customization where you insert a chunk of code into a JSP is something that can be easily broken by a patch or an upgrade. Automatic re-insertion of the code into a new JSP can only mean something if you have regression tests that can be executed. We offer a Change Management Checkup service to help organizations with process issues such as patching their Oracle Identity Manager instances.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc

Spring Cleaning

Deborah Volk — Thu, 28 May 2009 23:54:00 +0000

Each spring an annual rite beckons me. Software engineers might call it refactoring, artists prefer the term deconstruction and tres chic museum curators use denouement. The rest of the world calls it cleaning up your mess. Cobwebs are removed, dust is annihilated, furniture is rearranged, (ab)used items are donated or discarded. This is more out of habit (as rites wont to occur), the local microclimate doesn't really require winter clothes to be put away and summer clothes to be readily available. If you go through all this trouble of taking things apart and putting them back together, you should also decide what to throw away and what to keep. (That Members Only jacket you've worn five holes in since 1980s probably should go). Moreover, if you're struggling to maintain order, you might want to come up with a new methodology of avoiding quantum-level phenomenon where you are not sure if that sweater is really in the same place where you left it yesterday.

As a rule of thumb, weird vacuum cleaner inventors excluding, most people hate cleaning, be it spring, winter, summer, fall or any other season, including Lunar phases. It is time consuming, often at odds with itself (you want to keep little Jimmy's abstract expressionism paintings on your walls but the landlord objects), and just plain messy. Nevertheless, there are a million (and a half) good reasons to do it. For example, according to the National Soap and Detergent Association, getting rid of excess clutter would eliminate 40 percent of the housework in the average home. Facts are stubborn!

If you buy into the premise that an annual cleaning rite at your own residential abode is a mandatory event, consider what kind of dust is collected by an identity administration solution.
Forget yearly, you'll be lucky to do any cleanup every 2-3 years, that reconciliation engine never sleeps! People data starts resembling episodes from the Twilight Zone (zombies and such), logs stack up into impenetrable wooden fortresses that could easily reach a terabyte (1 GB/day is not uncommon in high-volume deployments), processes change or go defunct. Even though this may seem like an operational issue, there's usually not enough time or muscle on the operational side to deal with it, it's a project like no other. As digital dust accumulates, it clogs up the database and throws off an unhealthy sheen when piling up on the filesystem.

We all know that resources aren't free and there's no such thing as infinite amount of disk and CPU, there's always a price to pay. Not only the efficiency of the overall solution goes down but total cost of ownership goes up as well. To address these problems and to join the new and glorious tradition of spontaneous, self-organizing events (aka unconferences) , cultivate a recurring clean-up fest in your organization. All festivals need a catchy name. My suggestions:

Annual Identity and Access Management Dustbowl
First Ever Magic ReconciliationCamp
Enterprise Datacon XII (always append a Roman numeral, make it grandiose)
Feathers of Orphaned Events

Tasks that should be part of your cleanup:

A cross-check between records in your identity management database and same records in applications under management. These records have been previously reconciled from the application so this is an independent spot check on both data quality and the reconciliation process. Pick some records from the identity management side and then go directly to the application to research them. The outcome of the comparison could be as simple as a spreadsheet. Obviously, fix the problems seen, or at least schedule to fix the problems
Review your logs and the log retention policy. Do you have a problem of keeping clothes you haven't worn for last 5 years? If you are a packrat at home, you might be a packrat at the office. Take a look at your logs and retention policy to ensure you have sufficient data but you're not being flooded with data. Just as you do with your personal records, define how long you need to keep each type of log to appease support/troubleshooting and audit needs. Avoid what-if-itis if possible.
Review your code and configuration (application, app server, web server, database) . Do you have features deployed in production you are no longer using? If your product allows it, remove the unused features, don't fall for the trap of archiving. If they are kept in production, there is a cost AND a risk associated with these features. Consider the consequence of them being accidentally activated.
Sync your source code repository with code in production. Make sure all source code in production is checked in and what's checked in is in production. Take the Agility Quiz to find out where you stand with your development processes.
Update documentation. Many deployments have great documentation during the initial rollout but fail to keep it up, thus quickly depreciating the value of documented knowledge. Updated documentation helps reduce costs when it comes to communication with other groups, bringing new people on-board and, of course, troubleshooting. Based on our experience, one of the biggest barriers to walking the walk of "this is a living document" policy is the documentation toolset. Lowering the barrier to adoption by enabling one-click collaborative editing is the key requirement. A wiki is an excellent fit for this type of documentation process.

What other tasks should be or already are part of your spring cleaning?

Implementing Seek and Destroy (part 1)

Deborah Volk — Tue, 26 May 2009 23:48:00 +0000

In the previous blog post, I have described some of the best practices that are worthy of consideration when designing robust off-boarding processes. Here I will go over possible implementation strategies for the first two bullets using Oracle Identity Manager (OIM) as a an automation platform. I'll cover the other two bullets in my next post.

1. Be Fast. In terms of timing, off-boarding should be executed as close as possible to employee walking out the door. What this means is that OIM needs to know about the termination event before it actually happens. One way to accomplish this is to allow incoming off-boarding events to contain a termination timestamp. The timestamp would signify a cutoff beyond which all access should be revoked. This way if someone is leaving the company or being terminated, the event could be entered in advance by, for example, someone in HR, and eventually pulled into OIM. Doing this avoids both the last minute rush to turn off access and potential data entry errors.

Let's say the event with a termination timestamp makes it into OIM on Thursday and the timestamp is set to Friday 5pm. Would OIM "wake up" at exactly 5pm on Friday and proceed with revocation or disable workflows? It may or it may not wake up at exactly 5pm. Much of the internal processing in OIM is triggered via built-in scheduled tasks (rough equivalent of UNIX cron) which run every so often. If a task runs every hour and the last run was at 4:59pm, the next run is at 5:59pm and you just missed an hour. Schedule for important built-in tasks could be modified so that they run at a higher frequency, say every 15 min, and this could cut down on the lag. (This implies mucking with internals of OIM, something Oracle discourages). It's worth noting that frequently running tasks (and their interaction with the database) may have a performance impact. Make sure to conduct a thorough performance test if you're going to be scheduling a lot of tasks to run at a high clip.

What if an upstream source of events cannot have a termination timestamp be set in the future? Some HR apps don't allow this type of logic. In this case you're at the mercy of the interface between OIM and the HR app (if the HR app is your source of events, that is). Usually the interface allows for reconciliation via HR app's API and reconciliation is triggered by a scheduled task. Rather than modify the schedule of a task (one option), a better option is to have the HR app push the events to OIM, either by calling OIM API directly or by using a service-based abstraction, the latter typically implemented as a Web service. This way the events will come to OIM as soon as they're generated by the HR app. The PeopleSoft connector for Oracle Identity Manager works exactly this way: events flow through PeopleSoft's Integration Broker to a SOAP-based web service that calls OIM APIs. (The web service ships as part of the connector).

2. Don't get stuck in traffic. Best-in-class off-boarding processes allow for exceptional circumstances where the IT portion of the process can be triggered in multiple ways via multiple channels. The classic option is to align the identity administration solution with HR so that whatever HR uses (PeopleSoft, Oracle HR, SAP, etc) becomes the authoritative source of people-related events. In Oracle Identity Manager this means reconciliation from HR or in some cases such as PeopleSoft a push of events by HR into OIM. That's a hard-coded channel which makes it impossible for anyone but a few people in HR to revoke one's access via OIM deprovisioning workflows.

At least two more channels should be available: a simple webapp that allows a bypass of HR and an administrative override. The latter option is almost always "there" since operations personnel are usually placed in OIM's System Administrators group which has permissions to do everything. (Hardened OIM deployments place admins into different groups altogether). It is probably worthwhile to note that these channels should also be aware of terminiation events, and preferrably in advance. In our experience this is typically done by a series of emails and/or reports.

Even though the administrative override is available, it does not imply operations staff will know how to use it. Oracle Identity Manager thrives on data-triggered workflows: one wrong step when filling out an OIM form and your off-boarding event may not amount to much. Thus, documentation of an admin override is very important so that guesswork is taken out of the process.

Taking up the case of the front-end webapp, it is strongly recommended for it to be bolted downwith only a few supervisor-level or higher people in each org unit (department or larger) authorized for access. This is where Oracle Adaptive Access Manager (OAAM) can add a lot of value by strengthening the authentication service without requiring cumbersome infrastructure with, for example, X.509 certificates and two-way SSL. The Adaptive Risk Manager (ARM) component of OAAM could be configured with rules that would prevent risky off-boarding transactions, e.g. an authorized person logging in at 2am from their Blackberry with a geo location of hundreds of miles away from the office (stolen device?)

In the ideal world, the webapp would mimic the HR app by submitting a reconciliation event with the same payload but differentiate itself from HR by changing the point of origin field included with reconciliation data. For HR, the point of origin might say "PeopleSoft", for front-end webapp the point of origin might be "Terminator WebApp". If webapp can mimic HR, there's no need to develop a separate interface / connector with its own resource and forms in OIM. (The policy question of whether people in org unit A should be allowed to off-board people in org unit B via the webapp should also be considered).

Seek and destroy

Deborah Volk — Mon, 25 May 2009 22:42:00 +0000

In recent local news that became national news, Abdirahman Ismail Abdi, a former employee of California Water Services Company ("Cal Water"), a local water utility company, attempted to steal $9 million from the company by wiring the money to a bank in Qatar. Fun facts:

According to Cal Water's website, they're the largest investor-owned American water utility west of the Mississippi River and the third largest in US. Their parent company, California Water Services Group is a public company traded on NYSE with 2 million customers.
The attacker allegedly gained access to computers belonging to two senior executives in two separate buildings at the utility to initiate and confirm three wire transfers
The attacker resigned from his job as an auditor (!!) of Cal Water. He came back a few hours later (now night time, after business hours) and was able to get into the building using his electronic key card which was still active.
The janitor saw the attacker using the computer and presumably reported to management which discovered the transfers the next morning. The money has been recovered, the attacker fled to Canada and has yet to be apprehended.

The pattern of attack is very similar to a Fannie Mae incident where the terminated employee attempted to plant malware in retaliation for losing his job. In both Cal Water and Fannie Mae cases, the attack surface remained large due to the ex-employee's access not being immediately revoked. In Fannie Mae's case, the access was logical (VPN/network), in Cal Water the access was physical (card key/building entry). Without seeing the court documents, I won't speculate how the attacker was able to gain access to the execs' computers but I wouldn't be surprised if he had privileged (superuser) access too. (Segregation of Duties is truly a fairy tale for many companies)

We cannot completely eliminate insider attacks but we can reduce the attack surface by following a few best practices:

1. Be fast. Carefully design the IT portion of the off-boarding business process that gets kicked off when an employee leaves the company for any reason, be it voluntary or involuntary. In terms of timing, off-boarding should be executed as close as possible to employee walking out the door.

2. Don't get stuck in traffic. Have you ever driven a car on a one-lane road? If you have a slow driver ahead of you (and traffic flowing in the opposite direction so you can't jump out), you'll be stuck crawling for hours. This analogy applies to processes too. Don't be stuck with a process that has a single lane - in or out. If you depend on an upstream business unit (be it HR, Facilities, Operations, etc) to tell you that a person left the company, you're going to be at their mercy. If they have an issue - someone forgot to enter the terminated date or entered it the next morning or misspelled the name or the process is paper based and the fax machine was broken or... - you have a bigger issue. Best-in-class off-boarding processes allow for exceptional circumstances where the IT portion of the process can be triggered in multiple ways via multiple channels.

3. Trust but verify. A typical off-boarding process relies on either a direct supervisor (or someone higher in the org chart) or someone in HR to kick off the process and in either case you've got an issue since the task is driven by a single human. People forget, go on vacations or fall ill, put things off (memo to procrastinators: Just Do It) and so on. You need a system of checks and balances, at worst a single control where an alarm will go off somewhere if the terminated employee hasn't been off-boarded. At best, multiple people in independent org units (e.g. HR and IT) will be responsible for off-boarding workers. If one of them sleeps on the job, the other will step in.

4. Seek and destroy. Physical access (entering gates, buildings, floors, offices) is just as important as logical access (entering network and various systems). Best-in-class off-boarding processes do not differentiate between physical and logical access. All access should be shut off immediately, all access factors (usernames/passwords, personal certificates, key cards, fobs, badges, plain old keys) should be disabled and/or taken from the employee and accounted for.

Points 1-4 above could be followed regardless of whether a company has deployed a sophisticated identity and access management solution. Having said this, automating off-boarding processes via an identity administration product such as Oracle Identity Manager (OIM) certainly helps. In my next blog post, I will cover aspects of implementing off-boarding with OIM.

Ask Identigral (Issue 4)

Deborah Volk — Fri, 22 May 2009 10:55:00 +0000

Better Living Through Chemistry

Deborah Volk — Thu, 21 May 2009 09:23:00 +0000

I have always loved the subject of physics, but I am definitely a macro-gal instead of a quantum one. A Newton over Hamilton kind of thing. As a result, chemistry was one of my least favorite subjects in school. Having said this, I recently found that chemistry might actually be helpful in explaining the complexities surrounding the movement of an employee throughout an organization

We start by modeling the organization as a closed system with many molecules, like the Finance molecule, the HR molecule, the IT molecule and so on. Since molecules are made up of atoms, within each departmental molecule we have our business atoms (HR Operations, HR Benefits, ...), and within each of these atoms, we have electrons, the worker bees. Life is pretty good for our molecules, they form and dissolve bonds freely, until some worthy event occurs. For example, addition of new, foreign molecules (new departments spring up) or heat (economic meltdown) are possibilities. Once the event happens, we've got electrons moving around (electron A saying to electron B - "I am transferring, good-bye!"). Too many electrons going one way or too many of them going a different way and you've got a disaster on your hand.

Similarly to the discombobulation that occurs at the (very) low physical level, organizational or self-inflicted changes in a corporation that trigger a transfer of an employee from X to Y are hard to handle in software, whether X/Y is location, org unit such as department, or a job title. Managing the employee's transfer process while making sure his or her access required to do the (old or new) job remains correct at appropriate checkpoints along the way is no small feat. It's not unlike trying to control a chemical process so explosions don't occur. The goal of the supporting cast in the transfer process should be protection of corporate assets while maintaining a high level of productivity. And in my experience, fortunately or unfortunately, productivity trumps protection. (Quantiatively, this gets into probabilities. Potential loss from a breach vs employee idling).

There are many strategies in representing job change/transfer events in the identity and access management world. A simple approach is to treat the transfer as a role change. Role-based automation on both the identity side and the access side is simple to understand and (relatively) simple to implement with the right tools such as Oracle Identity Manager and Oracle Role Manager. As the person changes jobs or transfers to another department, we automagically notice the event (thanks to our ever-vigilant HRIS), change the role and from there automation does the rest. Accounts are enabled or disabled, entitlements added, removed or changed, appropriate access is granted and the old, inappropriate access is revoked.

This is all fine and dandy for the transfer process that fits into role-based access control model (read: straightjacket) but what about exceptions to that? Exceptions are the way of life in people-focused processes. For example, in his previous (outgoing) job, the employee might have been granted entitlements by his manager on an exceptional basis, they are not part of employee's job responsibilities. Another great example and something that happens quite often is that the employee is going to be temporarily performing both the new job AND the old job while the organization is searching for a replacement. This seemingly innocent scenario turns into pure wickedness if you're working under the role-based model, although in all fairness I have to say that this is a function of implementation and tools used, some are more flexible than others. One more fun challenge is a so-called toxic combination of privileges that follow from a combination of roles. Coming from Segregation of Duties (that fountain of audit youth), a toxic combination of privileges is a situation where the same employee can write checks and approve checks.

An alternative way of handling role-based model and corresponding access conundrum is via attestation. Nothing is revoked on a transfer; no accounts are disabled, no privileges are removed, only additional items may or may not be granted to the employee. Someone then has to say (attest) that a person should keep their "old" access post-transfer. Unfortunately, this puts an undue burden on people, as they may end up having to attest to hundreds of entitlements. This is especially true if the notion of a "transfer" is defined as any job-related change.

There are many other strategies of dealing with transfers, but ultimately, it comes down to being able to harness the capabilities of identity and access management platform.

Give me federation or give me death

Deborah Volk — Wed, 20 May 2009 03:00:00 +0000

Once again, several threads coalesced and lead to this blog. The chief impetus was a question asked on LinkedIn about federated identity management. Since the term federated identity management is somewhat of a misnomer (and a broadside), we'll use an even less accurate but slightly more legitimate federation. To wit, the person asking the question was wondering if federation is "critical" and why organizations are slow to adopt federation for "cross-organizational access"

My response to the question was that federation is not critical and the reasons for slow adoption are mostly standard. It's a fairly new technology with a high level of complexity that requires very specialized knowledge to deploy. Moreover, deploying federation has a unique twist not seen elsewhere in identity or access management implementations. Instead of Oscar Wilde's "tyranny of the weak", we've got a situation more typical in the business world, "do as I say and say as I do".

The latter scenario plays out something like this. Company A has an internal intelligence service tasked with sending well-trained, combat-hardened and fearless pigeons to spy on the competition. The service is used by a lot of sales people, they interface with pigeons via Morse code. Prior to the move, the pigeons lived in the company's datacenter; empty server enclosures were recycled for nesting, effectively producing a very "green" space with low energy consumption. Alas, the pigeons were too costly to maintain. Besides food and water, they demanded training in latest crypto techniques and argued loudly (in Morse code) about pros and cons of Blowfish vs Twofish. All that tap-tap-tap unsettled the system administrators who had offices on the floor above the data center and rather than pay for psychological counseling due to stress, Company A decided to send the pigeons to a 3rd party provider (Company B) located on a small island in the Pacific Ocean. It is always sunny on the island with nary a cloud in sight.

Company A had an application that kept track of pigeons but Company B promised a better and shinier pigeon-tracking app with a web user interface that knew what you were going to type before your fingers touched the keyboard. Company A agreed to let Company B track the pigeons but it also wanted to know what the pigeons were up to so it asked Company B to allow Company A people to use Company B's application. To top it off, Company A did not want its users to be prompted for credentials by Company B, no sir, no how. Company A told Company B that (drumroll, please) "we are going to use federation to avoid impacting user experience". Company B didn't know what these ominous words meant, they're pigeon experts after all. They did what everyone else does in this situation, they hired a consultant. The consultant tells them that they may have to change the authentication (and potentially authorization) components in their app so that they can accept SAML messages from Company A. More expense, all for the convenience of a few Company A users who want to track pigeons. Company B decides to swallow the sword and bite the bullet at the same time and Do It.

What can be so hard about establishing trust between two parties and processing a SAML message, you may wonder? For the answer to this I will turn to real experts. Patrick Harding (CTO, Ping Identity), Leif Johansson and Nate Klingenstein (both Internet2) write in a recent issue of IEEE Security and Privacy on this very topic. To quote from the article:

SAML 2 is extremely flexible and offers many choices, but without much guidance about
what’s most appropriate. Today’s implementations generally do little to hide the resulting
complexity: administrators are often asked to provide answers to fundamental questions that
require deep insight into the SAML 2 standard. As an example, let’s review some of the points
that two organizations must address to successfully establish a federated connection:

How should trust between providers be managed?
How should information about providers (metadata) be provisioned?
Which SAML profiles and bindings should be used?
Which messages and what part of each message should be signed?
Which identifiers and attributes should be exchanged?
What are the semantics of those attributes and identifiers?

The article goes on to suggest a possible solution to the metadata exchange woes by making the protocol even more dynamic but I won't go there, I am scared. If a CTO from one of the top federation vendors and two very qualified gentlemen from an organization that gave the world Shibboleth (another federation Das Gift) think this is just a tad too complex, what are mere mortals supposed to do?

Last but not least, some of you reading this blog may wonder if I am not shooting our own company in the foot (pedestal?). After all, we get paid for helping customers figure out these issues and wouldn't it be better for us if the learning curve went from high to very high (Space Elevator high), we'd be in business forever. As much as I would love for us to be dealing with entities and metadata every day, we help our customers solve problems that are relevant to their business. Federation is a choice of technical architecture, perhaps an elegant one, but still a technical choice and it has an indirect impact on business at best. A few unique business cases aside where federation presents a competitive advantage, choosing one approach vs another is an exercise in humility. I'd like to think that if we can save our customers money they'd spend on us (among other things) by steering them into less choppy waters, we've done our job.

Use It or Lose It

Deborah Volk — Sun, 17 May 2009 21:22:00 +0000

This blog post is a continuation of Waiting at a Station where I talked about attestation and possible strategies of reducing its scope. The strategy I am proposing is to segment user accounts into active and dormant where the definition of dormant is set by audit guidelines or IT policy; dormant accounts can then be excluded from attestation. At its simplest (and for the sake of this example), we can define dormant as any account that has not been used since the last attestation. If we assume that attestation is done once a quarter, our definition becomes "any account that has not been used since the beginning of this quarter".

Making this definition become an actionable rule, we have to boil it down to data elements that we can interrogate. Really, we just need a single element - time of user's last login ("has not been used"). Once we have that, we're done with our rule and our segment. How can we implement this segmentation strategy? Let's examine several organizations with an existing attestation process but with different levels of maturity in their access management solution.

Orgs with no access management solution. Each application has its own authentication and authorization schemes, identity-related information is stored in application's own repository. (Marketers like to call this an identity silo). Applications have point-to-point integrations for exchange of data, e.g. if SAP needs to know about the employee's birth date, it asks PeopleSoft. Even though there's no identity and access management per se, attestation process does exist and our mythical El Caro Corp has been doing it every quarter for a number of years. It went from being completely paper-based to Excel to (drumroll, please) Sharepoint.

In this scenario, we have to retrieve the time of user's last login from the application. Each application will have an interface for extacting data and (potentially) its own unique way of representing the timestamp. Some apps might be relatively young and restless (breathless?), allowing you to query the data via SQL, while other apps might be ancient, requiring a COBOL program/call (Y2K anybody?).

It is certainly possible to catalogue all apps, their interfaces and data representations and write a Giant Perl Script That Reads Like a Thomas Pynchon Novel (sorry, Thomas). It would work and the suicide rate of developers having to maintain The Script may be low but it won't be zero. (I do occasionally wonder about Pynchon's editor...how does he/she do it?!). In the land of Perl scripts, the rule of thumb is "someone already wrote it" (and it's probably a one-liner).

If you're not afraid of scripting, there's a slightly better solution available - log extraction, sometimes billed as log analysis or monitoring or all of the above. The premise here being that many access front-ends such as web servers or secure proxies or network gateways or CFOs close to end of the quarter will log events to a text file in a semi-structured fashion. That's how log extraction got its started but that was a long time ago. Modern log analysis/extraction products such as Splunk do a lot more than read and parse text files, they've evolved to cover just about any interface and data format. These tools typically allow for quick customization by writing a script-like plugin (sometimes as little as a regular expression) so you can handle your app without reinventing the wheel from scratch (or semi-scratch for CPAN-savvy) in Perl. Log extraction and analysis is a capability found in many classes of security products; Security Incident and Event Management (SIEM) products can also do this. One popular Open Source SIEM product is OSSIM, for example.

In the somewhat-perfect-but-not-too-perfect world where all apps of interest to us (and there are very few, we're still attestation- and regulation-bound) have a database or directory as their repository of runtime metadata such as user sessions, we can use a data virtualization solution such as Oracle Virtual Directory to present a uniform interface with the desired data element(s). This way we don't have to bother with hacking through a jungle of different schemas to get the timestamp of user's last login, we have it neatly packaged and folded in one drawer.

Last but not least, I would be remiss not to mention the ultimate solution to all problems - reconciliation of access metadata via an identity administration tool such as Oracle Identity Manager (OIM). While more labor-intensive than writing a regular expression in Perl, the architectural rationale for this option is very strong IF we're managing our attestation process in OIM. If so, we could send last logged in timestamp right into process forms for SOX-in-scope resources defined for our users and have the attestation logic in OIM skip users that qualify for our dormant segment.

All of these options - scripting, log extraction/analysis, data virtualization - assume that application is keeping track of sessions. Some apps don't bother with recording the time of last login, an unfortunate and not altogether infrequent occurrence.

Orgs with Web Access Management (WAM) solution. All major WAM (read: web SSO) products have a capability for auditing user access. For example, Oracle Access Manager has a notion of an audit policy that allows the administrator to define what events are of interest (for audit), what information gets logged for each event and what application is the event coming from. There's only one problem with using a WAM solution for audits: it only deals with web apps. Sure, WAM tools come with all kinds of interfaces and in the olden days I've even seen enterprising WAM implementations where the app developers created an HTTP interface to a non-web app for the sole purpose of kinda-sorta including it in the web SSO scheme but let's be honest, WAM is all about the W.

Orgs with Enterprise Single Sign-On (ESSO) solution. I am tempted to use the term Enterprise Access Management (EAM) but we'll go with a more established ESSO. The advantage of deploying an ESSO rather than a WAM solution is that ESSO can manage all classes of apps, not just web apps. It can handle standalone (client-server, desktop) apps, web apps, green screens on a mainframe and so on. Wanna know who was editing your accounting records by opening a QuickBooks file at 2am on Sunday night? An ESSO product such as v-GO Single Sign-On from our partner Passlogix can audit that login for you even though there's no native auditing capability in low-end QuickBooks editions (but there's a password screen). Certainly deploying ESSO for a sole purpose of access audit may be overkill but combined with other drivers, closing the audit gap strengthens your business case.

Ask Identigral (Issue 3)

Deborah Volk — Fri, 15 May 2009 08:57:00 +0000

Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.

We want to use Oracle Identity Manager (OIM) to manage Active Directory (AD) passwords. However, an error message is only displayed if changing the user's OIM password fails. No error message is displayed when a failure occurs when changing the user's Active Directory password.

When you change a password through the OIM web UI (aka "web client"), it calls the tcUserOperationsIntf updateUser API. This goes and fires all of the pre-update entity adapters and then performs a transaction that involves update of the USR table. From the web client's perspective, the transaction is complete if it has been successfully committed all the way to the database. Once it's committed,all the post-update entity adapters fire. Since you are using the Trigger processes to propagate the password change to Active Directory, the error message is outside the initial updateUser transaction. This is why the error message is not seen on the web client.

Typical of OIM, there area number of ways to solve the problem. I would put your update to AD inside the updateUser call by using a pre-update entity adapter. The best approach would be to take the AD Adapter that changes the user password (ADCS Set User Password adapter in the 9.1 version of the adapter) and re-create it as an entity adapter. (You probably want to keep the process task adapter around too). Once you have the entity adapter done,you need to do the following in order to have the error message show up on the web client:

1) Create an Error Message Definition for the failure to change AD.(Remember the code has to start with ADAPTER. So the code of the EMD should be something like ADAPTER.ADPasswordNotChanged). Make the Action be Fatal Rejection. This will roll-back the transaction and will not write the new password to the USR table.

2) Put a check in your new entity adapter for the appropriate response and add a Logic task to handle the error. Pick your error code if the Java task returns the appropriate code.

3) Take out the Change User Password task in the AD workflow. You can do this in two ways: Remove the task name from the lookup (as long as AD is your only resource), or rename the task in the process to something that does not look like "Change User Password"

4) Also, since we don't want to write to AD for every change to the user profile (Xellerate User object), there should be a check at the beginning to make sure that the password has in fact changed.

Here is a screenshot of what this looks like after it's been implemented in 9.1.0.1 web client:

If you take this approach, you will have to make sure your adapter gets updated if the ADSC Set User Password adapter gets updated by Oracle in the next rev of the AD connector. However, this will typically not happen too much, unless they are trying to support different Active Directory versions. The other downside of this approach is that the process form for the Active Directory resource does not get updated. If there is a reason for the process form to get updated, instead of having the entity adapter go to AD directly, you could write some Java code to update the process form using the tcFormInstanceOperationsIntf API.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc.

Waiting at a Station

Deborah Volk — Wed, 13 May 2009 23:45:00 +0000

In a blog post a few days ago, I wrote about the parallels between Security Information and Event Management (SIEM) and Identity Administration solutions. In both cases, when an event comes in from an external system, there are rules that evaluate the event. If the event is deemed to imply a threat (in SIEM case) or a compliance issue such as a rogue account that could lead to a threat (in Identity Administration case), I wondered about possible actions that could be taken without involving a human. In this blog I'd like to examine a related premise and do it from a gentler, kindler perspective of a business process known as attestation where humans play an important role.

Before identity administration tools grew up to be 6 feet tall and started sneaking out at night, attestation the process had already graduated from college, bought a car, got promoted to sous-chef and was about to pass the baton to the next generation. The term attestation came from legal jargon in accounting. In the accounting world, attestation refers to "an assertion about subject matter that is the responsibility of another party", someone vouching for you, in other words. Given the love affair in management consulting between accounting and IT, attestation infiltrated the fertile field of IT audits. There, the definition of attestation stretched out to encompass the entire process of gathering information about stuff and having people sign on the dotted line that the stuff is indeed good stuff.

As identity administration products matured and gathered steam, attestation went up into their crosshairs and reasonably so. Attestation is a recurring process, typically quarterly but sometimes as frequent as monthly, involving people from multiple departments, not to mention a sizeable IT data collection and correlation exercise that relies on a myriad of spreadsheets and scripts. Instead of hearing soothing words such as "accretive acquisition" a CIO or CFO would hear "recurring expense" and "can you give us directions to the tree that grows money". This is like waving a red flag in front of a charging bull. Reducing the expense of an IT audit, attestation being one of the key processes backing the audit, is every CFO's dream.

How do you reduce the expense of attestation? The top expense is human labor so you want to automate many of the attendant tasks done by humans, such as data collection and reconciliation from external systems in audit's scope. Automation is best done by an identity administration tool such as Oracle Identity Manager. The data collected can be anything but it's typically user accounts and associated entitlements. Once the reconciliation is done, someone has to attest to the fact that Barry O. Bama is still an employee and he still needs his superuser account on a UNIX server whitehouse.gov. That someone is typically the person's manager although if segregation of duties is implemented in a strict fashion, the attester is not the manager. (Look at Barry, he's got nine attesters that are not his managers). Taken together, if an employee has 20 accounts with 5 of those are on auditable systems and there are 5000 employees, that's 25,000 attestation events every quarter. Big, expensive headache.

It is, therefore, desirable to reduce the scope of attestation. You can't decrease the number of auditable systems but perhaps there's a way to decrease the number of user accounts or entitlements to attest. Instead of doing a blind sweep of everyone and their pet koala (only at Google, folks), we could consider dividing our population into two segments: active users and dormant users. Dormant users would be defined by an audit-blessed policy such as "everyone who hasn't accessed the system since the last attestation". The active users is a riskier segment, who knows what they've been up to on a target system. The dormant users have been vetted and if they haven't been naughty since the last outing, why require a check?

One reason to check dormant accounts is to have a human attester verify that the user is still alive and well and he still needs the account or entitlement. If he isn't alive or he no longer needs the account, the attester could choose to trigger the disable workflow. This is a good but unnecessary reason from a risk perspective. After all, attestation is about mitigating risk and if the user hasn't uttered a peep since the last attestation, there has been no plausible increase in risk (digging tunnels a la the Count of Monte Cristo excluded). Disabling the account might free up some infrastructure resources but the expense of the entire process that leads to the disable event is much greater than the benefit gained. Unfortunately, most IT auditors view dormant accounts as a riskier segment than active accounts although the rationale behind such view is not clear to me.

If dormant/active is our (admittedly simple) segmentation strategy, how can we place users into either segment? Some auditable systems may not keep track of when the user was last seen on the system. In my next blog I will examine some practical approaches to recording and extracting data related to users accessing the system.

The KOL Miner's Daughter

Deborah Volk — Mon, 11 May 2009 19:34:00 +0000

Just when you've escaped from your past, it comes back to haunt you, something about learning from history and being doomed to repeat it. I had every intention of doing a blog post about identity management challenges associated with implementing business processes having to do with internal (employee) transfers but when worlds collide, singularity happens. Prodded by the announcement of an improved Twitter search, Oracle's Nishant Kaushik writes about the new "identity equation" This comes only two days after a blog on the very same subject by a former colleague of mine, Endeca's chief scientist Daniel Tunkelang. Two blogs, two completely different perspectives. It seems the world is all atwitter (pun intended) about the wealth of information Twitter has to offer (MONEYtization, anyone?)

These two blogs reminded me of a problem I worked on briefly soon after I started Identigral. Given a large body of information that may include everything from blogs, news articles, conversations on Twitter (then yet to be born), to published and peer-reviewed research, how do you identify people whose opinions carry weight. This problem is especially potent in the pharma industry because physicians who are (more) respected by their peers can help product sales by mere advocacy, not to mention a more concerted effort. Both bottom-line (marketing dollars) and top-line (revenue) is impacted and there's a small cottage industry oriented toward solving this problem in pharma. This challenge even has a name, it is known as Key Opinion Leaders (KOLs).

KOLs is not something new, it's been around for a long time but methods and techniques have evolved along with decreasing cost of computational power, thus making it easier to construct a decent solution at a fraction of the cost. Twitter makes this more interesting, because now instead of having a bunch of doctors talking about clinical trials, you have doctors, engineers, teachers, kids, all 140-charactering about their aspects of the same problem (did this miracle cure work?), muddying the water and making data mining algorithms sweat. (They secrete residuals).

Nishant is correct in stating that reputation will need to have a context, just like Key Opinion Leaders have their sphere of influence. Just because you can teach a class on theoretical physics doesn't mean you know how to fix my car. On the other hand, even if reputation is context-based, it doesn't necessarily mean the search result will be relevant. If I am an Oracle Identity Manager (OIM) expert, when I search for "OIM" on Twitter, should I see OneInchMan's (who uses the Twitter tag #oim) thoughts about psychedelic music or should I see Nishant's announcements of recent Oracle whitepapers? Perhaps Twitter should prioritize the search results for me by putting Nishant before OneInchMan. Two KOL's, two different worlds but the "right" answer would be based on the context of my search in relationship to the KOL's sphere of influence, including historical data (past tweets) as fodder for algorithmic scoring of intersection between the two.

We now return back to our regular programming...

Meet Stanley Ipkiss

Deborah Volk — Sun, 10 May 2009 23:40:00 +0000

A few weeks ago a blog post by George Hulme on Health Information Trust Alliance (HITRUST) community site caught my attention. In his blog George talks about data breaches in the healthcare realm and how they are hard to prevent even if various data protection technologies are implemented. George wonders if data masking can reduce the frequency of data breaches where the primary attack vector is theft of data from non-production environments and I wanted to examine this premise in the context of implementing an identity administration solution with a product such as Oracle Identity Manager.

Data masking is an umbrella term for techniques that transform data without changing relationships within the dataset. Masking is particularly useful when applied to sensitive data in regulated environments such as healthcare since exposing protected health information (PHI) is an obvious risk. The chance of exposure is exponentially increased in non-production environments since many organizations typically copy production data at least one time to a staging environment although some articles cite 6-8 times as the common replication factor of a single production dataset across environments. Given that a greater number of insiders have access to non-production environments and controls are typically lax (or less stringent, ok?) outside of production, we've got a double whammy when it comes to risk.

A simple formula for assessing Risk is Probability of event multiplied by Severity of event. The probability of an insider having access to personal data housed in a non-production environment is high. Not only that but there will usually be a higher number of non-employees that make up the insider population with access to non-production data. If we assume that non-employees are a higher risk group, our Probability goes up from high to very high. The severity of data loss (breach, theft, leak, sprout, what have you) is also high in regulated environments, be it HIPAA, SOX or one of other 50+ regulatory frameworks if we go around the world (this is a real number, folks!).

Even with this simple formula, it follows that reducing the Probability of an event via data masking when copying data from production to non-production is a Good Thing™. The challenge with data masking when deploying an identity administration solution is that some fields in our dataset are used to establish relationships with other systems, rendering the masking exercise for these fields useless. For example, in a solution implemented on top of Oracle Identity Manager, reconciling records from an external system to OIM relies on matching rules that establish equality between external records and OIM records for a given identity. Frequently the matching rules are very simple, it's one rule that looks at some key field such as a login name on external system and a user ID in OIM. If the value of this key field is not sensitive (i.e. the field does not contain your passport serial number, for example), it doesn't need to be masked and our reconciliation will continue to work. If it is sensitive and we do mask it, we break our reconciliation process since matching rules will not establish equality even though the records do refer to the same physical person.

A possible solution to the above dilemma is a piece of software (let's call it a Data Broker) that sits between the applications and the identity store, the latter being a database in Oracle Identity Manager deployment. For applications connecting to the identity store and authenticating via an application account, the Data Broker will return data unmasked, for everyone else it will mask it. The masking would have to be done on-the-fly and in real time. If we want the Data Broker to reside at the lowest possible level in our application stack without going down to the network layer, we're talking about Data Broker that's attached to, well, data and resides inside the identity store itself. One possible implementation of our Data Broker for Oracle databases is Oracle's Virtual Private Database (VPD). Even though VPD is primarily a row-level security solution, it includes simple masking and column-level access control features and it resides at the database level. (Oracle has other products that specifically deal with data masking but our emphasis here is on access control).

However, VPD or any other implementation of Data Broker is far from perfect for our scenario. For one, there's a potential performance overhead, even if present only in non-production environments. Worse, once the application gets a hold of the data, it can log it, print it, send it to the console and so on. In other words, just because we've stopped developers from being able to hit the database and grab the sensitive data, we haven't addressed the root cause, i.e. source data being unmasked. Yes, we reduced the Probability of an event but not by a whole lot as any developer working with the application would easily circumvent the restriction by having the application grab and expose data.

A close-to-good solution would combine access control and DRM for data regardless of where data lives or how it's represented. Even if data ends up being transformed to, say, objects in application memory, it would still "know" where it came from and how to behave. As a first step, we restrict everyone but applications from getting unmasked data in non-production. As a second step, we allow the applications to retrieve unmasked data but we attach a usage policy to the data. This policy would prohibit the application from sending the data to the log or using it in any context other than manipulations in memory. This would restrict the Probability of a leak even further but not completely eliminate it. Memory can be examined too, an attack known as memory space snooping. There are solutions for that but I digress! (Note: the access control+DRM solution is imaginary, I don't know of any products that do this).

Good solution? Don't store sensitive data in your identity management database. If you do store sensitive data, don't use it for establishing relationships with external systems, then it can be masked when exported to non-production environments. The latter is a hard issue - either you need to use a field for integrating with external system or you can't integrate...but there's a light at the end of that tunnel. The light is called a risk acceptance form signed by the CIO to save you from going to jail in the event of a data breach.

Perfect solution? Meet Stanley Ipkiss:

Ask Identigral (issue 2)

Deborah Volk — Fri, 08 May 2009 10:28:00 +0000

Ask Identigral (tag, category) is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we're striving for in our blog. Since Abby isn't very good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.

Question: I am trying to use Deployment Manager for importing my prevoiusly exported XML file into another Oracle Identity Manager instance and the Deployment Manager freezes on the last screen. Is there a restriction on the size of XML? I am using OIM 9.0.3.

Signed, Still Migration Stumped

Answer: Deployment Manager does not have a size limitation but I've seen large XML files cause problems. Here are some tips for troubleshooting frozen Deployment Manager:

1) Since Deployment Manager uses a Java applet on the browser side, you have to be careful with browsers and JREs. Officially (certification matrix in release notes), only Internet Explorer 6.0 SP2 is supported with OIM 9.0.3.x so try that first. We have users successfully importing and exporting via Deployment Manager with IE 7.x, Firefox 2.x and 3.x and even Chrome but when you're in a jam, best to go with supported config.

2) Assuming you've got the right browser and it still hangs on the last screen, look at the JREs installed on the machine where you're launching the browser from. The browser could be an issue but the most frequent cause of Deployment Manager hanging is the JRE. In the case of Sun JDK, when you install the JDK, JRE is installed separately, even if both JDK and JRE are shipped in the same installation bundle. You can uninstall a Sun JRE without affecting the JDK. Uninstall all JREs except for a single 1.4.2_xx JRE. As bizarre as this sounds, I ran into issues with Deployment Manager where the minor version of JRE actually mattered and I recommend 1.4.2_16 . Perhaps the root cause of the problem wasn't due to the difference in minor version, I didn't troubleshoot all the way, but going to _16 worked for me.

Before uninstalling the other JREs, you can verify if the issue has to do with JRE by pulling up the Java console when you start Deployment Manager via OIM web UI. In the Sun JRE Java console, you can activate debug mode by hitting 5. If you see error message with "Bad magic number", the issue has to do with a JRE version and multiple JREs. (If you don't see this message, I still recommend this procedure, the message merely makes the case stronger). Even if your browser says it's using a 1.4.2_xx JRE, uninstalling other JREs helps. For those who want to play it really safe, uninstall all JREs, then install a single 1.4.2_xx JRE. You don't need to reboot,restarting the browser is good enough.

3) You've got a single JRE on a supported browser and it still hangs. Sometimes the large size of an XML file can be a problem. I've seen two variations of this, one is a network-based restriction and one is a Deployment Manager issue. Somewhere along the way there's a network component (or web server or some other component) that restricts the size of data being transferred, usually as a measure of prevention against floods or denial-of-service attacks. In this case, you want to make sure your entire XML is actually getting to the Deployment Manager.

The other variation is Deployment Manager choking on a large XML. The solution is to break up the export into smaller chunks and then try the import again.

---

What if you can't even get your Deployment Manager to launch? I would use the right browser and make sure you haven't disabled the pop-ups, blocked Javascript orprevented Java applets from loading. If your OIM instance is protected by a web SSO tool such as Oracle Access Manager or Siteminder, thenmake sure that relative URL /Nexaweb is allowed by your SSO policy.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc.

Segregation of Duties - Panacea or Pandemic

Deborah Volk — Wed, 06 May 2009 23:46:00 +0000

Recently I have been exploring the new APIs that came out in Oracle Identity Manager 9.1.x and what they can do for our customers. Most exciting are the new reconciliation APIs. For any company that views compliance as a raison d'etre of their identity management system, reconciliation must occur. Audit and reporting are aspects of compliance that require reconciliation. From a business perspective, it doesn't matter whether reconciliation is done under the auspices of the software product or by an IT group that gets together nightly for cappuccinos and crackers while comparing source systems or by monkeys hitting random keys.

Even though reconciliation ranks as #1 or #2 in terms of priority in most identity management implementations, the out-of-the-box tools for managing reconciliation events are sorely lacking. Customers with extensive reconciliation needs fill in the gaps on their own; witness Yale University's custom application for dealing with various types of mismatches. (The challenges of implementing identity management in higher ed are somewhat unique but I digress). Perhaps these new APIs are clues to a new and wonderful set of 21st (!) century user interfaces to be released in Oracle Identity Manager 9.2 (11g) or perhaps not. If you don't want to wait for 11g, you can take advantage of these APIs yourself and we've done some interesting work with them for customers on OIM 9.1 (contact us for a demo).

While engineering a better solution after a few rounds with reconciliation APIs, I ran into a logical challenge. One of the main selling points of reconciliation is the ability to detect rogue accounts on target systems. With these APIs, we can finally start delegating management of reconciliation events to the "appropriate" people. If a reconciliation event for a rogue account comes in, it's an orphan event. That is, it cannot be linked to a known identity since, well, it wouldn't be rogue if it had a known owner! I decided to make orphan reconciliation events be attestable by the application owners (delegation to the "appropriate" people). After all, usually it's the application owners who truly know if an account should or should not exist.

My assumptions (based loosely on many real-life requirements and processes) started to break down in some of my use cases. Along with knowing if an account is valid or rogue, application owners usually have the ability to either approve the creation of a new account or force the change of an existing account on the target system. This creates a logical puzzle having to do with Segregation of Duties (SOD). Can the attestors actually be the approvers of requests for (or creators of) rogue accounts? How about any accounts? I would like to know if there exist organizations out there with a policy or procedure that differentiates the approvers from the attesters, requiring these two roles be played by different people. I believe that for the most part companies in fact have an opposite policy, the approver and attester is usually one and the same person.

In this era of compliance or jail and Segregation of Duties as the holy grail of compliance, it becomes apparent that companies are going to need people with an in-depth knowledge of systems... yet without the power to do anything on those systems. A read-only system administrator is a good description. In this economy the cost of this type of organizational segregation where you have administrators who know the system but can't touch the system might be prohibitive, thus leaving the risk to be unmanaged.

Ask yourselves this: is attestation a check that mitigates insider threats or is it merely an acknowledgment of trust between an organization and the attester?

Action-Reaction

Deborah Volk — Tue, 05 May 2009 22:56:00 +0000

One of the nice-to-have benefits of implementing an identity management solution is the ability to know what's going on inside a target system. If someone creates an account on the target and the account violates an IT policy or procedure (thou shall not create accounts directly without going through Oracle Identity Manager), this fact is quickly discovered during reconciliation (if it's smart enough!) and/or subsequent review of reports. This problem of so-called rogue accounts is encountered very often and we've engineered many a solution for it for customers. (Naturally all of our solutions are very smart).

Rogue accounts may carry a linguistic negative charge but in the context of identity administration, a rogue account is not necessarily malicious, it's simply something that shouldn't be there based on some rules. The rules may be formal (IT policy) or informal (that guy with a scythe and a pitchfork said so). Many rogue accounts are not created by evil insiders seeking to materially alter the company's financial statements, they're mistakes or what I call oops-conveniences of operators. Identifying a rogue account is easy in programmatic terms. The challenge lies in flushing out the business rules and a myriad of exceptions for various accounts that illegitimately exist on the target system and naturally are declared VERY IMPORTANT TO THE BUSINESS. It doesn't matter that last time they were used was in 1984, they're there just in case a nuclear attack happens and we all have to go to the bunker. When we emerge from the bunker 20 years later, the accounts are alive and well, voila!

Let's pretend we've got all the rules and exceptions documented, we run a reconciliation and oopsie daisy, we've got a rogue account! This is a Las Vegas moment when you've hit the jackpot - bulbs start flashing, floor is shaking, music is blasting, people running with fire extinguishers and throughout this cacophony you have to remember to scoop your winnings and go on living. What do you do with the rogue account, what action do you take? (If this was Vegas, I'd surely double down). Opinions radically diverge from this point.

One approach is to notify people, usually send an email to a mailing list hoping that someone is going to be awake at 3am and burning with desire to investigate. This approach is boring but safe...or is it? Consider the now infamous case of Fannie Mae. One of their contractors was terminated on a weekday at 1:30pm. He wasn't even walked out of the building although that's a subject for a different post. Not only he was still in the building with his laptop, his access wasn't revoked until later in the evening on the same day, giving him plenty of time to launch an attack. What does termination have to do with rogue accounts? If immediatley revoking someone's access upon termination is considered a best practice, why should rogue accounts that carry as much (some might even say more) destructive potential be left untouched after discovery.

This leads to another approach: automatically shut off the account upon discovery. This approach is not very popular because of what-ifs. What if the account belongs to a VIP (who asked the administrator to circumvent a policy and create one just for him..) ? What if the account is used by a REXX script for talking to a mainframe noone even knows exists (yet it runs the company's payroll..) ? What if, what if, what if. The root cause of what-if-itis is company culture. Many organizations blindly preaching the mantra of "IT is at the service of the business" don't realize the hidden cost of saying "yes" without reservations to any business request. What would you prefer - a mechanic that will gladly replace your transmission with a new one (since you asked about the knocking noise) or one who will try to convince you that some noise is to be expected, all you need is a tune-up.

Fortunately or unfortunately, safe but boring (amplified by what-if-itis) trumps aggressive any day of the week in just about every business...unless you're Fannie Mae. This is where insurers make their money by weighing the odds but they've got statistics and past history whereas we're operating on very few data points, the rest is heuristics. What's more risky - increase the likelyhood of an insider attack by leaving rogue accounts up to somebody in operations and hope lightning doesn't strike or shut off the account and hope you still get to attend the free yoga class in the morning after that angry VIP finds out it was you.

Is there a middle ground between these two extremes? Yes..but it's hard to navigate. This blog post was brought on by several threads about SIEM tools and their ability to automatically respond to threats. Marketing: SIEM threat response is the best thing since sliced bread. Reality: very few deployments use the automatic defense response mechanism because of issues, false positives being #1. False positives exist because there's either not enough data to make a decision, not enough semantic power in the threat model (rules, analytics, what have you) or simply not enough knowledge contained in the threat model.

This introduces the question: given the ample information stored in the identity administration tool's repository about one's identity, resources that belong to the identity and history of events across the resources for this identity, is it possible to create a threat model that would allow for a low false positive rate when shutting off rogue accounts? Discuss in comments.

Authorization in Oracle BI Server (OBIEE)

Deborah Volk — Tue, 05 May 2009 02:16:00 +0000

Oracle Business Intelligence Server (BI Server) is a server product in Oracle's Business Intelligece Enterprise Edition Plus (OBIEE) suite. BI Server stores metadata such as business models in its own repository. Naturally, access to various repository assets needs to be secured. User accounts can be defined explicitly in an Oracle BI repository or in an external source (such as a database table or an LDAP-compliant directory server). Authenticating to an external source is a matter of configuration. Next comes everyone's favorite challenge - authorization.

BI Server uses groups as authorization principals, i.e. membership in a particular group equals access to stuff . Each group can contain explicitly granted privileges or privileges granted implicitly using membership in another group. Users can also have privileges granted through membership in groups, that in turn can have privileges granted through membership in other groups, and so on. (Sounds like a nightmare I had about recursion: I kept having a dream within a dream within a dream...) The challenge is twofold: 1) getting groups into BI Server 2) assigning users to groups.

One option for getting groups in is to define them from scratch in BI Server and manually assign users to these groups. The problem with this option is scale vs effort. For any sizeable deployment of OBIEE with thousands of users, defining groups from scratch is tedious but doable; putting users into those groups is a kiss of death. The conversation between business departments who will be consuming BI services and the IT folks standing up the infrastructure will go something like this:

Business User: I would like to run a report showing the monthly charge-offs segmented by sales territory and geography.

IT Architect: Sure thing. What groups do you want to have access to this report and what people need to be in those groups?

Business User: Everyone in dept 123 in sales territories A, B and C with manager title or higher.

IT Architect: We don't have such a group..

Business User: ...but I have it in Siebel!!

In other words, somewhere in the enterprise there exists a repository of users and their membership in one or more hierarchies (organizational, geographic, function-specific such as sales territories). In organizations that have deployed an identity management solution, this repository is usually a directory with an LDAP interface. (In organizations that haven't bothered with identity management, Active Directory with 300,000 groups is often encountered as a bottomless catch-all tar pit).

Assuming a directory (clean or stuffed with excess groups) exists, it would be desirable for BI Server to use the groups and users' group memberships already defined in the directory. BI Server gives you 1/2 of this - you can import users and groups but not users' group memberships from the directory into BI Server repository. Once you've imported users and groups, you still have to go through the exercse of assigning users to groups. Moreover, consider what happens when a new employee is hired or an existing employee fired (new user is added or removed from the directory). You have to re-synchronize the BI Server repository with the directory and do so on a regular basis. Ouch.

If we can't point to a directory, what can we do? The BI Server's solution for the authorization problem is a lowest-common denominator: database table. That is, you can point the Server to an external database and get the users, groups and users' group memberships from there. Crucially, the Server does not expect an actual table, it merely needs a result set in a certain format from a user-supplied SQL statement. The SQL statement does not have to hit the database, it can manufacture the results for all the BI Server cares. So we need to make our directory look like a database table...kind of like virtual directory but in reverse. This leads to a "classic" solution for those developing with databases - PL/SQL stored procedure that calls the directory via DBMS_LDAP package! Some might call this solution clever, others might call it an ugly kludge. (I've got one foot in each camp). The BI Server calls the procedure during session initialization so that the user's groups come across whenever he logs into the BI Server. No need to synchronize anything.

This works but surely there must be a better way of doing this. The root cause is a product limitation and BI Server will definitely solve it at some point. Meanwhile, the best option is to deploy an identity administration solution such as Oracle Identity Manager (OIM). This way you've got all 3 sets of data covered: 1) Users 2) Groups 3) Users' group membership. OIM can provision users and groups to BI Server repository (separate schema is best) and it can also put users into the provisioned groups inside the BI Server repository. OIM can do it based on one or more sources, be they a directory, an HR master such as Peoplesoft or Oracle HR or SAP or a combination thereof. OIM will keep BI Server's repository up-to-date with respect to these master sources and the BI Server can do authentication and authorization against it. This achieves the goal of using one, or more authoritative sources for storing users, groups and memberships and having any changes be propagated from there to the BI Server.

Problem solved? This is just the beginning. For a measure of the real problem, think about access control as a function of entitlements.

Ask Identigral (issue 1)

Deborah Volk — Mon, 04 May 2009 02:02:00 +0000

Ask Identigral is our answer to Dear Abby. According to Wikipedia, "Dear Abby ... is known for its uncommon common sense and youthful perspective", two qualities we strive for in our blog. Unfortunately Abby is not very technical, I keep wanting to cross her with Walt Mossberg of Wall Street Journal but this will have to wait until next century. Since neither Abby nor Walt are any good when it comes to identity and access management products' arcana, I together with the rest of Identigral staff have decided to step in and close the gap. Email us your questions about any Oracle identity or access management product(s) and once a week we will post the answers here.

Question: I was moving a resource from one Oracle Identity Manager (OIM) instance to another instance via deployment manager. The import failed part of the way through, and now I have a process form with no columns.What do I do now?

Signed, Migration Stumped

Answer: Moving assets from one OIM instance to another OIM instance is not a 100% bulletproof process, errors are sometimes encountered on import. There are several things you can do:

1) Check the logs to see what failed. Sometimes it has to do with foreign keys on tables missing, sometimes it has to do with objects already existing in the database. If the depoyment manager subsystem logging is turned off, turn it on and make it verbose (XELLERATE.DDM set to DEBUG)

2) Check the XML to make sure there are no extraneous objects being imported. Take everything out of the xml except the process form (and make sure the columns are listed!). I highly recommend an XML editing tool such as XMLSpy or Stylus Studio to do this.Try the import once again after you have cleaned up the xml.

3) If all else fails, you will need to back out your changes. Warning: perform the following at your own risk and only if you are an expert in OIM schema. The process form can be deleted from the database by deleting the relevant row from the SDK table. The database will make sure you remove all references to the row first.

Here are some best practices when dealing with OIM's Deployment Manager:

- Read Chapter 1 of the Best Practices Guide - it has extensive coverage of Deployment Manager.

- Do small imports, and always start with the objects that can live by themselves without any dependencies (you can have a group without anything else, you can have a process form, but only with admin groups, etc)

- Always check XMLs to make sure that extra objects haven't been carried along. For example, if the person who creates a process form is in 10 groups in the dev environment, those 10 groups get attached as Administrative groups on the form. Then those groups get carried into the next environment.

Have a Question?

Send your questions to ask@identigral.com and we'll do our best to answer. Please use your work email address - no GMail, Hotmail, Yahoo, etc.

Generic Connector and the Temple of Doom

Deborah Volk — Fri, 01 May 2009 14:25:00 +0000

The City of Atlantis. The Holy Grail. The Philosopher's Stone. The Perpetual Motion Machine. The Generic Identity Management Connector. This is the stuff of legend with folk tales reverberating through the ages. (The rise of scientific method during Renaissance with empirical evidence as a way of learning? An early example of reconciliation). Building connectors for customers and trying various frameworks as a way of decreasing the cost of creating a connector, I've been thinking about the notion of a generic connector

Connectors have always been the bane of any identity management solution. Without a way to understand or influence external (target) systems by, well, connecting to them, the business value of an identity management solution amounts to little. Therefore, connectors are a must-have...but the number of target systems found in the wild across all customers is large so it becomes impractical to build a connector for each individual target. This is where the analysis of what makes a connector tick becomes interesting.

Each target system is indeed different but there are degrees of difference. The difference between the two systems could be very small or very large. For example, two Oracle databases with the same structure are two different target systems but the only difference between them is the server they're hosted on. This is a small difference. Another example is having two databases, one a relational database such as Oracle and one a hierarchical database such as IMS. Being able to connect and retrieve data from a relational database will get you nowhere when you try the same approach on a hierarchical database. This is a large difference. How can we build a connector (with or without an underlying connector framework) that would allow us to quickly adapt it to a variety of systems while minimizing the effort having to do with differences between these systems? This would be our generic connector, the One-Size-Fits-All-And-Cooks-You-Breakfast Connector.

Thor Tech engineers working on Xellerate product (later acquired by Oracle and rebranded as Oracle Identity Manager) had a Eureka moment. Instead of tackling a problem of identifying all possible differences between target systems and building connectors that encompassed these differences, they partitioned the problem into two halves. One half would deal with procedural differences and the other half would deal with a technical specification having to do with a low-level integration details and protocol(s) for talking to the external system. A procedural difference can be illustrated when creating a user account in LDAP-compliant directory with one directory being Oracle Internet Directory (OID) and the other directory being Active Directory (AD). Even though in both cases we've got LDAP protocol as our "neutral" communication and data/command description substrate, the steps for creating an account in AD and OID are not the same since the container hierarchy in two directories and the placement of entries in the hierarchy are wildly different.

Having the problem consist of procedural and integration steps allowed Thor engineers to allocate these steps to two different components in Xellerate. The integration logic and all low-level technical specification details for talking to another system would live in Java code. The procedural logic having to do with needs of a particular workflow could live in the Java code or it could be be built in a visual composition environment proudly called the Adapter Factory. The idea behind Adapter Factory was that someone who knew the target system well but didn't know how to code (read: that elusive IT "business analyst") would be able to put together the steps for completing the transaction by clicking on various UI widgets. The Adapter Factory would then
generate the Java code underneath the hood. Here are the default (out-of-the-box) steps for creating account in OID as seen in the visual composition environment of the Adapter Factory:

The other Good Thing™ about the Adapter Factory was that each step in the above procedure could talk to another adapter or a pre-built piece of Java code (or a stored procedure or ...). This would allow organizations to use already written components for integrating with, say, Siebel or Peoplesoft and have the analyst configure the procedure (build the adapter in Adapter Factory) that used these components. Since adapters could talk to adapters, one could create reusable building blocks as small or as large as one would like. A small block could be creating an entry in LDAP, a large block could be creating a user account in Oracle database. This is an example of a Composite design pattern, taken to extreme by frameworks such as Qi4j and labeled as Composite-Oriented Programming.

On paper, the ideas and goals of Adapter Factory are fantastic. The implementation of these ideas is, unfortunately, a different story. It takes one some time to reach a comfort zone where clicking on this or that dialog in Adapter Factory becomes second nature. The visual composition UI is rooted in programming idioms closely resembling Java. While no programming is required, you have to understand the concepts of flow of control, loops, parameter passing and so on, few non-developer IT/business analysts would be able to handle this. The UI is slow and most people don't know how to achieve optimal results, creating poorly performing (slow or memory-hog or both) adapters. Since developers can't get the Adapter Factory to work they way they think, many OIM implementations end up with code, code and more code (unless you've hired Identigral, of course) . This drives up the implementation and maintenance cost.

If code generated by Adapter Factory coupled with pre-built or built-to-order code couldn't solve the Generic Connector Problem, maybe another approach would work. Oracle's solution was the Generic Technology Connector (GTC), a combination of architectural foundation/framework and (somewhat) generic connectors. The GTC framework allows developers to create reconciliation or provisioning providers for target systems. The GTC framework provides a standard roadmap and APIs for how providers should be developed; this fits well with the developer mentality. The GTC framework has a somewhat heavy footprint for small(er) tasks. If all you want to do is create a row in a database using a particular SQL expression that isn't supported by the out of the box database connector, you've got to do a fair amount of legwork.

Are there other approaches for genericizing a connector? Back in the olden days when identity management was still a nascent buzzword, provisioning was something out of a military jargon and reconciliation was strictly for accountants, Trulogica (acquired by HP in early 2004 for OpenView portfolio) tried to hang connectors on top of J2EE Connector Architecture (JCA) spec. For those not familiar with JCA, this was kind of like requiring a rocket engine for building a small model plane. Needless to say, this didn't work very well.

The most recent attempt at a generic connector solution is courtesy Sun. They've taken what I consider to be the most innovative approach with their Identity Connectors project. The project is an Open Source initiative whose goal is to produce connectors that can be easily decoupled from the applications using them, thus allowing easy replacement and substitution. Right now the connectors and the framework are very Sun Identity Manager-friendly, it would take some effort to make them work in a different identity manager product but the future is (potentially) bright.

Back to the original thought: Do you all think that it's possible to have a Generic Connector?

Provisioning Active Directory - Best Practices

Martin Sandren — Mon, 27 Apr 2009 21:58:00 +0000

After the very popular Suncle series covering the Sun/Oracle identity and access portfolios, the blog went on a brief hiatus but we're baaaaaaack. Instead of giving y'all yet another dose of Identigral, we've got Martin Sandren as our guest blogger today.

Martin is a security architect at Genzyme in Boston. Prior to joining Genzyme he spent four years implementing Oracle Identity Manager for Sena Systems in both US and Europe. Martin is originally from Sweden where he received his Masters degree in computer science from Chalmers University of Technology. He also lived in Germany and the UK. You can reach Martin via LinkedIn or Xing.

---

A recent entry on Identigral blog talked about about managing entitlements instead of just managing the relationship between the entitlements and the users/roles. This sounds great, but how does this actually work in practice?

For our example, we will use Oracle Identity Manager (OIM), Active Directory (AD) and the OIM connector for Active Directory. In the series of articles on the subject I will illustrate an approach to extending the connector and using OIM framework such that it will go from managing the AD user account with base-level set of attributes to managing the relationship between entitlements and users to finally managing the entitlements themselves. As the first step in this process is to manage the base AD user account, I will start with that.

Since Active Directory represents a central nervous system for most Microsoft infrastructure deployments and just about every organization out there has deployed Microsoft apps and services regardless of whether they like it or not, Active Directory is one of the most common target systems in OIM implementations. Implementing support for provisioning of base AD accounts usually yields a quick win in the form of improved operational efficiency and greater compliance, especially in regulated environments.

The out-of-the-box Active Directory connector does a good job of creating base AD accounts as long as you don't have any specific requirements that deviate from the lowest common denominator. Unfortunately, the lowest common denominator is very low. Frequently encountered challenges such as the desire to generate a login (and/or email address) or being able to support a directory structure with multiple organizational units require customization of the connector.

Usually, it's the advent of the process automation via an identity manager tool such as OIM that forces the organization to articulate the rules for generating email addresses and logins for the first time. Inevitably, the newly-written requirements for the generation algorithm cover three pages and include a small mountain of special cases and advanced collision logic.

Warning #1: If you receive a simple, sensible set of written rules in the first place, the odds are good that the true (and extremely complex) requirements won't show up until the system is in production, which is not a fun experience.

One of the most complex issues in Active Directory implementations is figuring out where in the directory tree the user account should be placed. Typically, there's a series of organizational units (OUs) in AD that represent someone's idea of org hierarchy and one of these OUs should act as the bottom-level container for the user account. Occasionally, the AD org unit structure actually makes sense and the placement of the AD user object can be determined via a simple lookup algorithm that utilizes a single attribute from the core OIM user object, e.g.
the user's geographic location. A table in OIM database stores the mapping from the user's location to the org unit. However, this ideal state is rare and most of the time you'll find AD implementations with large numbers of org units arranged idiosyncratically (random walk anybody?)

Thus, the "simple lookup" table often grows to include hundreds or sometimes thousands of rows. In many cases you will also need more than one variable to determine the exact org unit. Enter multiple nested lookup tables or utilization of the rule and group engine of OIM. Now
you can configure OIM to locate users who work for the truck division, are located in the Raleigh office (location code) and work in Sales. You do this by going into the “truck division" branch of the org unit structure, then navigating to the bottom of US -> North Carolina -> Raleigh -> Sales org unit tree. Problem solved!

Unfortunately the problem is not solved. As it turns out, the company has two offices in Raleigh with the corresponding two org units that share the same office location code. It is also critical that the user gets put in the “right" org unit or he will have to drive 90 miles to another office to get his free company lunch. At the end of the day you will often discover that no matter how complex or sophisticated your rules (and their implementation in OIM) become for determining where the account will go in AD, they will not be able to solve this problem with 100% accuracy. In most cases, you'll need to accept that you'll be able to automatically place only 95-99% of the users. The rest will have to be done manually.

Regardless of which strategy you pick to deal with this issue, it is important to realize that the org unit structure won't stay static so your placement algorithm will also need to be flexible as the directory structure will change and change frequently. Sometimes the new structure will look nothing like the old structure (think mergers and acquisitions or a re-org, the latter being a way of life in some large companies). One way to make life less painful is to give each configuration entry a validFrom and a validTo value. This will make it possible to stage configuration changes ahead of time. Once you have dealt with the basic provisioning requirements you need to consider creation of email accounts and home directories. Each of these areas deserves an article of its own.

Now that you have a shiny new AD user provisioning system the next step is to handle all of the supporting use cases. First, you will need to disable user accounts to support cases such as employee termination. The AD connector makes the disable transaction very straightforward; the compensating enable (or re-enable) transaction is also easy.

Warning #2: Try very hard to convince your customer to implement the termination process by disabling the AD account rather than by deleting it permanently. As a best practice, you should always implement terminations as a reversible action. When someone or some process goes haywire and sends 5000 termination events to OIM by accident, you won't have to try to resurrect all those accounts from a backup and the IT managers won't use your name in one sentence together with many expletives. Instead, you will just have to re-enable the accounts and move them from the "disabled accounts" place in the directory to "live accounts" place. The move is still painful, but much less so than the alternative.

The best way to implement this is via a “disable and move to disabled org unit for a period of time" rule. The only downside of this rule is that the users who leave the company and later return may want their old accounts back. As the account still exists it is hard to refuse this
request (at least once the user figures out that their account still exists). At this point you'll have to create a process for re-enabling accounts which sounds straightforward but often turns out to be quite complex.

Users also have an unfortunate tendency to change their profile attributes by getting married or divorced. Alternatively the client rolls out the system where people tend to use a “preferred first name" rather than their legal name in email addresses and other identifiers. For example, let's say your Asia Pacific marketing director's legal name is “Chen Ai-li". This name flows from the HR system to OIM. But the director goes by “Holly Chen", so she wants “holly.chen@acme.com" as her email address is not the OIM-generated Ai-li.Chen@acme.com. You might think that you could just establish a “no email address changes allowed" policy, but that will only work until someone important wants to change his name.

Another approach is to allow the change to occur outside of OIM (e.g. in Active Directory) and reconcile the change into OIM but this only works if you allow the reconciliation process to update the profile in OIM. A third and best approach is to let the change flow down from the trusted source, such as your HR system. If you want to avoid having to argue the importance of using legal names in the HR system with the HR admins you can include "preferred firstname" and "preferred lastname" fields in the OIM user data model so that you can handle this without
having to change the legal names in HR.

Updating key AD attributes such as samaccountname so that it becomes based on the new name can be dangerous, because some of your downstream applications might depend on the samaccountname staying constant. The usual compromise is to change the
email address and the displayname while keeping the samaccountname unchanged.

If you cover all of these use cases, you'll be able to get accounts provisioned to AD at the snap of your fingers. At this point you certainly deserve a break. You might think that you are finally done but this is just the beginning. Tune in next time for a discussion of how to deal with reconciliation and basic provisioning of AD groups, including their membership.

The big bite

Deborah Volk — Tue, 21 Apr 2009 14:42:00 +0000

We at Identigral are a bit obsessed with Edward Lear so we couldn't help ourselves. Instead of writing another few pages worth of text on Sun/Oracle future, we thought it would be easier to summarize the last few days in two limericks:

There was a company whose name was Sun
That took Java out for a run
With NetBeans spilled
And MySQL forked
Larry the Yachtsman got the wine uncorked

There is a company in Redwood Shores
Whose appetite grew in fours
A fork in the left
A spoon in the right
And the Valley became one big bite

The rise of Suncle: Solaris, Java, ripple effects

Deborah Volk — Mon, 20 Apr 2009 21:42:00 +0000

In previous articles on this blog, we took a look at all 3 parts of Sun/Oracle identity and access management portfolio - identity administration, access management and directory services. This blog will talk about some of the other components of the acquisition.

Solaris. With Oracle gaining ownership of Solaris, Oracle Enterprise Linux (OEL) will no longer be an ever-present entity looking very forlorn on the list of supported/certified platforms for a particular Oracle identity or access product. I don't think Oracle will abandon OEL completely (RedHat and IBM need to be kept in check, after all) but it will become a much lower priority vs Solaris. According to my long-haired and bearded system administrator friends (you know they qualify with a look like that!) with Solaris, Oracle gains a superior product to Linux on a number of levels.

When we talk to customers about their proposed deployment of one of Oracle's identity and access products, there arises a question of application server, JVM and OS. A long and exciting process known as deciphering Oracle's certification matrix begins; it usually culminates with a question of "Linux or Windows ?". Oracle's identity and access products support other OSes but Linux and Windows enjoy the greatest breadth of certification. That is, you can run just about any J2EE app server and just about any JVM if you choose Linux or Windows; going with a different OS will limit your choices. With Solaris being an Oracle product, it becomes a de facto certification choice across the board. Web servers, app servers, databases, directories. Makes it easy for customers who are allowed a choice by their IT department to use Solaris as a verb and say Solaris me!

Java. This and Sun's customers (mmmm..maintenance revenue..tasty!) is why Oracle bought Sun, right? RedMonk has a nice writeup that covers all relevant angles.

Hardware. Let me just register my one-liner prediction that Oracle will not keep the hardware business, despite all proclamations to the contrary. They might give it a shot but sooner rather than later it'll be spun off or sold. I don't see identity management or other appliances in Oracle's future. They like warm protoplasm (read: software).

Ripple Effects. Gartner's John Pescatore writes on his blog about ripple effects from the acquisition. One of the effects is what he calls a "startup echo effect" where the smart people will leave Oracle after their 1-year retention bonus runs out and start their own companies. "It's like flowers blooming nourished by the ashes of the previous company". No mention of fertilizer?

The rise of Suncle: Directory Services

Deborah Volk — Mon, 20 Apr 2009 14:40:00 +0000

I've covered identity administration and access management pieces of Sun/Oracle (affectionately referred to as Suncle on this blog) product portfolio in my previous blog posts. This one will address the remaining third - directory services. (Updated to correct the omission of virtual directory and identity synchronization from Sun's suite).

Oracle brings Oracle Internet Directory (OID) and Oracle Virtual Directory (OVD) to the party, Sun brings Sun Java System Directory Server (Sun DS) Enterprise Edition. Sun's Enterprise Edition packaging includes 3 pieces: Directory Server, Directory Proxy Server and Identity Synchronization for Windows. Sun's Directory Server corresponds to Oracle Internet Directory, Sun's Directory Proxy Server corresponds to Oracle Virtual Directory and Sun's Identity Synchronization for Windows is closest in terms of functionality to Oracle's Directory Integration Platform (DIP; sometimes referred to as Directory Integration and Provisioning).

Let's start from the end. Identity Synchronization for Windows and DIP are both focused on synchronizing entries between "our" directory (Sun DS or OID) and "their" directory (usually Microsoft's Active Directory) with typical flow from "their" to "our". DIP is part of Oracle's "legacy" identity management stack that revolves around OID; the metadirectory-like synchronization approach is somewhat dated. Customers synchronize identity and credentials for various reasons but many of those reasons are challenges that can be solved in other ways, they do not require point-to-point synchronization. For example, an identity manager solution could provision both Sun and AD with the same credentials and keep them in sync based on updates from HR database. Having said that, Oracle has plenty of customers who use DIP and have no desire to deploy an identity manager product. Sun Identity Synchronization for Windows product seems to have quite a bit of overlap with DIP and DIP is not just for AD, it was conceived to deal with any "foreign" directory, plus there are other ways to achieve goals without synchronization. Based on this, I don't see the Sun product walking too far from the parking lot, it'll be riding in the trunk of the car to the docks.

Sun's Directory Proxy Server and Oracle Virtual Directory seem to have been cut from the same cloth and OVD is a very nice product, we're big OVD fans at Identigral. Again, I don't see anything unique or special in Sun's product that OVD doesn't have. Mark Diodati from Burton Group writes that Sun's Directory Proxy Server lacks a number of core features found in other virtual directory products, including OVD.

This leaves OID and Sun DS in the ring. Directory Server is the only weight category in this boxing match where I think Sun has a legitimate shot at an upper hand but it will require more than 5 rounds.

Oracle will not kill OID by any stretch of an imagination. Oracle's "legacy" identity management offering requires OID and Oracle has a number of products tied to this legacy infrastructure. Most notably Oracle e-Business Suite requires legacy identity management stack if you want web single sign-on. Aside from these dependencies, the legacy identity management infrastructure also requires a database server (Oracle's, you guessed it) to store both metadata and application data. Having OID in the mix when deploying the legacy stack at a customer automatically means that the customer has to buy a database and not just any database but an Oracle database. This is good business and while Oracle doesn't produce a nice spreadsheet breaking out revenue streams by products, we can guess that this "pull-through" strategy where you drag a bunch of products on coattails of another yields a nice chunk of change.

Having said this, Sun DS is a formidable opponent. It has a royal pedigree going back all the way to Netscape and University of Michigan team, it has a large customer base and it has a fantastic brand. Even though it suffered some neglect in a few years following the dotcom meltdown, it is no technology slouch from any perspective and Sun did invest a fair amount of resources into its upkeep. Many Oracle customers would love to run Sun DS instead of OID plus accessories. Will they finally get their wish? I think so.

The scenario I see as unfolding will be similar to the playbook for BEA's Weblogic and Oracle's own application server. While Oracle could not simply erase Oracle Application Server (OAS) from its roadmap since customers and Oracle's own products depend on it, it relegated OAS to the lower position on the totem pole by placing it into "continue and converge" category. Translation: OAS will be spoon-fed from maintenance dollars and eventually placed on life support with Weblogic being the go-forward app server of choice.

The gap between OID and Sun DS is not as wide as the gap between OAS and Weblogic so OID won't be completely downshifted. Nevertheless, I predict (48.52 probability) that OID and legacy Oracle identity management infrastructure will be sent to the back of the bus. Sun DS should become a de facto Oracle choice for a directory server even if it doesn't require the database. For customers who like to store everything in the Oracle database, OID will be always available as an option.

The rise of Suncle: Access Management

Deborah Volk — Mon, 20 Apr 2009 13:03:00 +0000

This post is a continuation of a series analyzing Sun/Oracle acquisition in the context of identity and access management. Read the Identity Administration article if you want to start from the very beginning.

Access Management. Oracle has quite a few pieces in this bucket but only three of them have a counterpart in Sun's world: Oracle Access Manager (OAM), Oracle Identity Federation (OIF) and Oracle Web Services Manager (OWSM). Sun's OpenSSO product contains web and federated single sign-on capabilities along with a bit of web services security. Oracle fields three separate products to answer the same needs - Access Manager is web SSO, Identity Federation is federated SSO and Web Services Manager is web services security. Sun's roadmap for OpenSSO includes a fine-grained authorizations capability built into web SSO and this capability would partially compete with Oracle Entitlement Server (OES). (I say to an extent because OES can handle fine-grained authorization service for a wide variety of clients, not just web apps).

First, let's deal with the easy one. Web services security pieces in OpenSSO do not hold a candle to Oracle's Web Services Manager. Also, putting web services security into an SSO product is suspect but Sun did not have a choice. Oracle did the right thing by letting OWSM play in both identity and access as well as SOA/services sandboxes since the challenges being solved are right on the borderline between services and access management. I see web services security being extracted from OpenSSO and sent to sleep with the fishes; OWSM has plenty of firepower to deal with web services security.

This leaves federation and web SSO. On the federation front, Sun has shown an ability to innovate so I think there's definitely some pieces worth saving, e.g. fedlets and UI-driven task flows. Having said that, I don't see Oracle keeping federated SSO pieces inside a single product and I can speak from the perspective of having addressed this issue with customers. Most customers start with web SSO, few start with federation. Certainly federation is a goal of customers who deploy SSO internally, learn about its pros and cons and generally like what they see so they want to move on to the next stage. If such a (typical) customer was confronted with a decision of whether to buy one product that contained both web SSO and federation features (and pay 100 dollars) or buy one web SSO product now (50 dollars) and federation product later (50 dollars), most customers would opt for the latter (at least in this economy) The overlap between OpenSSO federation and OIF is sizeable. If there are technology gaps between OIF and OpenSSO where OpenSSO is superior, I think they'll be closed in OIF. Same goes for web SSO. Eventual fate of OpenSSO is to be chopped up and sent to sleep with the fishes (42.79 probability)

Another option is that Oracle (after harvesting the juicy bits) will release (or simply let continue) the remaining pieces to Open Source while offering a migration path from there to commercial Oracle products. In some sense, this would be a wise move, especially if a few resources are committed to supporting these projects so that it doesn't seem like a joke. Lots of positive PR, little downside. Sun customers that liked the allure of Open Source could try and continue with now-discontinued Open Sourced Sun products, only to discover that having the source does not imply you have the muscle to "own" it. Their recourse would be to run right back into the welcoming arms of Oracle that could offer them a migration package.

Next step: directory services.

The rise of Suncle (volume 1)

Deborah Volk — Mon, 20 Apr 2009 11:34:00 +0000

With the news of Oracle acquiring Sun exploding like an errant bombshell on the peaceful identity management beach shores, it's a perfect opportunity for me to step into my analyst shoes (Jimmy Choos donations are welcome). For those of you who prefer your conversation in 140 character chunks, you can follow us on Twitter; the proposed Twitter tag for Sun/Oracle discussions is #suncle; it's also the tag used on this blog.

Let's compare and contrast Oracle and Sun identity and access management portfolios. We'll use functional buckets because that's the easiest way to get apples-to-apples comparison. Here's what Oracle's identity and access stack looks like today:

And here's what Sun's stack looks like:

Identity Administration. Oracle has Oracle Identity Manager (via an acquisition of Thor Technologies) and Oracle Role Manager (via an acquisition of Bridgestream). Sun has Sun Identity Manager (via an acquisition of Waveset) and Sun Role Manager (via an acquisition of Vauu). This will be the toughest fight in the land. Both OIM and SIM products are well respected by analysts and customers, both came via acquisitions of pure-plays that were #1 and #2 (or #2 and #1) in the IDM land. From a business perspective, it would be ideal for Oracle to retain Sun's customers and then gradually migrate them over to Platform X (my codename, not Oracle's) where Platform X will contain best of both Sun and Oracle product worlds. Pissing off Sun customer base early on will lead to rapid defection to either IBM, CA or Novell or smaller vendors such as Aveksa or Sailpoint that excel in certain areas of identity administration.

What is the genetic makeup of Platform X? My guesstimate is that the core of Platform X will be based on OIM and Sun Role Manager. There will not be a separate Role Manager product, role management will be part of an identity manager product. Role management does not make sense as a completely separate entity, it should be a service/module/set of features provided as part of identity manager. You want to manage roles and make decisions based on roles? You install a module and all functions within identity manager become role-aware, right down to connectors. Naturally this is science fiction at the moment (especially the connector bit) but Oracle has an opportunity to make it a reality and Do It Right™

Why will the core be OIM and not Sun Identity Manager? The current release of Oracle Identity Manager is 9.1.x and it is part of Oracle's 10g "umbrella" release stream that touches a number of Fusion products (For those from the Sun world, Fusion is Oracle's overarching brand for all things middleware and even apps that run on top of it). The "next generation" stream is 11g which has a corresponding OIM release. This is not just OIM, all Oracle identity and access products could rev up to 11g but OIM and Oracle Role Manager are the key strongholds and 11g needs them to be, well, labeled 11g versus just some next release. Oracle has been working on 11g stream with identity and access products for a while, I've heard a number of tentative release dates but I am not going to speculate or announce them on the blog. Suffice it to say that a lot of development, QA, marketing, comm effort went in to 11g and the effort started a while ago. For Oracle to turn around on a dime and to delay 11g in order to come up with Platform X will be a an execution miracle and I don't believe in miracles. Thus, I think 11g will go out as planned with some opportunistic changes where Sun/Oracle products either have gaps or absolutely no overlap (witness the lightning fast addition to the suite and rebranding of BEA's ALES product as Oracle Entitlement Server)

Last but not least, let's not forget a very important part of any identity manager product story - connectors. Sun has just released their connectors and a little bit of architectural foundation into the wild of Open Source and there's a licensing story that needs to be written on how that would shake out if Oracle wants a piece of the pie (a fork?). This final salvo by Sun is great for Sun customers since it's all within the context of Sun Identity Manager. The integration with Sun product is provided "out of the box" (out of java.net source depot!) or assumed to be possible with little effort.

It'll be interesting to see what happens to this and other Sun open source/externally-focused initiatives when Oracle fully digests the rabbit. If Oracle decides to use Oracle Identity Manager as a baseline for Platform X, having Open Sourced connectors is a measure of protection for current Sun shops. That is, if you have the source code, you can keep on trucking for a bit longer with the Sun product and derive pleasure from not paying maintenance to Oracle, assuming you're willing to get your hands dirty (really dirty) whenever an issue comes up versus opening a support ticket. Regardless of whether the Sun connectors can be used by Platform X, high-quality connectors available out of the box are a large part of a successful deployment.

Next stop: access management

Channeling Edward Lear

Deborah Volk — Fri, 17 Apr 2009 17:50:00 +0000

Since we've added subscribers to our burned feed, I am making good on my limerick promise.

There was a Young Person in IT
Who joked about identity
The auditors came
And made him lame
That Deprovisioned Person in IT

Virtual truth (chapter 3)

Deborah Volk — Thu, 16 Apr 2009 11:31:00 +0000

There's no chapter 3. RBAC Fiction publishing imprint just offered me a HUGE book deal to write a crime novel about virtual directories so I am going to get started pronto. If you have any plot ideas, feel free to comment on this post or email blog at identigral.com.

Virtual truth (chapter 2)

Deborah Volk — Thu, 16 Apr 2009 08:57:00 +0000

In chapter 1 of this ongoing novel, I've written about the basic premise behind virtual directories. This post will cover use cases that we've encountered in the field when working with prospects and customers and Oracle Virtual Directory (OVD) product.

Architectural Buffer (Service-focused). The buzzword-friendly among you may label this example as Agile Infrastructure. You've got an enterprise-wide directory service that you provide to applications. Multiple applications query the directory via LDAP for identity-related information and associated entitlements, a few applications (such as Oracle Identity Manager) create or update the entries in the directory. All such efforts usually start with a single directory, "clean" schema and nice container design - everything is neatly categorized, labeled and stacked (socks in top drawer, shirts in bottom drawer) and lives in its proper place. Over time, as applications demand schema changes, containers multiply and data quality degrades (just like an increase in entropy this is inevitable), the house with a neatly trimmed lawn and a white picket fence starts looking like a soot-blackened dwelling with roaches on the floor. Yikes!

In this case we recommend that you deploy a virtual directory in front of your "real" directory and have all applications that use the service point to virtual directory. This provides an architectural buffer against both the current clients of the service as well as future needs. Perhaps the specter of future requirements (unknown unknowns!) is even more important than straightening out the current mess but you can hit both targets with one shot. If more directories spring up in the enterprise in the future (and they always do), you're protected from impacting the current clients of the service since you can incorporate the new directories into your virtualized service. The entry point for clients remains the same, the underlying directories don't change, only the piece in the middle that directs traffic changes and that's OVD. The extent of the protection depends on how the service is used but the impact will certainly be much more muted with a virtual directory than without it.

Another important benefit of Architectural Buffer is ownership of data. With multiple directories residing in various business units, you don't have to get into potentially ugly political fights for ownership since you're not taking them over, merely providing a view and a path for data flow. That's a lot easier to swallow than "I am moving your data to my central directory. Good-bye!".

A special case of Architectural Buffer is web single sign-on where various SSO components act as clients of the directory service. All web SSO products work with directories, some require them as repositories, some give you an option of storing data in the database or in their own proprietary format. Oracle Access Manager officially supports Oracle Virtual Directory as an option for storing customer (user) data. With web SSO, the virtual directory option is strongly recommended because the scope of web SSO usually expands to encompass different audiences. It starts with internal users, then it might start covering partners, then customers and so on. The identity information and associated entitlements for these distinct audiences are already there, the company has been doing business with these folks after all for many years..but now it wants them in web SSO. You would be lucky if all these records reside in a single place such as an enterprise directory. In reality such luck is rare. Usually the data is spread across multiple sources and only a few of them are directories, the rest are usually databases. Again, a virtual directory will save your life here by allowing the web SSO tool to act on partner and customer identities with little or (ideal case) no change to web SSO infrastructure.

Single View of the Customer. Timely to my note, Mary Knox from Gartner weighed on this very topic in her Customer Data Integration: Think Ideally! Act Pragmatically! Gartner talks about multiple "styles" of customer data integration, primarily in the banking context but I think they apply anywhere: registry, coexistence and transaction with transaction being the ideal state where all data is available in one central store (referred to as "hub" in Customer Data Integration (CDI) parlance). The problem being solved is that of, well, data integration - the data is spread across multiple source systems yet it needs to be available in a single place/view.

Registry style is when the central store contains minimum amount of data necessary for the service to work plus references to where the rest of the data resides; it's up to the application to retrieve the location of additional data from registry, navigate/connect to that location and retrieve additional data. Coexistence style is when the central store has a copy of the record from the source system. Both registry and coexistence require synchronization from the source to the central store; the transaction scenario usually requires bi-directional sync to/from hub and sources, real-time or batched.

CDI is focused on data and directory virtualization is focused on more than data (e.g. protocol translation and routing) but they're kissing cousins. Moreover, a virtual directory is an elegant technology implementation option for either the registry or transaction style. In fact, there's no need to sync anything with a virtual directory - it can present the data in a single, virtualized view without touching the back-end sources. If an application needs to change attribute "partner code", OVD will route the request to the CRM system. If an application needs to change attribute "product SKU", OVD will route the request to the MDM app and so on.

Even though this pattern is titled Single View of the Customer, it's really Single View of the Entity. Customers and Partners are usually entities being focused on but we've seen Products as entities too.

Replace a Directory. Oracle Virtual Directory has a notion of Local Store Adapter (LSA) that allows it to store data in its own database. In other words, not only it can proxy requests to/from sources but it can also serve as a repository for data. Given this capability, why deploy a traditional directory when you can have a directory on steroids (it slices, it dices, ...)

Directory Consolidation. This is somewhere between Architectural Buffer and Single View of the Customer. Count with me: I've got 1 directory, 2 directories, 13 directories...oops that's too many! Directory consolidation doesn't happen just for the sake of it. It is usually driven by either architectural considerations or business context such as achieving a single view of the customer. There's going to be cost savings when you shut off a silo but wrestling with data ownership issues can be costlier so directory consolidation is often talked about but rarely done. Virtual directory offers a way out: keep your data in your own backyard but centralize access.

Geography Lesson

Deborah Volk — Wed, 15 Apr 2009 00:15:00 +0000

Since I started blogging, the number of visitors to the site has grown dramatically and I thank all of you for stopping by. Our readership spans the entire globe with people coming from 30 countries on all major continents, everywhere from Finland and Russia to Qatar and South Korea. United States is leading the way in terms of visits but I am slightly disappointed in coverage. We only have 40 states out of 50 showing up. I can understand Montana, Wyoming and both Dakotas missing in action but Wisconsin, Tennessee, Arkansas and Oklahoma need to wake up and discover the identity challenge within. I am not even talking about Alaska (Sarah Palin, you KNOW you've got an identity management problem!) and Hawaii.

If you know folks in those missing states, bring them over. When we hit 50 states, I will commemorate the occasion by writing to Steve Jobs and requesting a donation of a new iPhone to Identigral so I can listen to Stackoverflow podcasts and twitter incessantly.

...and to make this post worth something, I included a gorgeous relief image from US Geological Survey that shows the varying age of bedrock underlying North America. Can you guess which colors represent older formations? If you're having a hard time, I strongly recommend getting a geology lesson. Click on the image for more info and a full-resolution shot.

Virtual truth (chapter 1)

Deborah Volk — Mon, 13 Apr 2009 23:29:00 +0000

I saw a note by Mark Wilcox on his blog regarding Oracle Virtual Directory (OVD) and SharePoint. Mark's note details how among other things OVD could be used to provide a unified LDAP-based view of users in multiple Active Directory forests not bound by a trust mechanism. If you've ever encountered SharePoint and multiple forests, the OVD solution is priceless (ok, they might charge a little per processor). This made me think about other interesting use cases for using a virtual directory but before going to outer edges of the galaxy, I'll cover the basic scenario first.

We'll use our favorite El Caro Corp as a hypothetical guinea pig for our Gedankenexperiment. El Caro has grown from a small business to a large corporation and as a result of this wild (some might say unrepentant) growth, it has a number of enterprise applications. El Caro's go-to market strategy is based on partners who resell El Caro's products. Thus, El Caro has a CRM app where it tracks partners and related sales opportunities with product SKUs, a Master Data Management (MDM) system that contains all product SKUs, corresponding product names/descriptions and configurations of these products that El Caro offers to the market and finally a Sales Compensation (SC) tool that works out the commission due to the partner based on a sale of a product SKU by the partner.

These 3 apps all store their data in their own repositories - CRM in its own database, MDM in an LDAP-compliant directory and SC in one humongous Excel spreadsheet (don't laugh, this isn't far from reality). The JPY 6384000 (roughly $64,000 at the current JPY/USD conversion rate) question is this: how can El Caro management achieve a single view of their partner-sales-product universe? The ultimate goal is to have a dashboard showing sales opportunities for a particular territory with each opportunity displaying partner name, product name, opportunity dollar amount, commission due to partner and the estimated profit margin for El Caro on the sale.

To achieve a single view of data across 3 different repositories, two things have to happen. First, relationships between records in different sources must be identified. Second, somehow the records must be "brought together". (I am using the term record to mean a set of data even though some sources such as directories should be more appropriately labeled as containing entries rather than records). We're concerned with the 2nd step and here we have two major options - to copy the records from all 3 sources into one central repository or leave the records where they are and provide a view onto them. Since virtualization space is white-hot, the 2nd option is referred to as (you guessed it) a virtualized view.

In the first option our central store (database, directory, Excel, ...) will contain copies of records and perform the "unification" step. This is equivalent to exporting the data from 3 sources, massaging it, importing the data into our store, glueing the records into one and finally achieving a single record/view of partner-sales-product space. The problem with this approach is that we've just created a chunk of work that serves no business purpose...other than moving data. We've got the overhead of maintaining the central data service (labor, hardware, utilization, etc) and the data in our central store duplicates the data already available elsewhere. On top of this, if someone spots a data issue (what do you mean they didn't charge them for 16 extra CPUs?!), it'll be your fault. After all, the data is in your store.

The other option is to provide the unified view without copying or moving the records to a central location. In this option, records from 3 sources are "joined" together into one view much the same way this is done in a database. (Database views do not contain copies of records from underlying tables that make up the view). This is the purpose that virtual directories were born with. Viewed from this perspective, a virtual directory is a very smart, data-oriented, aggregation-capable multi-protocol proxy. The virtual directory may accept a request via HTTP or LDAP formatted as plaintext or XML (e.g. SOAP), transform the request into multiple requests with (potentially exotic) format/protocols palatable to the downstream source(s), apply routing rules to the request, send them back to the sources of data, retrieve the results, perform aggregation on results and finally send the results back to the requester. This sequence of events is very basic, virtual directories are capable of a lot more but the central premise of protocol translation, routing and aggregation of data holds true throughout.

In chapter 2 of the Virtual Truth novel, we'll look at interesting use cases that we at Identigral have encountered in the field while working with Oracle Virtual Directory.

Homework: compare and contrast portals, mashups and virtual directories.

Bonus: Everything You Wanted to Know About SharePoint User Mgmt But Were Afraid To Ask

Beeping in Minnesota

Deborah Volk — Fri, 10 Apr 2009 11:31:00 +0000

I used to live near train tracks. By train I mean the old-school garden variety industrial animal that huffed, puffed and choo-chooed loud enough to rattle the double-paned glass windows in my house. On days when the train density approached positive infinity (must have been a shortage of cucumbers somewhere) and the noise levels exceeded the wildest dreams of experimental music fans, I dreamt I was in one of those Japanese shinkansen trains that silently fly at 360 miles per hour. My dreams were rudely interrupted by incessant beeping (beep jeep, say 30 times fast) and that was as much as I remember.

Fast forward to now. I was reading Bruce Silver's BPMS Watch blog and saw his note that 2.0 release of Business Process Modeling Notation (BPMN) standard is close to being out. That's one loud beep about to be heard round the world! WaittaBangaloreminute, you might say, what does Business Process Management (BPM), Business Process Management Systems (BPMSes) and BPMN have to do with identity and access? They're aliens from a different universe, shoot them with a laser and turn them into stones.

Aliens they are not but an invasion is coming and we all need to be prepared. I am going to let you all in on a BIG secret that United States, nay, international military-industrial complex has attempted to hide from you: identity management is nothing but a flavor of business process management. BOOM! Yes, we have our own special tools and jargon (reconciliation of provisioned entity failed due to a misguided attestation attempt) but that just makes us different and misunderstood (like all teenagers), it doesn't mean we're not related. Managing identities doesn't make sense outside of a business process and even though our workflows may not span applications and be orchestrated with a fancy engine that claims to do XML-driven pirouettes, they're still workflows that are very much a reflection of real business processes. If you believe that we're part of the extended BPM family, then you also know a certain truth: don't ever take sides with anyone against the family or you might end up on a mainframe project in Florida (or Minnesota).

What does the family use to communicate amongst its many and far-flung members? The answer is BPMN. As a modeling notation, BPMN is lingua franca of BPM practitioners who employ it when communicating the details of a new or changed process. Just like UML, BPMN is a formal notation, it means business when you draw something so there's no ambiguity about what happens to, say, a process task when it doesn't get the answer from a remote system in 60 seconds. Naturally, any type of formal notation carries complexity and a learning curve, you must spend enough time with it in order to be fluent. There are tools that make this much easier for you (see Bruce's blog for reviews and recommendations) and Visio has a plug-in.

Why bother with BPMN, why not use Visio and "simple" diagrams? You have to remember the family, they are coming. Identigral Analyst Group predicts with 1.89 probability that the next generation of IDM tools will rely on BPM standards. The other reason has to do with a more involved discussion that I will attempt to shortcut. BPMN as a modeling notation has a kissing cousin in the runtime space, that being Business Process Execution Language (BPEL). You draw a process in BPMN but you cannot stuff it into a tool and have it be executed, it first has to be translated to BPEL or a proprietary execution language/substrate. This causes all kinds of issues. As befits kissing cousins, the relationship between BPMN and BPEL is challenging to describe but suffice it to say that the gap is closing. With BPMN 2.0, the gap may be artificially reduced to none by a tool vendor.

Imagine this: instead of configuring a workflow in your favorite identity management tool via XML or by clicking or by writing Java code, you draw the process in BPMN, right down to attributes and communication protocols...and you're done, the tool would do the rest for you. You would import your BPMN diagram into your revolutionary IDM tool that would translate it to executable tasks, pull in the necessary connectors to other apps, wire the tasks to the connectors and so on. The job of IDM developer would be reduced to its proper denominator , namely the subject-matter (business process) expert.

As of today the above vision is largely science fiction but all major vendors are thinking about the convergence of BPM and IDM spaces. Until then, it's BeeP(in)MN.

Slow burn

Deborah Volk — Wed, 08 Apr 2009 23:03:00 +0000

For those of you who read this blog but have yet to subscribe, I've got a business proposition for you. You attach yourself to our FeedBurner-powered wisdom and I'll write a haiku or a limerick celebrating a topic of your choice. The poems will be published on this blog and you will enjoy many years of fame and fortune (if you play the lottery and win). Naturally you'll have to claim your subscription by commenting on this post or contacting us privately. Since FeedBurner doesn't advertise identities of subscribers, we'll have to trust your word but to paraphrase Bela Karolyi, we are in the business of identity management, we know what a subscriber looks like. You mess with us and we'll throw an entire set of printed Oracle Internet Directory manuals at you, starting with release 1.0.

I've improved the FeedBurner experience by adding an option for you to email the article in one click or share it using AddThis which contains virtually all social networking/bookmarking services. I also changed the description of the feed, it's no longer boring. Please let us know if you like it and if there are any other feed-related changes you'd like to see, we aim to please.

A Flock of Seagulls (Feeling Entitled)

Deborah Volk — Wed, 08 Apr 2009 11:59:00 +0000

If you read my previous blog on entitlements, you might think that it's not a big deal. After all, how much management overhead can there really be for a few groups in Active Directory that represent entitlements? Jackson Shaw from Quest Software quotes a customer in his blog as saying that

We have over 300,000 groups (distribution lists, security groups) scattered across our company. Forget about "managing" them! I'd simply like to know if they are even being used let alone what for!!

Quest's products deal with Active Directory and groups and my entitlement example uses Active Directory and groups (art imitates life!) but there are other ways entitlements and their lifecycle come up as challenges. Consider an instance of Oracle's e-Business Suite (EBS). Do you know how many roles and responsibilities (coarse-grained and fine-grained entitlements) are there across apps/modules in an EBS instance? Go ahead and ask your DBA, I dare you. I've seen an EBS installation with close to 50,000 responsibilities. Oh and then there's RACF and TopSecret, they deserve a blog post of their own.

Show Me the Money (Feeling Entitled)

Deborah Volk — Wed, 08 Apr 2009 01:30:00 +0000

It has become popular during these challenging economic times to wonder and speculate about the root cause of that sinking feeling in everyone's financial stomach. Were the lenders so greedy that they overlooked basic risks by lending left and right or were the home buyers so greedy that they overlooked basic risks by going into debt with insane loads? My money (the green, eco-friendly variety) is on both; everyone had a hand in the cookie jar via chopped-up CDOs but you have to dig deeper. After all, we're searching for roots and in my humble opinion the source of the malaise is a feeling of entitlement. Are we entitled to be entitled? Some cheeky Brits think so, especially when it comes to February 29th on leap years:

I wish it was as easy to shake off the entitlement feeling as singing a silly song! How does this all related to identity and access management, you may ask? I am yomping 'round to that.

It's worth noting that the definition of a term entitlement crosses two domains - the identity administration domain where the entitlement is defined and the access management domain where the entitlement is applied and enforced. The IT Manager entitlement is defined on the identity domain as any employee who works in the IT department and has direct reports. The right of IT Manager to view the real-time web-based dashboard of server status in a company's datacenter is applied and enforced by the access domain.

Entitlements fall into two classes: coarse-grained and fine-grained. Coarse-grained entitlements are broadly defined aspects of a business whereas fine-grained entitlements are specific rules originating in a particular business process. Coarse-grained entitlements are usually implemented as groups or roles; Full-Time Employee, IT Manager and IT Manager in San Francisco are examples. Fine-grained entitlements are rules comprising a policy in a specific business context. An example of a fine-grained entitlement may be "IT managers who work in the London office, bring their pet iguana to work on 29th of February and have the first name of Alistair"; these special people may then be entitled to have lunch with Gordon Ramsay. (Can you imagine Gordon Ramsay in the IT department? What in the [bleep] are you doing with this server? Get that [bleep] donkey outta there. You're in the datacenter shaking hands like the [bleep] president of the United States of America, what was that all about)

The challenge with entitlements is that their lifecycle in the context of an identity management system is often left unmanaged. Let's consider an example. In a mythical organization El Caro Corp, we've got sales representatives that have access to two applications - the company's CRM app and another app in HR that keeps track of their compensation. The representatives are assigned to territories that are geographical boundaries within which they are allowed to call on customers. A territory might be as small as a city of London or as large as the entire country of Russia. Sales representatives join and leave the company, territories remain the same. El Caro, like everyone else on the planet, has Windows on the desktop and Active Directory (AD) in their backyard. El Caro decides to define territories in one place, namely as groups in Active Directory, and have all applications that need to know about the territories and what reps belong to what territory draw this information from AD.

How do the representatives become members of a territory (one or more groups in AD) ? Manual process would be cumbersome and expensive, lots of paperwork, approvals and emails floating around. El Caro had a solution - let the identity management tool deal with this. Load all existing territories and their members into the identity management database and presto, we're done...but not quite. The real fun begins when a new territory becomes available, an existing territory splits into new territories or a territory goes away (it was a small island that got flooded, ok?). In the absence of an identity managemen tool, these territory changes would be accomplished by an AD administrator creating new groups, moving people in and out of groups and so on; having the identity management side in the mix makes this much harder.

If you squint, you'll notice that a territory is an entitlement. Entitlements have a lifecycle of their own. Just like applications and users, when new entitlements become available due to a change in business conditions, they are on-boarded onto the identity management tool. The on-boarding process may be simple or complex but it is a process. The entitlements then undergo changes and are eventually off-boarded from the identity management tool. In a recently released whitepaper (registration required) we've described the challenge of administering entitlements specifically in the context of having them live in an identity management world. Give it a read and (as our British friends might say) Bob's your uncle!

What's in your wallet?

Deborah Volk — Mon, 06 Apr 2009 01:04:00 +0000

We've been tweeting, tweeing and twalking on Twitter (feel free to follow us) and it's been an interesting ride. Thanks to a tweet by Nishant Kaushik, my former illustrious colleague (still illustrious), I had the privilege of reading a recently released Oracle whitepaper about an Oracle Identity Manager implementation at Agilent.

The whitepaper talks about decreasing the cost of access requests and quarterly audits as the primary business driver behind the implementation. The other usual drivers of improved security and better compliance are either down or not on the list. While the emphasis on cost as a business driver is hardly new (it's still capitalism folks, regardless of what Obama says), what's interesting about Agilent versus a typical identity management implementation is the statement of what was NOT a business driver for them. Bob Horowitz from Agilent made a presentation to Silicon Valley chapter of ISSA in May 2008 and one of our staff was in attendance. Bob's presentation made a lasting impact because of one "simple" item: desacralization (yes, that's a word) of password resets.

To quote the presentation, "Password Management and Single Sign On don't rise to the top of Agilent's priority list. Password resets are not a significant Helpdesk issue. Yes, users have too many passwords. But security issues can be solved by recommending a tool to manage multiple passwords safely". WOW! The sacred cow, the holy grail, the justification of all justifications, the cost of contacting helpdesk to reset passwords, is NOT a significant business driver because...the real issue revolves around educating the users with a little bit of tools. Why, they must be drinking some special water over there in Santa Clara (Hawaii Deep Marine's Kona Nigari seawater mineral concentrate, $33.50 per 2oz) and I'd like to buy them another case because I absolutely agree.

How would someone manage multiple passwords safely without attempting an all-encompassing single sign-on solution? According to one of Bruce Schneier's more controversial posts, choosing a strong (complex) password, writing it down on a small piece of paper and then storing the piece of paper in your wallet is the way to go. Personally I prefer Bruce's other contribution to the challenge of managing multiple passwords: an Open Source (free as in beer) product PasswordSafe. PasswordSafe or KeePass are tools everyone at Identigral is asked to use when dealing with passwords at a customer site.

Open Source tools duly noted, they're not for all organizations. Another alternative is a class of products that falls under Enterprise Single Sign-On (ESSO) umbrella. The word "Enterprise" does not refer to a breadth or expense of implementation. It's a marketing label to differentiate capabilities from other classes of single sign-on products such as web SSO (often abbreviated as simply SSO since everything is on the web, right?) and federated SSO (often referred to as federation because it sounds sexier). In Enterprise SSO, applications that can participate in the single sign-on scheme can include desktop (client-server, thick, standalone) apps, mainframe apps with green screens as well as traditional web apps.

ESSO's advantage in terms of implementation cost vs other types of single sign-on technologies is that participating applications require no changes. ESSO is a client-side technology that has a footprint on the user's desktop. You can still have administrative policies and overrides as well as many other bells and whistles so it's far from being something that cannot be controlled once released into the wild. Managing the deployment to the desktop by administrator has long been addressed by Microsoft and countless 3rd parties. If you'd like to find out more about the magic of ESSO, you can watch the webinar by our ESSO partner Passlogix or come to a joint Identigral/Passlogix webinar in May (contact us for registration).

...and last but not least, if you want to solve that darn password reset issue, Passlogix has you covered at less than $10/user. Mention this blog and promo code "IDENTIGRALROCKS" and receive a WHOPPING discount. WHOPPING!

Bonus: Secret Q&A
Double Bonus for our readers outside US: What's in Your Wallet?

Opt me in, opt me out

Deborah Volk — Fri, 03 Apr 2009 09:26:00 +0000

Mike Conklin at University of Rochester is blogging about his experience while going through various stages of an identity management project. One of Mike's academic exercises (as he puts it) is anwering a question of how to manage mailing list membership. Mike writes that “after posing this question to several vendors in our IdM evaluation meetings, I actually think that there are no current solutions out there that will allow you to create dynamic distribution lists with opt-in/opt-out capabilities".

No current solutions? Sounds like a challenge to me and boy do we like a challenge here at Identigral. First, let's consider the use case stripped from its technology foliage:

A school wants to offer a newsletter to all of its Geology majors. Maybe it will provide information about guest lecturers or other events. As new students join the Geology program, they should be automatically subscribed to the newsletter based on their declared major.
There are students with other majors who have an interest in geology and would like to receive the newsletter as well. These students should be able to subscribe (opt-in) to the newsletter
There are students in Geology who would like to unsubscribe (opt-out) from the newsletter

The challenge here is that you've got a set of rules that automatically determine membership (if you're a Geology major, you are auto-subscribed) but if you don't fall into the rule-based criteria, you should be able to ask and get in anyway (opt-in). If you do fall within the criteria, you should be able to ask and get out (opt-out). Here's how an identity administration tool such as Oracle Identity Manager (OIM) would solve this problem. I am going to be using OIM terms but if you've got a different product, you should be able to translate.

In OIM, we'll have the students and resources. A resource can be anything, it's just an abstraction for capturing metadata associated with the student's relationship to the resource. A newsletter can be a resource, an LDAP-compliant directory can be a resource, a pair of shoes can be a resource (especially if they're Jimmy Choos!!), a meal card, and so on. Our goal is to accurately track the relationships between students and resources and the state of the relationship. When a student joins the university and chooses a meal plan (grits! grits!), the university issues the student a meal card. The meal card has an ID number, it has a student's meal plan on it, etc. We can then draw a line between our student and the meal card. For example, student Joel Seligman has a Breakfast Only meal plan. OIM labels this step as provisioning, i.e the university has provisioned (issued) the meal card to a student.

The resource has state (more accurately, the relationship has state but ok) - it can be Provisioned, Disabled or Revoked. There are other states too but we'll skip them for the sake of brevity. Provisioned means that the student has the resource and the relationship is active, Disabled means that the student has the resource and the relationship is inactive but can be made active again and Revoked means that the student had the resource but now the relationship is permanently destroyed. If the university decides to revoke the student's meal privileges and send Joel to solitary confinement, they would revoke the meal plan resource (poor Joel!)

There are 3 types of provisioning supported in OIM:

Request-based provisioning: A request can be manually entered by a user or on user's behalf. Approval workflows are started after a request is submitted and provisioning (or de-provisioning) of the resource is started after the approval is completed. Thus, request-based provisioning is really two processes (approval and provisioning/de-provisioning).
Policy-based provisioning. This type of provisioning refers to the automation of target resources being granted to users based on rules that make up a policy. Rules are based on attributes that make up the user's profile. In addition, you can also use access policies to kick-off approval processes that can be run as part of the policy-based provisioning cycle.
Direct provisioning. This type of provisioning is a special administrator-only function. You can provision, disable or revoke a resource for a particular user without having to wait for any approval processes

Here's how OIM solves the mailing list membership problem that Mike posed:

A school wants to auto-subscribe all of its Geology majors to a newsletter. This becomes an example of policy-based provisioning where the policy in OIM looks at the student's major and automatically provisions a Geology newsletter when the student joins the major. The policy could also automatically disable or revoke the subscription when the student leaves the university or switches majors.
There are students with other majors who have an interest in geology and would like to receive the newsletter as well. These students should be able to subscribe (opt-in) to the newsletter. This is accomplished in OIM via request-based provisioning. A student could request the newsletter and be approved by, for example, the newsletter owner. You could also skip approval.
There are students in Geology who would like to unsubscribe (opt-out) from the newsletter. This is done in OIM via request-based provisioning. A student could request to disable the subscription (disable the resource) and be approved by, for example, the newsletter owner. You could also skip the approval.
As an extra feature that's not in Mike's scenario, what about students who become unruly when discussing geology? It can be a very contentious subject and certain dissidents may need to be removed from the list by the administrator. In this case, direct provisioning would be used by the newsletter owner to disable or revoke the newsletter resource for some student

Bonus: a starter kit for those of you interested in pursuing a career in geology

Burning and looting

Deborah Volk — Wed, 01 Apr 2009 22:52:00 +0000

For those of you who like FeedBurner, you can subscribe to our feed at http://feeds.identigral.com/identigral . Unfortunately we can't change the RSS link on the right so it'll continue pointing to www.identigral.com/blog/rss. If the feed moves from www.identigral.com to some other universe (underverse?), we won't lose you and you won't lose us. If you've already subscribed to the feed off the website, no need to resubscribe via FeedBurner...unless you're one of those law-and-order-everything-must-be-neat-tagged-and-categorized kind of person. In that case, you're welcome to click on the animated headline (forever stuck in its frozen glory) or the link above, they both lead to the same place (shhh).

Will the real Oracle Identity Management please stand up (part III)

Deborah Volk — Mon, 30 Mar 2009 23:30:00 +0000

Read Parts I and II

For those of you who got here without reading parts I and II of this novel, I don't blame you. 140 character summary is available by request, please drive through. We're finally ready to answer the question that prompted this blog mini-series :

Question: What is Oracle Identity Management? I've heard that it requires Oracle Internet Directory and Oracle Application Server. Is it possible to deploy it as a stand-alone application or with and

If you haven't read parts I and II, you wouldn't know this but I am going to tell you anyway. The phrase "Oracle Identity Management" is context-sensitive and it means different things to different people. When referring to a set of metadirectory-like services that Oracle built around Oracle Internet Directory and Oracle Application Server, Oracle Identity Management is indeed something that cannot be deployed as a stand-alone application. Furthermore, it cannot be deployed with a 3rd party LDAP-compliant directory and/or with a non-Oracle app server. You could have a 3rd party non-Oracle directory and a 3rd party non-Oracle app server be part of the solution that includes Oracle Identity Management infrastructure but you will still need OID and OAS.

So where do people get the idea that Oracle Identity Management can be deployed without OID and OAS? This is where "new" vs "old" context is important. To make any middleware-based strategy (read: Fusion) a reality, you need a solid set of infrastructure services with identity and access management services being at the bottom (read: foundation) of the stack. In 2005-2006, Oracle went on the acquisition spree and ended up with a shiny new identity and access product stack that to this day continues to dominate the market, IBM claims notwithstanding:

Xellerate product from Thor Technologies became Oracle Identity Manager
CoreID/NetPoint from Oblix became Oracle Access Manager and Oracle Identity Federation
Virtual Directory Engine from OctetString became Oracle Virtual Directory
SmartRoles from Bridgestream became Oracle Role Manager

(I am skipping Phaos and later acquisitions of Bharosa -> Oracle Adaptive Access Manager and BEA ALES -> Oracle Entitlement Server).

In the new stack, no products require deploying OID and OAS as a pre-requisite so the linguistic challenge is to determine the context in which the phrase "Oracle Identity Management" is being used. To make this truly an interesting exercise, it's worth noting that many people associate the term "Identity Management" with the functional bucket of identity administration (user provisioning, attestation,reconciliation,access requests), the bucket that in Oracle's stack is occupied by Oracle Identity Manager and Oracle Role Manager. Thus, the 3rd possible variation on a theme is that "Oracle Identity Management" could really mean "Oracle Identity Manager" which still does not require OID and OAS for deployment.

To make it less confusing for the readers of this blog, I created a "(Legacy) Oracle Identity Management" category. To be sure, Oracle doesn't call identity management services based on OAS and OID "legacy" because they have current customers to support (and eventually migrate to new identity and access stack) but it's certainly legacy in my book so I'll leave it at that.

Ah, semantics or as Italians would say: Traduttore tradittore .

Will the real Oracle Identity Management please stand up (part II)

Deborah Volk — Sun, 29 Mar 2009 22:30:00 +0000

Read Part I

How does a company compete in a market dominated by incumbents? The MBA case studies written on this topic weigh in at hefty poundage, more than enough to cause deforestation of the entire Amazon flora. Oracle, faced with the onslaught of Weblogic and Websphere, employed a classic "divide and conquer" strategy. On one side, OAS was either heavily discounted or thrown in for free to seed the market. On the other side of this equation, OAS was tightly coupled to Oracle's products, causing a drag-through or coattails effect. If a customer bought a product that was just a few steps away from the database in the architectural terms, this product probably required OAS (which required OID which required the database). From a customer's perspective, this coupling could translate to either positive (look, ma, integrated stack!) or negative (look, ma, one more pile of hardware in my datacenter).

Oracle Applications (now e-Business Suite ) was and remains to be, well, the Oracle application but Oracle has other apps too. Oracle's customers wanted single sign-on (SSO) across Oracle's apps and while Oracle integrated with leading SSO vendors of the day such as Netegrity and Oblix , the divide and conquer strategy for OAS was still in effect. As point solutions for functional silos (single sign-on, provisioning, etc) bubbled up and became part of the broader identity and access management market, Oracle's marketing machine took note and Oracle Identity Management was born.

Oracle's acqusition spree of identity and access management companies and expansion of Fusion was yet to come so this was Oracle's response to customer demand and to some extent competition from bigger players such as IBM. OAS (OracleAS in the diagram above) is the bundle of J2EE app server (OC4J) and web server (OHS), LDAP directory is Oracle Internet Directory (NOT any 3rd party LDAP-compliant directory) and OAS certificate authority is a holdover from the times when PKI was sexy. Directory Integration is a set of tools that allow for synchronization of data to/from OID and other directories. Delegated Administration Services is an interface for managing data in OID via self-service or lightweight delegation model. Provisioning service is an interesting example of what Oracle thought of provisioning back then. As the rest of the Identity Management services in this "stack", Provisioning service revolved around getting the data to/from OID:

Viewed in these directory-flavored and data-oriented terms, Oracle Identity Management closely resembles a set of services commonly found in a metadirectory. This is all peaches and cream but where is OAS in all of this? That's where Oracle Single Sign-On comes into play. The first diagram calls it OracleAS Single Sign-On but you'll find just as many references to Oracle Single Sign-On (OSSO) .

The genius of Oracle's marketing (and I really do mean it with respect) was to create a single sign-on "product" out of nothing. To quote Oracle documentation "The single sign-on server consists of program logic in the OracleAS database, Oracle HTTP Server, and OC4J server ". Whoomp! There it is. There's no separate single sign-on product, it's just integration and glue.

Will the real Oracle Identity Management please stand up (part I)

Deborah Volk — Sat, 28 Mar 2009 22:44:00 +0000

I get asked this question all the time and the best answer to any question is documentation. Blogs are a modern form of documentation, ergo this post.

Question: What is Oracle Identity Management? I've heard that it requires Oracle Internet Directory and Oracle Application Server. Is it possible to deploy it as a stand-alone application or with and

Oracle Identity Management is a very context-sensitive term, just like help in Microsoft Office: if you right-click on the wrong thing, you'll end up spending 30 minutes searching all over Encyclopedia Britannica for directions on how to change the footer via that darn ribbon. To understand context, one must know what questions to ask and the questions don't materialize by themselves, there has to be some foundation from wherein they spring. I call this foundation a history lesson.

A long time ago, in a galaxy far, far away there was a company called Oracle. Larry Ellison aside, it did not resemble the present-day Oracle very much. The database and a few apps made up most of its product line, Oracle Financials had yet to morph into e-Business Suite and Oracle Universal Installer ran on JRE 1.1 which it also conveniently added to the front of your PATH. Fusion was something mad scientists had cooking in a jar in some collider, PeopleSoft was optimizing workforce somewhere out in Pleasanton with PeopleTools (hammer, sickle, ...) and there were these other databases too, like Informix and Sybase.

When Netscape rose to prominence in second half of the 90s and helped propel LDAP to new heights of popularity with Netscape Directory Server, Oracle had to have an implementation too. Whether it was a "me too" move or a preview of things to come in Fusion I don't know but happen it did and Oracle Internet Directory was born circa 1999. As J2EE gathered momentum in late 90s - early 00s with app servers leading the way as a key infrastructure component, Oracle entered the market by acquiring the codebase to Orion app server (pretty decent and lightweight J2EE implementation at the time) from a Swedish company IronFlare. The codebase served as a starting point for Oracle's development effort that culminated in a release of Oracle's app server, aka Oracle Containers for J2EE (OC4J). If you are a J2EE expert, you could probably make sense of this product name but most customers weren't so Oracle simplified this game of linguistic chicken for everyone by releasing Oracle Application Server.

Oracle Application Server (OAS) isn't a real product per se, it is a marketing name for a bundle that consists of Oracle HTTP Server (OHS, based on Apache codebase) and OC4J. When BEA and IBM grew the entire cottage industry around their app server product lines and capitalized on app server market domination by renaming everything to Weblogic Blah and Websphere Foo, Oracle's marketing was not far behind. Thus, a number of components became "attached" to OAS even though they were not directly related to the app server .

Becoming inSenSitiVe

Deborah Volk — Thu, 26 Mar 2009 21:56:00 +0000

Every software package has its flaws. But, in the grand scheme of things, it is about how you can get around the flaws. Having been intimately (!) involved with Thor Technologies and having had a hand in many of the first and second wave IDM implementations, I've learned that software is only part of the solution, not the entire solution. Nevertheless, it's important to know how to, well, do things in software. The level of effort when it comes to implementation and maintenance of a live system is directly proportional to the foundation that was built. As for Oracle Identity Manager (OIM), I've seen just about every issue, bug, gap, problem and so on and there are always ways of getting around them but one of the most confusing aspects of the software has been fixed in the recently released 9.1.0.1 version of OIM.

If you have never had to deal with reconciliations, a short intro is in order. The term reconciliation came from the accounting world where it refers to a part of an audit process where (usually) bank records are compared with the company's financial records. If your books say that you've earned $100 and spent $25 in the month of March, your bank account should have $75 at the end of the month. If it doesn't, there's a transaction that's not accounted for and auditors will get this creepy smile on their face when they find it. Somewhere in the 90s the accounting auditors discovered that not everything is well in IT kingdom and much advice should be proffered (along with stern looks and knuckle-rapping with a ruler); reconciliation became an IT term.

In OIM, reconciliation is the process of retrieving data from other systems (aka sources), comparing it to what's in OIM and acting upon differences (if any). Usually this data has to do with user accounts and associated information such as roles or entitlements. For example, if OIM created a Siebel account for me when I joined the company but at some later point, a friendly Siebel administrator accidentally granted me a VP role so I could see financial reports on the entire division, this would be something reconciliation from Siebel to OIM might catch and flag as an issue. Reconciliation can be used to deal with many other scenarios as well, anything from initial data load of users and applications into OIM to periodic refresh of application metadata.

The method of retrieving data (database? web services? ferrets?!) from some application to OIM is half the reconciliation battle. The other half and probably a much bigger half (I am thinking in non-Euclidean terms here where halves are not equal!) has to do with matching or linking the record coming in from the source to the identity in OIM. If your identity management implementation is dealing with all these reconciliation scenarios and multiple source systems, the rules for deciding whether a record from a source really belongs to some identity in OIM quickly become complex.

Enter Set Theory (you saw this coming, right?). The intersection between two sets must be done based on a property (or properties) that all elements of the set share. In the diagram above, the user record in different source applications (RACF, PeopleSoft and Solaris) has the "User ID" property so it would seem that we can easily link these user records to an identity in OIM. After all, the records have a "User ID", OIM identity record has a "User ID" so we're done.

Unfortunately, the sets are disjoint. Even though records in all 4 sets have a "User ID" property, each application thinks of the "User ID" in a different way so with data "as is" in these sets, the records coming in from PeopleSoft, RACF and Solaris will not link to an identity in OIM. We have to normalize the "User ID" space which translates to being able to control transformation from some value (e.g. jsmith) to another value (e.g. JSMITH). In an ideal scenario you'd like the software that you are using for your IDM implementation to help manage the transformation rules.

One of the most common (if not THE most common) transformation rules is case conversion, e.g. going from jsmith to JSMITH. If your source system does not impose strict rules on the User ID (or other key properties like first and last names) property (lower vs upper vs mixed case being one example) or case is changed after the fact, this could cause problems with reconciliation in previous versions of OIM and lead to misrepresentation of user-application relationships. In 9.1.0.1, Oracle made a change that allows for case-insensitive comparisons on key properties coming in from source systems during reconciliation. This seemingly minor change will drastically cut down on customizations and extensions that will have to be done for systems that don't follow or enforce a naming convention.

Have you upgraded yet?

Through the looking glass

Deborah Volk — Wed, 25 Mar 2009 01:43:00 +0000

One of the key benefits of an identity management solution is the ability to collect data from various systems and use this data to establish relationships between owners (the official term is entities - users, groups, organizations) and things they own. Presuming this magic summary would be shown in a user-friendly format such that a person in a reviewer role (IT auditor, someone's manager, Homer Simpson) can get a cohesive view of the user, we're one step closer to truth. The aggregated set of entities and relationships is a foundation for how such a system might be used to meet compliance needs by answering questions of "who has what " and "how did they get it" nature. Some might even use the term business driver but our blog software filters this out based on an unauthorized autobiography context. (Information Cards, here I come!)

So you've got this wonderful set of data that you presumably give to an auditor in a form of a report...but how much of it is real? There can be an alternate world behind that mirror!

I have had some interesting discussions about getting the representation of the user to be 1) meaningful and 2) accurate.

Let's look at the first part of this. In order to be meaningful you have to understand what people want to see. Just as a rear view mirror in a car is very useful to the driver, to the passenger, they cannot accomplish much with what they see staring back at them. This is where solutions such as data virtualization, business intelligence, or even present-day whiz-bang tech such as mashups could add a lot of value on top of an IDM infrastructure. (Watch our site and this blog for updates about Identigral Labs and our experiments with these technologies). If your IDM reports or dashboard is showing you the rear-view image and you really need the side mirror image, you will have an issue getting the full value out of the system. Some might say, well, just dump the data into a reporting tool and report away. Some bolder ones might even claim that these reports are so friendly they can be manipulated on the fly, drilled down, etc. I beg to differ. This is not a reporting problem, it's a knowledge representation problem that needs a different approach, one that's centered on knowledge, context and semantic rules rather than data and tables. How do I express in SQL what mirror do I need to look at to see who's behind my car if I don't even know what I am looking for.

The second part is accuracy. Since the IDM infrastructure is both the compiler of identities as well as (often) the generator of identities, we could potentially end up with a Hawthorne effect, an old Jedi mind trick that's a version of self-fulfilling prophecy. You are going to be looking at a screen, be it a web page or a report, and you're going to be saying to yourself "This data is right, it has to be right" but how do you really know? Unless you went to individual source and target systems and double-checked yourself, there's no way to tell and that's where accuracy comes in. You don't know the accuracy of represented information unless you've compared the measured value (what's in the IDM system) to the true value (what's in the source or target system) and the comparison was done in an unbiased fashion with an acceptable error rate.

Depending on the requirement for accuracy, data quality products such as DataFlux, Informatica, Trillium (resold by Oracle in Data Integration suite) can be brought to bear on this problem but then we're getting into statistical analysis and who likes that in ye olde IT shop? The phrase standard deviation is probably interpreted as something out of a psych ward manual.

Always conduct a sanity check when looking at a report. Trust but verify!

Traffic jams (part II)

Deborah Volk — Fri, 20 Mar 2009 09:35:00 +0000

Read Traffic Jams (part I) to get the first part of the story

How do you mitigate the risk of a deadly spike in message volume without upgrading hardware? Using a cloud-based architecture is one way. If you've deployed OIM on a grid that could grow or shrink its computational capacity, you've got a way out. This is a realistic but bleeding-edge scenario and I am not aware of any customers that have done that. Thankfully the smart engineers at major app server vendors knew about this issue before the word grid entered IT vocabulary and introduced an intelligent solution - flow control. Flow control came from, well, pipes and valves. Here's a demonstration of a pipe and valve combination that is a very close analogy to a JMS queue with flow control. The valve dynamically shrinks or expands without bursting the pipe or requiring a different pipe. Pay close attention to this death-defying trick, this is the only identity management blog that combines the magic of industrial engineering with multimedia presentation to illustrate a point:

In the pipe and valve combination, the aperture of the valve is manually adjusted to control the flow. If a human operator finds out that the flow rate of material through the pipe needs to be reduced or increased, he goes to the valve and acts on his information. The flow control in app servers is smarter. That is, we can define a threshold of messages (max/min) in the queue. The threshold includes all message states - pending, in-flight, in-transaction, etc. If the number of messages in the queue reaches the threshold, the app server automatically adjusts the flow rate. The flow rate is adjusted to some number that you specify in the app server configuration. If the max threshold is breached, the valve opening will grow smaller down to a specified minimum flow rate (messages/sec) which will be used by producers to push messages into the queue. If the queue is emptied really fast so that the number of messages goes down to a minimium threshold, the entrance of the pipe grows larger up to a maximum rate used by producers.

With flow control turned off, producers and consumers could act as they please and the queue is infinite. Under most normal operating conditions no flow control is needed but if you experience a spike and corresponding backlog, flow control can be the difference between a chugga-chugga server and a puff-puff-out of breath server. In OIM 9.1, the flow control is on by default with thresholds set at 250 max and 20 min. If you're on an earlier version of OIM, you should investigate turning on flow control as a way of improving OIM performance.

Traffic jams (part I)

Deborah Volk — Thu, 19 Mar 2009 16:57:00 +0000

As you may or may not know, many operations in Oracle Identity Manager (OIM) become messages that are processed by the Java Message Service (JMS) container. The container resides inside the application server and is usually referred to as messaging service. In particular, all reconciliation events, raised requests and audit events are turned into JMS messages.

Messages are processed by the JMS container using a queue. A queue works just like a pipe: if 5 messages are pushed onto the queue, the first message out of these five to enter the queue is also the first message to come out of the queue on the other end. Messages are pushed into a pipe by producers. OIM hides the producer/consumer machinery from you but there are many producers underneath the hood, some coming from the web UI, some from the Design Console, some are driven by scheduled tasks and so on. Messages are removed from the queue by consumers. Consumers are worker bees - once they grab a hold of the message, they process it by extracting the message content (headers and body) and acting on it. In versions prior to 9.1, OIM used a single queue for ALL message types which made it challenging to prioritize and tune the messaging service inside an application server for a specific category of messages. Starting with version 9.1, OIM comes with separate message queues for each class of messages , one queue for messages that get generated from reconciliation events, another queue for messages from attestation, another queue for audit, and a few other queues.

Consider what happens when producers generate messages faster than consumers can handle them. That is, producers work very fast and push a ton of messages into the pipe yet consumers are slow because each message on the consumer side is involved in an expensive transaction with a 2-phase commit. The pipe fills up and this creates a backlog. Messages are in a pending state - they're sent but not yet received, they're waiting in the pipe. A backlog in a queue is a natural state so by itself it's not a cause for an alarm. Only if the backlog grows exponentially, a server administrator should take action. It could be surprising to many how quickly this backlog could grow under certain scenarios.

For example, consider a company that runs a marketing campaign with a goal of getting the customers to register in the company's brand new customer service portal. The campaign sends out a large number of emails and the marketing message is very popular, it offers a coupon in exchange for registration. Lots of users click on a "Register" link in the email and the registration is implemented as a web page that talks to OIM and submits a reconciliation event to attach a "Portal" resource to an already existing customer identity. This scenario could result in an extreme degradation of performance that might eventually end up in a loss of data.

To be continued...

Thermodynamics and Oracle Identity Manager

Deborah Volk — Wed, 18 Mar 2009 10:35:00 +0000

Long time ago in the land far away I was an avid student of physics . If you need a refresher course on social implications of physics and the difference between experimental and theoretical physics, consider watching a popular US show Big Bang Theory and you shall be enlightened.

Somewhere along the way I learned about thermodynamics, an area in physics that studies heat. Three laws of thermodynamics (we won't count the zeroth law or the wayward addition of reciprocal relations as another law) are the foundation of thermodynamics. The three laws postulate that energy can be exchanged between physical systems as heat or work and they also introduce a concept of entropy.

Most people are blissflully unaware of thermodynamics, entropy or when their mail gets delivered but they do know that "stuff always rolls downhill". Hey, that's 2nd law! The second law is all about entropy, essentially "chaos increases and you have to work to prevent it from happening." To be a tad more eloquent , I went to the ever-present Wikipedia and looked it up. On the page for the 2nd law was this: "In a system a process that occurs will tend to increase the total entropy of the universe". Let's be literal and liberal with this definition and see where we get if we apply the 2nd law to performance aspects of an Oracle Identity Manager (OIM) installation.

First, a system in the above definition is something that has a boundary. Within boundaries, the system does not interact with its surroundings and obeys conservation laws (total mass and energy stays the same). For the purpose of our dissertation, the system will be defined as two physical hardware boxes (an application server and a database) that have a fixed number of CPUs and a fixed amount of memory. These servers are neither aided by nor aid other servers in the environment, e.g. there's no cloud or grid so you can't expand or shrink the capacity of the servers and these machines are dedicated to hosting OIM. This way, the total computational power (or "energy") of our system remains constant.

Second, entropy is a measure of the unavailability of a system's energy to do work. In our case this means the server's ability to process instructions. As entropy goes up, then, by definition, the machine's ability to complete work goes down. Applying this to OIM we arrive at the 2nd law for Identity Management ( all rights reserved!) : In an installation of OIM with dedicated hardware, performance will decrease as more resource objects, workflow processes (provisioning and approval), scheduled tasks running reconciliations and so on are added to the system.

Now, this is all just common sense, but for those of us in the know with OIM, understand the true impact of this statement. The more processes you have, the more you have to work to keep the system running. Never underestimate the importance of performance tuning and the necessity of doing it BEFORE going into production.

Class dismissed!

What is your Agility Index

Deborah Volk — Fri, 13 Mar 2009 10:14:00 +0000

We have come up with a process and formula to score an IdM's implementation for helping customers understand where they can improve their ability to respond to business requests and changes. Obviously, this is not as easy as calculating the surface tension coefficient of my son's bath foam toys (which have an amazing stick-to-any-surface propensity) but I wanted to put up a tiny quiz. This is a cheat-sheet version of an exercise we go through with customers but I thought it would be amusing nonetheless. I give you How Agile Are You quiz.

Pick the answer that best describes your team.

1. Do you know where all your code, configuration, and documentation are kept? If you don't, does any full-time employee at your company know? (Contractors or consultants don't count)

A. Yes, absolutely.
B. No, but someone on my team knows.
C. No, I rely on my managed service provider and they know everything
D. Code? We don't need no stinkin' code..

2. Who does your releases of your IdM solutions?

A. Operations, of course. Who else?
B. Operations, with developers sitting close by (or calling from across the ocean)
C. IdM developers. Operations typically take over several weeks after the go-live
D. We have no releases, we just PUSH!

3. How many issues get introduced with each new release?

A. Full testing is part of every release and we never have issues
B. One or two issues might creep up, but typically we are good
C. We never seem to know what exactly will be impacted, but the system doesn't fail completely.
D. We still haven't resolved issues from our initial deployment
E. Don't ask, don't tell!

4. Are IT/business owners empowered to manage access to their apps without involving IdM group?

A. Application owners have the ability to define their own admins and approval workflows without any developers
B. We have an access request system that is online that allows people to request changes
C. The IdM team meets with business owners once a year to determine what to work on.
D. Business people are involved in IdM? Mon dieux, quelle surprise!

5. How long does it take a new member of your IdM development or support team to come up to speed?

A. In-house training for IdM team members takes a week , then they are good to go
B. After several months, I think they got it
C. I have seen sky scrapers built faster
D. We're still waiting for that brain osmosis technique to be commercially available

Scoring: For each D, give yourself 1 point, each C - 3 points, each B - 4 points, each A - 6 points (you will quickly see the issue of loving prime numbers for a scoring scale). If you've answered E to question 3, subtract 5 points from your overall score.

If you scored:
0-9: You need to step away from IdM and take a deep breath. Then call us :)
10-20: Your IDM karma needs work but you're heading in the right direction. Look at how your development is working together with operations and business
21-29: Good work, please let us know what you eat for breakfast
30: WHO ARE YOU?!

Development lifecycle and identity management

Deborah Volk — Fri, 13 Mar 2009 00:56:00 +0000

When deploying an identity management solutions, you will come to know that the development lifecycle will be tightly coupled to your identity processes . Even if development might not produce actual source code and deal strictly with metadata and configuration of tools, it's still a development activity in most IT shops. Just like loose lips sink ships, loose process management is liable to scatter the enterprise ocean floor with debris of all kinds. Caveat emptor.

I strongly feel that sound change management practices have to form a foundation of any identity management implementation. Since the very nature of identity management requires the interaction of tools with business policies, processes, and applications, the ability to evolve is essential to the quality of implementation. Some analysts might label processes that can evolve quicker than the rest as agile. I am introducing a new metric, an Agility Index. The Agility Index ranges from 0 to 29., 29 being super-agile, liquid processes. (Why 29? It's a nice prime number). In an implementation with inadequate change management, deployment (among other activities!) quickly becomes chaos. The Agility Index of such an implementation is close to zero.

Homework: consumtpion of Adaptation as a moral fiber for implementing a change management process

Hello, world!

Deborah Volk — Wed, 11 Mar 2009 15:52:00 +0000