Talk to any Sun IdM consultant and he/she will give you the same old elevator pitch about Sun IdM. That’s great if you were a CEO who is buying IdM. But if you were a developer who wants to use brains and understand things from first principles rather than from a step by step recipe book, then you will like my blog – Because I peel out the useless layers of marketing, hype and “monkey see-monkey do” recipe guides and get straight to concept and explain this at the conceptual level. Then I let you to exercise your brains to figure out the rest. I trust your intelligence. I dont want Sun IdM developers to be “monkey see-monkey do”ers.

In today’s blog, Iwill  explain the IdM configuration object mayhem in a typical IdM lifecycle and VIDT in greater details. In my next blog, I will layout some uncommon ways of approaching and understanding Sun IdM using UML. (I hope my readers come from a OO background and know Java and UML)

Abstract

Sun Identity Manager deployment experiences have added the maturity to the delivery model. VIDT is the outcome of thus gained maturity. VIDT captures several best practices in IdM implementation and almost productizes them to help jumpstart a IdM project. It is possible that VIDT workings can appear confusing on the surface. This blog probes beneath the surface to reveal why it is, what it is and how it works.

In the process, the blog series will provide a overview of VIDT logical and physical architecture, role of VIDT in a IdM deployment lifecycle, problems solved by VIDT and new challenges introduced in a IdM project using VIDT and how to address them. Future blogs will also cover the patterns and best practices that are implemented by VIDT as time permits.

1. Identity Management Project Lifecycle

This section covers the Sun identity Manager in the context of execution of a Identity Management project. Most importantly, it highlights a few logistical problems faced in Identity Management project with Sun Identity Manager.

1.1 Sun Identity Manager Overview

Sun Identity Manager is the granddaddy of configuration. Sun Identity Manager 7.1 has 50 different types of so-called IdM objects. Each type of object can have 5 subtypes and up to 100 instances. Identity Manager projects tend to be configuration heavy as most of the features of the product are exposed and customized via the IdM-object configuration. Each IdM object is essentially a xml snippet (conforming to waveset dtd) and stored as a single record in IdM repository. Throughout this document any references to xml snippet, IdM object, or object are interchangeable.

Sun IdM itself ships with thousands of objects. Some of them are internal and core to IdM, while others are essentially meant to be customized. A lot of functionality can also be configured via the administrative interface. Even the configurations from an administrative interface translate into xml snippets. Figure 1. shows this.

Any project life cycle involves building a baseline in an environment. Then it has go through the iterative cycles of configuration, development, testing and deployment in multiple environments. test and then deploy to several environments including production. The automation of this process makes it defined and repeatable. IdM projects are no exception. One thing that especially stands out in IdM project is that they involve heavy configuration. Configuration done via the administrative interface involves manual intervention and prone to human errors. The solution for this is to “create the configuration once and deploy everywhere”. Sun IdM provides the hooks to automate the deployment of the se objects. Creation and testing of the objects forms the rest of (also bulk of) Sun IdM implementation.

1.2 Where is my XML?

As noted earlier, Sun IdM implementation is mostly about configuring and deploying the xml snippets into the IdM repository. The xml snippets can be put together by hand or using a logical interface like Business Process Editor (BPE) or the newer NetBeans IdM plugin. In either case, they are imported into IdM repository through a ant build/deploy (The xmls can also be indivdually imported into repository via a special “import exchange file mechanism, but the environment specific parameter replacement will not occur). Many xml objects share a logical relationship because they are part of a single business requirement. However the xmls snippet validation is limited to basic dtd. Complex type based relationships are not completely enforced at the creation time(Netbeans and BPE do some type based validation at creation time). At runtime, the association between the xml snippets is resolved and the IdM tries to get all the defined objects and connect them together to execute the defined business requirement. In doing so, it may fail only at runtime. In addition, the number of xml snippets needed to meet even a modest set of business requirements can be quite large.

The two factors mentioned above overload the IdM implementor with creation of xml snippets (some boilerplate, some slightly customised and some highly customized) during project initiation, which really can be automated. Additionally, considering the fact that IdM is a “sort of” vertical, most of these basic requirements across IdM implementations are more or less the same and need slight adjustment to meet the needs of individual customers. Velocity Identity Deployment Tool (VIDT) was born out of this necessity.

2. What can VIDT do for you?

VIDT is a tool aimed at solving the problem mentioned in the previous section. It is a tool aimed at jump starting the IdM implementation. VIDT lets the business analyst or the implementer to input most of the basic business requirements through a simple point and click interface. A set of xml snippets are created by the tool to meet the business requirements.

In the beginning, the number of xmls generated by VIDT can be a bit overwhelming. However the structure of generated xmls remains same across multiple projects. The generated xml snippets follow several identifiable patterns, best practices and defined process flows. Over time this consistency becomes a familiar territory. Advantages of pre-defined patterns, practices and processes are manifold.

First of all, it cuts down project time by generating the pre-wired xml snippets. It does this by eliminating the need to creating most commonly needed xml snippets from scratch (not to forget the time needed to verify all those are of correct type and correctly linked)

It moves the thought process from xml snippets to actual business use cases. It makes cross-training across projects is easier. Spotting the patterns in a project jumpstarted by VIDT becomes second nature to a VIDT trained implementor. Health checks become easier due to the same reason. Consistent structure can work wonders by making the projects defined and repeatable.

In addition, it also generates valuable documentation automatically for requirements, design, level of effort and Statement of Work. Each of these is a timesaver by itself.

At the beginner level, it is okay to treat VIDT as a blackbox that outputs wonderful xmls based on business requirements. But a deeper knowledge of the tool is necessary to fully exploit its capability and understand when it cannot be used. A deeper knowledge is essential for resolving the logistical and technical challenges that arise with the usage of the tool in a IdM project.

3. VIDT Logical Architecture

Figure 2 shows the high level logical architecture

On the left use cases are entered into VIDT using the UI. Use cases are definitions at pseudo business level – for instance – define a Active Directory resource (easier than IdM console) and a use case might say – I need activesync with Active Directory and voila a bunch of xmls including workflow, forms and Xpress code to support the use case (all based on best practices) get generated. They can be further tweaked then at xml level. Internally the use cases get stored as intermediate xmls using Castor which then generate the real XMLs when requested. Incidentally all this conversions and even the UI is based on Velocity (a open source tool – Find it in Apache) templating. Hence the name VIDT !!

More to come in future blogs