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.

"Oh, I see now. Virtual *IS* Meta!"

Got to love this posting by Phil Hunt.  I've been watching this bit of diatribe back and forth, especially between Dave Kearns and Kim Cameron.  It's a bit like the old story about six blind men trying to describe what an elephant is, each only feeling one part of the beast. One says "it is like a wall", another "it is like a tree", and so forth. 

SO, are we really talking about multiple problems, or one problem with several aspects?  do we need multiple solutions, or is one elephant enough? 

This discussion is good, and I hope everyone is reading all the posts.  They are essential arguments and these guys are no dummies.

Jackon Shaw << Jackson started it here!! / blog home page
Dave Kearns
Kim Cameron
Phil Hunt
Felix Gaehtgens

if I missed someone, let me know... oh yeah... I put in my two-cents here. :)

Worst practices: Exposing IAM blunders

Joel Dubin exposes the most common IAM blunders, and enlightens information security professionals on how to prevent these mistakes. OK, its a bit basic, but they are still problems. I thought the article was uninteresting, but two things caught my attention:

1) multiple logins for multiple applications (listed as the sticky note syndrom)

2) "ghost" passwords - which are more precisely "ghost" accounts, not just passwords, they are logins that should not exist.

If you are correlating any and all identity profiles in your enterprise, then these orphaned accounts can be properly detected AND accounts could be linked to aggregate same-user profiles from the various applications, enabling true SSO. No more multiple logins, no more "ghost" or rogue accounts. 

Utilize an abstraction layer to virtualize sources together, correlate identities, and provide provisioning for identity lifecycle management. Delivering identity data from a central virtualized source can solve this problem.  If your environment is a dynamic and ever changing business (and who's isn't these days) then this is the only way to go. 

read more | digg story

Single Sign-On

There was an SSO webinar today by Quest Software.  I would like to thank them for actually putting some content into it and actually explaining what their solutions offer.  I have become a bit weary of webinars so laden with marketing message, you really have no idea what the technology is offering you or if it will fit your infrastructure or not. 

The recording is available here.   My big take-away's had a familiar ring to them, as I have repeated some of these points too many times to count at this point.  Quest has an offering of multiple applications for an SSO package.  Also, check out Mr Shaw's white paper on the subject. 

First SSO means different things to different people; enterprise SSO, Federated SSO, Web SSO, Single Password, Reduced SSO, etc.  But I believe that some things are the same regardless of the "type" of SSO you want to deploy.

Shaw had a nice list of the "perfect world" for SSO:

• Standards based
• A single password or login
• A single directory
• Strong Authentication support / multi-factor authentication
• Support for multiple platforms
• Support for multiple applications
• Support for "thick, thin, and web applications"

This week I have been faced with some of the problems in solving SSO integration problems and how to deliver identity information to enable SSO.  A client had previously deployed a SSO solution for 35+ applications, using only two sources that were disjointed. Now they were faced with integrating another data source that contained intersection of identities. Some users in the new source exist in one of the other two sources - now the entire SSO solution collapses because it was based on the idea that they would never face an overlap of identities within the repositories.  Again, the answer was to deploy a virtual directory server as the abstraction layer to simplify the management of identities in these, now jointed data sources.

The lesson is, yes you can deploy an application without building a unified infrastructure, but you take a big risk.  When new data sources need to be incorporated (including acquired applications with their respective user-base), you can expect problems. 

PLAN AHEAD.. if you don't need to solve this integration problem now, YOU WILL at some point if you expect any level of scalability.  YES, it is possible to have one source for all your users, without replication.  By using the features of a virtual directory server to create a true union of identities (identities are correlated appropriately and duplicates are eliminated) and extend those entries with additional attributes from the needed data sources, you provide an identity infrastructure to provide authentication and authorization services to your SSO application. 

 

Global Key Mapping

I read an article a few days ago in the latest issue of DMReview titled, "Global Keys: A Unified Key Mapping Architecture".

I visited the authors blog at http://www.globalkeysdesign.com/global_keys/blog_index.html and found it to be a good start of a very important discussion about creating a centralized mapping of keys for multiple data repositories that contain equivalent data (or identities).

Check out my post
http://www.globalkeysdesign.com/global_keys/2008/01/what-me-work.html