The Safari of Identity

I thought I would have a bit of fun and continue my analogy about the jungle we often find ourselves in when dealing with the sticky issues (and often unknown) of identity and identity management.

African Safari's were plagued by slave trading until the British put a stop to it in 1896, in the shortest battle in history (38 minutes).  The past for identity has been similar, you were forced into solutions, sometimes without your consent - you didn't really know what was happening or that you were even solving what we call an "identity" problem now.  You were just trying to get authentication services to work perhaps.  You saw a problem and solved it.  Now you have choices, you are free to chose and the options are a bit more clear, but there is still a jungle, and navigating it can be difficult.

So, now you have choices, but just like going on Safari, never go without someone who has been there, just as Stanley and Livingstone never went without their native guides, the most famous of which were Chuma and Susi. These two were the ones who were responsible for carrying Livingstone's body thousands of miles so it could be transported back to England for a proper burial at Westminster Abby in 1874.  There are "guides" that don't specialize in much, they just "know everything".  Identity is unique and there are unique issues, you can't trust just any "data" expert.

So, first lesson with Identity Safari - don't' be a slave to the biggest company or solution, be creative and look around.  Second make sure your choice of products and consultants specialize in identity from the ground up.  Not just to add to their "global suite" of "stuff" they can sell you.  They really don't know what or why behind these solutions, such as virtual directories. 

I noticed an interesting short post from James McGovern in which he states:

"Mark Wilcox, Nishant Kaushik and others have discussed the virtues of virtual directories but have at some level done themselves a disservice by describing them as glorified proxies."

VERY TRUE! Here is an example of what I see as a failure to know your jungle. Do you need more than proxy?  OF COURSE!  But if you see virtual directories as nothing more than a glorified proxy service you are limiting your view of the jungle.  When your solution revolves around old ideas and paradigms you will have the same old results and complexity of the past.

The solution at this vantage point is that you need more help, more products, more data stores, complex synchronization, and then start searching for SOA solutions and new ideas of architecture they will recommend you adopt.  WAIT! STOP! Don't burn down the jungle just because you have a poor guide.  It's really not that difficult when you have the right information in hand, with tools prepared for now and what will come. 

I was going to post more about this misunderstand in the virtual directory market, but here is a good newsletter article from Oct 2007 that explains it well.  Check it out. 

 

Lost in the Jungle?

To add more thoughts and explanation to my last posting, "Are we lost?"

The idea is to not cut through the jungle every time we have a new initiative  At least solve the integration problem, once.  Don't reinvent the wheel every time you have a new application or new initiative.  Don't replicate data everywhere, employ complex synchronizations, and in general make everything 10X more complicated, compounded with each new deployment. 

Build one platform to plug everything into.  Sounds too good to be true?  Yeah, maybe it's not "everything" yet, but almost.  AND I believe this technology will evolve further and will become even more useful. 

This doesn't address the plethora of applications and methods available in the IdM market, but it does give you the opportunity to not care.  You can integrate any application you want, use any protocol, any schema, any data structure, any security means, any authorization/authentication schemes you want, as many as you want.  That is the power of virtualization. 

For me, within the virtualization platform you need proxy, data modeling, synchronization, service bus, and the ability to do build a correlation index (key mapping) if needed.  If you have these things within a virtualization "platform", then you will be ready to face the future.  You know where you can start, at least your identity stores are integrated into a common platform.

If you need LDAP, you have it. If you have the need for web services, use it. If you need to concatenate, transform, and otherwise alter objects, you have the tools.  If you need to query data, you can, if you need to push / synchronization data, you can.

The beauty is you do this work once; integrate your sources, then you just need to build a virtual object (e.g. in XML) to meet the needs of a new application or initiative and how you want to access it.  This is where you save time, money, and the headaches. 

You might still get lost in the IdM jungle, but at least you have a point of reference, a stronghold in the jungle.  A starting point instead of starting from scratch each time. This means you are free to choose a solution or application based on the business needs and its own merits, not your environment.  Otherwise you get lost in trying to calculate integration costs, deployment times, feasibility studies, and so on.

Solve what we can today, let others worry about the future. "Tomorrow has enough worries of its own." Simplify your workload, use virtualization to solve the problem of identity integration, don't stay lost in the jungle.

Are we lost?

There is a posting of interest recently by Pamela Dingle, you can check it out here.  I love to see people talk from their gut and talk about real issues, without the marketing guff and fluff, just real-life observations. Her recent posting "Catalyst Epiphany 2 - We're a little lost" points out the fact that identity management is all over the map.  I agree, sometimes I feel like companies are throwing solutions as fast as they can and hope that something sticks. Identity solutions have become a type of jungle, one that you never know exactly what to expect when you get inside.  Yes, there are explorers who have been there, and have reported back to us what strange and deadly creatures you will encounter on your own journey.  But where are the roads, the standards?

When my personal life gets like this I know it is time to slow down and take inventory, examine the issues. Perhaps this is where we need to start, to slow down and start to examine the underlying issues and what the real needs are in Identity and Access Management.  I have been to this crossroad, and I think this is why I believe so strongly in the identity virtualization platform (which virtual directory is a part of, and what started this concept).  It has given me an anchor point to start from; tools in my pocket like a swiss army knife to address the multitude of issues that plaque identity integration.

 

Active Directory Reality Tour Travelblog: James' unanswered questions...

Jackson's Identity Management & Active Directory Reality Tour Travelblog: James' unanswered questions...

As most of you know, I try to keep up on some blogs out there, one of which is Jackson Shaw's.  I wanted to throw in my two cents on a couple responses he made yesterday to another blog's posting (James McGovern). 

JAMES: If pretty much every Fortune 500 enterprise (acknowledging that Sun is the standout oddball) has Active Directory, why should any of them consider yet another product? Why shouldn't they simply wait for Microsoft to include virtualization support in Active Directory? Please no responses that are "tactical" in nature nor attacking Microsoft because they never get it right the first time.

JACKSON: I agree. Why should they? It's obvious - at least to me and I am pretty sure a lot of other folks out there - that identity management has evolved beyond directory synchronization and metadirectory to include the concept of virtual directories and all of what that means. Is there ever an ideal product? Sure, for a period in time. But times change. If Microsoft isn't thinking about how to solve this problem I would be surprised - oh, and let's not forget that a possible solution is to do nothing.

Yes, Microsoft already has several options to managing the problems solved by virtual directories, if you are a primarily Microsoft shop (if someone really wants to know, let me know and I will get you a list).

They (Microsoft) are interesting in selling more products, and keeping you "in the fold", virtual directories tend to give you more freedom to leave the sheep pen.  If you are a Microsoft shop, then their products integrate relatively well with their other products.  I'm not as magnanimous in my feelings that Microsoft is particularly interested in the problems that are primarily encountered in a non-Microsoft centered architecture as Jackson. 

Also, this idea of using AD for a central identity store, umm not so fast.  There are a couple issues, yes almost every enterprise had AD, but that doesn't mean it is their central identity store.  (1) AD stores lots of information, primarily related to its original design of being a NOC directory.  Moving all your needed identity information into AD is just a bad idea in the minds of a lot of architects who don't want to "tinker" with AD operations.  I would agree with their position here. (2) Also, it is not offer high enough performance for many deployments, so then you replicate instances, and things get more complex.  Say a SunOne Directory Server is performing 5K-6K quires per second (qps) on the same hardware you could see AD performing only 2K-3K qps or less.  I've seen AD doing less than 900qps.  (3) Then you have the issues of non-standard LDAP operations, there is a rather long list of things I have compiled over the past year that AD is just not LDAP v3 compliant with, not the least of which is most applications want to see "inetOrgPerson" objectclass, not "user". These little things can hang up projects for longer than you might think. Yes, again Microsoft has "work-arounds" but if you aren't committed to being a Microsoft customer no matter what, why would you try to go this route? 

JAMES: The ideal situation says that a software company should be able to write an directory enabled application without requiring virtual directories but reality is a little different. Wouldn't the thought leaders in this space without resorting to tactical responses agree that instead of pushing products/tools in this space we have to help others understand the <> so that this problem goes away? Even products by companies with really smart individuals such as EMC still get this wrong. Does Oracle have any thoughts on helping people avoid virtual directory by writing better directory-enabled applications or is it better to bury one's head in the sand, ignore the problem of others and simply respond with point solutions.

JACKSON: James, you are right. Software companies need to do a better job when they write directory enabled applications but it is a long road. The average application developer still needs to do a better job managing identity, authentication and authorization.We still have a long way to go unfortunately.

Sure, in the ideal world... well maybe... This exchange of ideas makes more sense if virtual directories is only viewed as an LDAP proxy, a way to aggregate multiple directories, centralizing data sources.  They do more than that, they

• integrate applications, databases, web services, and directories,
• disambiguate same-user accounts to integrate identity information (even establish previously non-existing key mapping),
• overcome performance issues of underlying sources,
• "push" information for provisioning
• use an ESB for messaging / synchronization,
• data model new views of data,

and the list goes on-- you face one or more of these things with each new deployment.

I prefer the idea of having a central access point for identity, and just creating a new view based on my new requirements rather than configuring applications over and over, duplicating my efforts.  I do the work once and my applications have one place to look for the information (for authz and authn).  It saves A LOT of time. Even if you do have an application that supports directory services very well such as CA's SiteMinder (which offers a lot of functionality to connect multiple sources), but still you configure all this and it is only consumed by SiteMinder.  I've lost all the effort I've put into this when I have another deployment that needs to consume the same or similar identity profiles. There really is a lot of duplication of work here for different applications. 

Which is quicker?  Configuring each application's virtual-directory-like component, or just creating a new view in a virtual directory to be consumed by a new application?

I would be interested to hear with others think....

More Complex Identity Integration

I have had some questions recently about what I mean by comments about "more complex integration".  I have had a few people ask me through my blog and recently at Catalyst in San Diego, and so perhaps I should clarify.  What IS my point of reference to "more" complex? 

Quoted from http://identityinfrastructure.blogspot.com/2008/02/oracle-virtual-directory-webinar.html:

Identity Data Delivery: Oracle Virtual Directory Webinar

... offer solutions to more complex integration problems that you can face that require more feature sets...

My point of reference was in relation to some virtual directory products which are basically LDAP proxy's.  It is not always apparent the issues you will face when planning an identity deployment.  So here are a few examples of what I would consider out of the scope of most LDAP proxy services.

1) integration between profiles where a common key is not present

when a common key is not present in all data sources, this requires correlation and complex matching rules to be used to disambiguate users across systems, for performance you need to do this off-line processing (this is something many virtual directories would try to do dynamically, in real-time for each query, if at all). 

2) Projects that could benefit from "push" not only "pull" technology.

Sometimes to achieve identity integration, you need to provide for only only "pull" (search/query) but also "push" (synchronization) technology (needed for things such as provisioning). Being able to leverage ESB technology for example has huge benefits to being adaptable to future needs. 

3) Deployments that require a different tree structure than what exists in current identity sources.

For some projects, the integration of the sources requires a tree structure that does not match any of the existing DIT's.  It is necessary to have the ability to design a new DIT based on existing information, but in a different structure. 

4) Deployments that require, or could benefit from information that lives in legacy applications, accessible only via web service, and/or one or more databases in which the data you need is located in multiple linked tables (complex relationships).

This requires a preservation of the context of the objects and the ability to build a modeled view of those objects based on the requirements of the initiative.  This is again out of the scope of an LDAP proxy service that is offered by most virtual directory vendors.

Also, think long-term.  Often we do not care enough about other feature sets because they don't see the need today.  Integration issues tend to get more complex, not less complex over time. Just because you are not facing these types of issues now doesn't mean that you won't the future. More times than not we avoid using certain identity information only because of the complexities in doing so.  There are certainly more options for identity integration than those of LDAP proxy capabilities offered by some virtual directories.

The "Virtual Storm"

Too bad I didn't see this before my last post!  This is great, and actually humorous, especially if you have been following any or all of the virtual / meta / & "my stuff is better than your stuff" discussions since March '08.  Jackson started it! (can you have to hear the child-like finger pointing in my voice)

But seriously, I think this interest and effort by people trying to make sense out of the tools and methods available and solve real problems of identity in the enterprise should tell us something.  The problems still exist!  I love debate, that means people are thinking about it. Progress is at hand :)  

SO - go read this post!  :) 

Cache, Enterprise Service Bus, Virtual Directories

I was trying to catch up on some of the discussions from the past month or so. Check this posting from Mark Wilcox.  Mark does a good job of being a peace-maker of sorts, trying to organize thoughts from different bloggers such as Dave Kearns and Clayton Donley.  There is definitely confusion around what each author is talking about.

It is my position that you need not only what Oracle and others would define as a virtual directory, but that service should include the other tools necessary for a complete solution; cache, ESB (enterprise service bus) / Messaging, LDAP proxy, data modeling, key mapping/correlation, web service, etc.  This is what identity virtualization is all about. You have different problems, you need different solutions (see what Jeff Bohren says). Virtualization allows you to use your existing data stores and use it the way you need it. You should have LDAP, SQL, web service capabilities - not limited to a single protocol.  You need push and pull of data (dynamic access and message bus) and performance guarantees (cache).

BTW it is funny to watch some of these guys fight against cache.  WHY?  We use cache everywhere for performance reasons.  No one argues that CPU's aren't fast enough as evidenced by the presence of cache!?! Or your that the internet needs to be "fixed" because your web browser has cache. Cache is everywhere, there are real applications for it, people use it, people need it.  So, why the anti-cache rhetoric when it is talked about in terms of Virtual Directories?  It is a mystery.... most all virtual directories have at least one form of caching option... 

It has always been frustrating to me to see large companies bully customers into accepting their view of the world.  So, what I mean in this example is that some large vendors will tell you that if their virtual directory isn't fast enough for you, then you have a problem with your sources, it is not their problem. They will be glad to sell you more of their "stuff" to fix "your" problems.  Well, I prefer to keep my lunch money than to give to bullies.  :)   Think about it....

SaaS IdM Management - Flynn

Matt Flynn has an interesting post about what he calls SaaS-ish identity management.  The idea is to outsource your IdM managment, the dicussion is primarily about the objections to this idea within an organization. I can see how this can be useful, especially to smaller organizations who can not afford project teams, expensive IdM management packages, and the ongoing expense of maintaining these systems.  This is certainly down-the-road, but worth taking note - this could certainly become reality. 

There are certainly segments of the IdM market ready to see commodization, and this could be one more way of doing just that.