Combining that UML centric/domain driven idea with existing VIDT and deriving inspiration from Naked Objects (and similar) framework, I came up with a novel concept for next generation VIDT. This approach will take VIDT a level higher and would solve additional problems that VIDT cannot solve as is. I developed the approach on my own time – based on my understanding of Sun IdM, VIDT, Java, JavaEE and of course OO. I proposed it to the Sun management, the idea was accpeted, but nobody had the commitment to take a goose laid golden eggs (meaning billable – that is me) and put on a  project that would take the VIDT tool to next level. The idea was that apart from travelling every week and working insance hours, I could as well contribute to developing the product. That was too much to chew at once.

Anyway, a more detailed explanation of this approach will be provided at a later date. For now, enjoy the presentation below. It is chock full of ideas.

Download (PDF, 676.87KB)

The bootcamp methodology for teaching Sun IdM was too much a like a cookbook. Instead of getting to the fundamentals and concepts and building it from there, the approach was – Here is a button, here are few drop downs, Clikc them and you will get activesync., Oh by the way provide a proxy admin for ActiveSync, but remember not to attach a user form to proxy admin. Oh and here is how you create a deferred task scanner. This approach was totally unappetizing for me. I am a JavaEE developer and architect  by profession and understanding concepts, capturing the domain in UML lay at the center of whatever I did for my customers.  I thought – IdM should be no different. Hence – after a few painful iterations of following the cookbook, I decided to dig under the hood – look at the database created by IdM, analyze the data and come up with how IdM is logically under the hood. This was of course UML (No surprises there – huh ?)

So, while other wannabe “IdM architects” were mugging how to do each task via the cookbook approach, I went on a tangent and approached the domain from common sense approach. As I uncovered each relation between various IdM components – I drew UML on paper. After I had captured enough of those relations, I converted them into electronic format. A cookbook would only address a few pre-defined questions, but my UML was helping me address all sorts of questions that customers posed.  With just a week of bootcamp and a two weeks of self learning using the aforementioned approach, I emerged as a real productive IdM developer in my first project, implemented it very well and was architecting more IdM solutions. I was productive on ground real fast.

Download All UML Diagrams as a ZIP

And here I am, providing a few of those UML class diagrams as samples for you to understand Sun IdM from grounds up using concepts than cookbook. Use these as starting point to build, extend and share your understanding.  As the old adage goes – A picture is worth thousand words. Whoever said it had UML on their mind. So, each of these diagrams captures a wealth of relationships between components and you could look at each of those relationship and conclude what configuration changes are needed for a given task. Observe the relations, navigabilities, multiplcities, dependencies and inheritance depicted to get a deeper level of Sun IdM understanding

IdM Top Level View

Login Module Class Diagram

Relation between IdM Forms, Rules, View Handler and XPRESS

Relations between Waveset User, Account and password policies, Forms, Resource assignments etc.

Relation between a Waveset User, Resource, Reconcilation, ActiveSync, scheduling, admins and forms

Relation between User, Resource, Admin Role, Admin Group

As you can see this material is not meant for glossing over. Rather it is meant for focussed study with deep introspection. Meant for serious readers only

Enjoy and provide feedback. And if you contribute, dont forget to provide me a link to your UMLs

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

Sun IdM is a very extensible product. Every piece of functionality is loosely coupled.  Everything is configurable in Sun IdM.  Even to the last bit. How is this achieved?

Answer: Configuration Objects

Configuration Objects are pieces of xml to configure a bit of functionality. Large number of such bits come together to define the behavior of the product.  Like communism – the idea is great, but implementation sucks. This is how it causes unthinkable nightmares

1. All configuration objects are xml and stored in database with a id and name.
2. Developer can change any xml object and write back to the database/repository
3. Database will happily accept the xml as long as it is valid and confirms to to the dtd
4. Problem comes during runtime – Another executing object looks for a previously existing xml by name or id. If it does not find it, there is a runtime error. If it finds it, but somebody has changed the behavior of the called object/xml by modifying it and introduced bugs, again it results in  runtime error.
5. IdM consultant’s biggest headache when at a customer site  who has been using IdM for a while is exactly this. One of client’s developer has inadvertantly changed a xml and put it in database. Nobody knows which one. A lot of these xml changes completely skipped the source control and done by just committing the new xml to the production database.
6. Client has changed a xml behavior but retained its original name. During product upgrade all xmls with out-of-the-box names are replaced. Gone are the customizations

With 1000s of xml pieces, it is hard to find which pieces were interacting together before and after and the system is broken. Like I said before, the idea is great, implementation sucks. Tools such as VIDT (Velocity Identity Deployment Tool – Bad name, good implementation) came into being just to address this mayhem a little bit.

In my next blog, I will describe in detail about IdM project life cycle and the importance of VIDT and a logical description of VIDT.