Identity Management 2.0 ?

Darren Calman posting something that has attracted some attention from Matt Pollicove and from Ping.  I think it is worth paying attention to. You will find some good historical and pragmatic information, but of particular interest to me was what was stated about identity virtualization.

Virtual directories are being touted as a IdM 2.0 by Matt Pollicove, as a "identity virtualization" service.  Virtual Directories have been around for almost a decade now (8-9 years).  Perhaps their value is being increasingly realized.  The need for directories is not going away soon, their secure hierarchical structures give context and the high-performance needed for such things as web portals, which could be servicing millions of users.

I believe that the need for this type of value will continue long term, even if we see a decline in the use of directories and LDAP  There persists a real need for applications to understand the semantic relationships that are not easily represented in more traditional, and more prevalent RDBS AND in security or externally facing applications (which user volume is typically higher) a real need for high-performance and availability that can not be easily achieved through other database systems.  Using a thin virtualization layer on top of other databases to provide the functionality of directory for security, but not the primary storage of data, is an interesting evolutional possibility in the identity space. Security, search, and querry could still be serviced through this layer, but insert, update, delete operations could be handled by an RDBS, maximizing effeciencies.

The virtual directory offers this "virtualization of identity", solution, where relational tables can be presented as hierarchical views, accessible as LDAP or other protocols as needed. To acheive this value your "identity virtualization" service must offer:

1. data modeling (as to not constrain you to the existing structures if a different view is needed, but still maintain the existing relationships),
2. the ability to maintain high performance (because if back-end sources are NOT primarily LDAP, there are complex joins, or cross-application searches needed for authorization, performance will not be high enough),
   
3. a choice in deployment (proxy AND data model; dynamic AND event-driven update of an instantiated model (materialized hierarchical views) and
4. choice of protocols (not only LDAP, but a object oriented system that is more agnostic about delivery, at minimum you should get LDAP, SQL, and web services)

Perhaps we are about to pass the "hype" stage of identity management, but that means it is now is time for the heavy lifting to begin, the work of deployment and implementation.  Is your infrastructure ready?

 

Burton Id Correlation Stressed

Burton is hosting a telebriefing about identity correlation.  I have to say I'm a bit surprised, but think it's great.  (see blog posting by Ian Glazer here)

It is true, if you want to have true access management you have to start with being able to correlate accounts. Without this you have no way to even know who has access to what, much less be able to audit, control, or monitor it in any way.

Correlation enables "Access Certification, Role Mining, Entitlements Management, Policy Evaluation, Identity Auditing, and numerous other custom services developed by our customers... password management and user provisioning.  The reality is the correlating of accounts to people is a requirement for all identity management exercises.  "

How true it is.  You have to establish a mathematical union of identities.  Think back to basic set theory, you have to establish a record where each user is represented exactly and only once. Some would call it "global key mapping", others "correlation", or even "account linking".  Whatever you call it, the idea can still be reduced to the old concept of creating a union of two or more sets. 

Here is another great point, "Here's a tip to enterprises out there - ask your software vendors and deployment teams what capabilities they have to help facilitate this correlation.  Ask early and before you start down the path of an identity project.  Make it an on-going process governed by your overall identity management program."

TRUE!  Do this planning early.  I was talking with several integrators this past week at DIDW in Anaheim, and its amazing how much work you still have to put into convincing people not to just buy an IAM suite, but rather to solve some integration problems (i.e. correlation) Seems like I never stop talking about this, but glad to see Burton is taking up the mantra also!  :)   If you can, join the teleconference on October 1st and 2nd.

 

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. 

New VDS Releases

There have been a couple of announcements in the Virtual Directory World.  I would be remise if I did not make mention of them.

Radiant Logic announced (Jun 23) the release of VDS 5.0. Here are some of links from the announcement. Press Release, Government Computer News, DM Review, Campus Technology

The new VDS offers simplified use of virtual directory technology, turning complicated LDAP operations into simple point and click tools. VDS 5.0 has built in wizards and templates to make the most common deployments even quicker and easier.  The new admin console boasts new scenario-driven wizards, so that users can easily deploy various identity and access management tasks.  Scenarios include web access management, Active Directory object and attribute mapping to SunOne (or other LDAP v3 directory server), and Active Directory forest aggregation.  There has also been support added for role-based delegated administration

They also added a very cool new Web-based remote admin console.  If you get a chance, check it out.  It was built on Abode's new Flex technology and has all the features of the server-based console.

As LDAP ages it is important to see that vendors are automating more of the LDAP functions. The need for hierarchal structures still persists, and LDAP is a perfect fit, applications consuming information from LDAP based repositories are not going away anytime soon. I have already heard this new version of RadiantOne VDS referred to as the "VDS for the rest of us". 

Optimal IdM also announced the release of their new Virtual Directory offering today (June 30th), the Virtual Identity Server for Enterprise Group Management.  This is a specialized release of their VD based on .NET to help with the known cumbersome task of AD group management. 

Their close partnership with Microsoft shows in their product.  Not only it is .NET based, they address AD issues with sharp precision.  Certainly Microsoft centered shops should take notice. I also read a good posting about this release on Jeff Bohren's blog. Jeff relates these new tools that are emerging from the virtual directory vendors as specialized "arrows" designed for use for specific problems.  I could not agree more.  You need a "quiver" of tools at your disposal to solve the unique and changing requirements of your identity environment.  Having a flexible identity infrastructure that virtual directories provide, is in my opinion essential. 

 

 

Identity and Beyond!!

No, I haven't turned into Buzz-Lightyear. 

I found this diagram today, by accident, by searching information on WAM architecture, it is not into the details I was looking for, but I actually really like it!  Obviously its not just was Web Access Management...  check it out...

This is a logical layer you might see related to identity, security, virtual directory, etc - but could be used for much more.  IdM would just be one consumer of the service layers that are pictured below. 

I have two purposes posting it here:

1) Has anyone seen this diagram before?  I would like to give reference to the owner, but can not find him/her, and see if they have published anything else related here.  (and no, it is not in CISSP Exam Guide, 4th edition - I have a copy and I've already looked.. twice)

2) Let everyone else see this diagram, as I think it is very useful in understanding how virtual directories can be used to solve a lot of problems in the enterprise.  It is a great tool to use as a virtualization engine, and if you have cache involved (amazingly noted also in the diagram) then you have a very performant (yeah, i know its not "officially" an English word, but it should be!) and scalable solution. 

With this approach, you have all the things the "identity gang" has been arguing about - meta, virtual, synch, provisioning, performance, key mapping, etc.

VERY COOL!  So, who is the brilliant one out there?  Come forward and claim your honor due.  :)

Identity Infrastructure Discussion

Its been awhile since I posted, so here is something I've been wanting to blather about for a couple weeks.  Perhaps when I have more time I can come back and give more specific examples in this conversation where these guys (the "identity gang" or perhaps "the identity thugs" lol) unknowingly are arguing the same point.  Listen to this discussion (link below) and see if you too can pick up on it also.  It is a matter of terminology and perspective. 

This discussion, at least appears to be, an impromptu group conversation on identity bus at the European Identity Conference. Click on the link and go to the Kuppingercole blog and check out the video clip series.

http://blogs.kuppingercole.com/gaehtgens/2008/05/06/identity-bus-round-table-video-online/

What struck me was the differences in terminology. If you listen carefully, you may also notice that often they are talking about the same thing, just from a different perspective. (remember the story about the blind men asked to describe an elephant, having never seen one).  OF COURSE the solutions will be based on a different patterns!  (e.g. loosely coupled vs tightly coupled if they are external or internal to a specific security domain). These guys know this and I'm sure they would agree, but the conversation gets tricky to follow when they switch back and forth.

SO, what is all the fuss around the identity bus? It would give us a way to at least "plug-in" all our related services, so we can transport information in a uniform manner.  You add transformers / connectors (I've given you one of those 'different description for the same thing for free) to plug into the bus and then begin to define how we can interact with the other systems.  THIS IS HUGE.

Increasingly we need to interact with external resources (e.g. remove services, partnerships, federations, etc) and the solutions will look different than what we need to solve identity interoperability inside the enterprise (where we have relatively tight control). 

One thing is clear.  These topics are not an easy ones.  First we need a way to discuss the topic using accurate and consistent terms (at least better than we do now).  We need to build upon ideas and find solutions, without a common communication model, this will never happen.  This goes far beyond just the "bus", we need to define the components and this will help define the conversation.

It is a heterogeneous jungle out there. There is a new project, initiative, concept, etc everyday it seems.... we need to learn and build on concepts.... and move forward. 

(Yes, this was quick and dirty, sorry if I lost anyone, as always contact me if you want more clarification on anything, and thank you for reading my post!)

LDAP Directory Proliferation

Matt Flynn posted "Proliferation of Multiple LDAPs" today.  Matt's post was fueled by the recent meta vs virtual debate, which is a nice segway to talking about how to deal with the increasing number of identity stores within the enterprise. 

He suggests examining your current environment, paying attention to these factors:

• Which data stores have overlapping data and which are unique?
• Does it make sense to consolidate?
• Is the data mappable across systems? Do they share unique identifiers?
• Where can multiple applications share a single store?
• Where do given applications require access to data in multiple stores?
• What applications or uses are coming in the future?
• Which stores are used for critical apps? What is the up time demand?
• In what format is the data stored?

His article focuses on directories, increasingly common to read referred to as "LDAP stores". Certainly, identity stores revolve around these hierarcal databases, why?  Because of the reliability, performance, and implicit context provided which is a perfect match for security and IAM solutions.

Just some food for thought.  What if you have an application that could make valuable use of information stored in a relational database, a web service, or specialized application?  What now? These types of data stores are proliferating at a higher rate in the enterprise than LDAP directories for sure.   You could...

1. ignore the possibility of using the data and recreate it (ostrich approach)
2. replicate the data into an LDAP store (creating potentially complex synchronization requirements and introducing data that is at some level, out of date with the authoritative source)
3. use the non-ldap source directly (which will probably not be as secure, have the availability, or provide an overall solution for most IAM packages)
4. use an LDAP proxy to access the information (which will still have the performance problems since a proxy can not perform faster than the underlying data source)

What to do??? By the time you got to my 4th point, you probably were ready to take option #1, admit it... 

Metadirectories are just too expensive, take too long to deploy, difficult to adapt to new sources and/or new synchronization requirements, and the list goes on. People use metadirectories as the "end-all, ubber directory", only to realize the multitude of new requirements not addressed within a year of deployment.  Most virtual directories are too light-weight, offering little more than an LDAP proxy solution. 

Here is my short list of what a solution needs to offer, regardless of your environment.  You needs will change, so your solution should be adaptive and offer more options than you will use today...

• flexible data representation: able to compose identity objects on proxy or data model views from disparate sources (such as data virtualization platforms offer)
• performant: yes, I know its not "really" an English word, BUT IT SHOULD BE, we need this word :)  you need to have the reliabilities, availability and overall performance that LDAP compliant directories offer
• caching options: this includes cache refresh options (i.e. event-driven, TTL, local/distributed, etc)
• synchronization: at the object and even the attribute level, keep it light-weight, and the option of real-time updates OR not - the choice is the key
• identity mapping: identities need to be correlated across the data stores, regardless of the data store type and maintained automatically (it is important to have the ability to subsume new sources quickly and effeciently)

 

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

 

Are Meta-Directories Dead?

My favorite old ranter Dave Kearns (self proclaimed as the old man ranting in the corner) has an article for NetworkWorld, raising the question if meta-directories have any life left in the market.

Although I don't know if meta-directories are dead, they seem to still have a place in the world, I do see an end to this technology in favor or other technologies in the future. The Higgins project is offering a new approach to identity control and management.  Virtual Directories offer a solution, you can check out OVD and RadiantOne who both offer meta-directory type functionality.  (Although Oracle is not explicit how this use case is deployed using OVD since it requires the purchase of additional products, who knows if Oracle has actually tried this or not - you just buy buy buy (story as usual with Oracle right?) until you get the functionality, I have not tried this deployment use case with Oracle personally, I know that RadiantOne offers this functionality out-of-the-box. )

Jackson Shaw (an excellent source of high-quality information regarding in the IdM space) is the source of Kearn's rant, in his more recent posting Jackson again refers to meta-directories as "dead". Shaw also links to Neil McDonald's presentation at the Gartner's IDAM Summit "Everything You Know About Identity Management Is Wrong". 

What is sure is that things are definitely pointing to a big change in how Identity Management projects are deployed.  The time seems right for a major move towards a more manageable, higher level of fulfillment of the promises of IdM applications, and less complexity. 

Noel Yuhanna, principal analyst with Forrester, has some great ideas where this market is going, pay extra attention to "Information Fabric" and "Information as a Service" papers.  It is worth the read if you are planning for the long-term.  I have learned a lot from his materials. 

Another Virtual Directory to Market

Yes, I am a little behind in my postings.  Don't rant against me too much, I have a full-time job ya know!  :)  

I need to add my small voice to the cheers of yet another virtual directory added to the market. Optimal IdM has released their first version of their Virtual Identity Server (VIS). 

The announcement was during last weeks' Directory Experts Conference in Chicago (mainly a Microsoft AD pow-wow, but definitely worth the time).  Although I was not able to attend personally, some of my co-workers did and they felt the event was worth the time.  I do have to note, it is has always been amazing to me how segregated Microsoft centric vs. non-microsoft centric IT shops are.  There were a lot of new people to meet instead of the usual groups that attend the other usual conferences that deal with Identity Management (like Burton's Catalyst, Gartner's IdM Conf, Digital ID World, etc). 

but I digress. .. back to VIS --- 

This newest virtual directory is based on .NET and totally Microsoft AD/ADAM centric.  Focusing mainly on the AD Forest problem (where enabling trust is not an option), the product offers a basic LDAP proxy solution for aggregating (although they call it "union", it appears to really offer aggregation, since I can not find the ability to merge same accounts from different directories into one profile, it requires unique members and identifiers in all connected sources).  They also offer a join, but since their use of "join" and "union" are a bit loose, it is hard to tell the level of sophistication and features they bring to the table.

The bottom line is its great to see another Virtual Directory on the market.  Here is how VIS fits in the overall VDS market...

Virtual Identity Server does:

• LDAP Proxy
• Merge and Join directories only
• Designed for Active Directory / ADAM integration issues; forests, multiple domain controllers, etc
• Merge of groups from multiple LDAP sources

Virtual Identity Server does NOT have:

• fully LDAP compliancy local store (if a local store is needed, an instance of ADAM is used)
• integration capabilities for databases, applications, or web services (at least outside Microsoft, and if it does offer it, it is not explained, although their solution would probably be to use ADAM between such services, which would add more points of failure and complexity, and undoubtedly performance and scalability issues).
• ability to offer true union of data stores (where matching profiles can be mapped into a single view, they only merge and join) (if you need further technical explanation of this, esp for LDAP folks, let me know - I'm using mathematical definitions of these terms, more common in the database world).
• meta-directory functionality and/or synchronization capabilities (again they would rely on ADAM, IIS, ILM, which brings nothing new)
• data model (e.g. for creating new hierarchies / DIT structures)
• cache (neither memory or persistent)

I am sure the product will evolve, and even though the initial offering is limited, they are offering a solution to a very significant problem, addressing compliancy issues and overcoming serious limitations of AD/ADAM. If you are a Microsoft shop, and don't anticipate the need to integrate from other branded products, then VIS is your choice.  If you have heterogeneous data sources (i.e. oracle, sun, novell) this is not your solution, you need to look at a product like Symlab's Virtual Directory (based on C++) for a more robust LDAP proxy or basic virtual directory for low to moderate volume, or the king of the virtual directories Radiant Logic's RadiantOne Virtual Identity and Context Platform, which offers more features and solutions than any other product I have found in its class by far.  RadiantOne also offers longer "legs" as it offers more features to scale to almost any level.

 

 

 

WebDAV Vulnerability Worst of Four Windows Flaws « Bardissi Enterprises Blog

As a lot of us know, there are some serious DOS (denial of service) issues with AD.  AD just isn't fully LDAP compatible, that's the bottom line in my book.  If I have to interface to AD to multiple sources outside Microsoft designed use (inside the NOS), I recommend using a virtual directory to protect AD. Such LDAP packets as described below and other causes of DOS can be dealt with. 

Quoted from http://bardissi.wordpress.com/2008/02/12/webdav-vulnerability-worst-of-four-windows-flaws/:

WebDAV Vulnerability Worst of Four Windows Flaws « Bardissi Enterprises Blog

12 February, 2008

 

MS08-003: Active Directory Denial of Service Vulnerability

Active Directory is the Windows component that provides central authentication and authorization services for Windows computers. Active Directory runs on Windows servers, but also on Windows clients as the Active Directory Application Mode (ADAM) service. Microsoft’s security bulletin warns of an unspecified Denial of Service (DoS) vulnerability involving the way Active Directory handles specially crafted LDAP packets. By sending a malicious LDAP request, a remote attacker could exploit this vulnerability to cause your Windows computer to lock up or to reboot. The attacker could repeatedly exploit this vulnerability to keep your Windows machines offline for as long as he could sustain this attack. However, most administrators don’t allow LDAP traffic (TCP ports 389 and 3268) through their perimeter firewall. Therefore, this vulnerability primarily poses an internal threat.
Microsoft rating: Important.

 

Oracle Virtual Directory Webinar

I thought I would share an interesting webinar on virtual directories recently from Oracle on their virtual directory (OVD).

You can view the recording here.

This is the first time I've mentioned a product by name, and referenced a particular company. I try to stay as neutral as possible, perhaps out of habit due to my role to help customers decide. I usually always give at least two options for any decision and list the pro's and con's.

This webinar is a little generic, although I was able to get in a couple questions which the moderator answered decently. OVD certainly has a place in the marketplace and a specific role.

If you want an introduction at a high-level for what a virtual directory can do for you, this is a great resource so check it out.

What OVD doesn't do is offer solutions to more complex integration problems that you can face that require more feature sets, which Oracle will gladly provide to you, of course, at an additional price, as part of their IdM Suite, such as synchronization capabilities, data modeling, provisioning services, and more...

Problems extending Active Directory Schema

Jackson Shaw blogs about still MORE issues that are arising from trying to update schemas in active directory. This is why I encourage people NOT TO TRY THIS AT HOME (or at work). It's disruptive and can have some serious effects on your network infrastructure. Use the existing schema in a virtual directory, extend the schema there. Then you don't have to worry about the issues involved here. Point the applications that need this schema extension to the virtual directory instead of AD. Most virtual directories will let you mount an existing structure (proxy) and extend the entries from various data sources (including data bases, other directories, applications or web services). Some virtual directories will even allow a join function to extend the entry from its own local store if the needed schema attributes do not currently exist. Kind of neat huh? So why all the drama? I think people just don't understand this technology - you can use your existing stores and pretty much do anything you want with them, without replication. Performance you say? Well, if it really becomes a problem, there are several caching options and cache refresh options in virtual directories also. If you don't have a virtual directory (or one that has these options) in your arsenal, get one - it will save you a lot of headaches, and a lot of time. Become the famed Engineer Mr Scott of Star Trek fame and get everything done in one third the time or less!

read more | digg story

Matt Flynn Blog, Burton Group, affirm Virtual Directories as a Valuable IdM infrastructure component

Matt (see http://360tek.blogspot.com/2008/01/year-of-virtual-directory.html) asserts his continued position as an advocate of using virtual directories- and references Burton Group's affirmation of this technology as well in a recent webinar. Burton also published a paper recently (Nov'07) "Virtual Directories: Valuable Present, Promising Future" that is great information on the state of the vendors in this market and their capabilities. Not all of them have all the flexibility that Matt refers to "That is, virtualizing the data structure, access protocols, server locations, etc. and presenting the same useful data from its original source in real time (or cached) in virtually any format and over most common data interfaces." The Burton Group study will help a lot in sorting that out.http://identityinfrastructure.blogspot.com/

read more | digg story

Weakness in IdM Products

http://duckdown.blogspot.com/2008/01/common-weakness-in-all-identity.htmlThis author takes a harsh, but not well versed stand, into criticizing ALL IdM software packages out there for the lack of integration into various data stores, especially Active Directory. If it were that simple, don't you think all the vendors would do it? Just the fact that the symptom is there for ALL IdM packages, should tell you there is MORE to the story, no??? First check out Gavin's response, a good one - and saved me from more ranting on here... http://blog.suretecsystems.com/archives/77-A-Common-Weakness-in-all-Identity-Management-Products,-but-not-OpenLDAP.html First - Active Directory is for INTERNAL users primarily. Not useful for all IdM initiatives, say for a partner portal, or federated business environment where the user list is NOT your network users. Second - If you know much about Active Directory you will know 1st AD admins don't want you messing with it, you can cause serious problems if you do - extending schemas, customer object classes, etc pose problems, plus its SLOW - HENCE why ADAM exists in the first place, but then why isn't everyone clamouring over the use of ADAM? Like Gavin Henry says... I encourage this author to take a look at the white paper Open LDAP wrote (http://symas.com/documents/Adam-Eval1-0.pdf) and you will start to see the limitations and disjointed nature of LDAP compliant directory services and AD.

read more | digg story

Completeness of Metadata

http://www.b-eye-network.com/view/6722 This is just kind of interesting, nothing great... BUT the issue of how you do handle large amounts of metadata does ring true. The author states that perhaps you must limit your metadata and not try to get a complete picture. Of course you do! You must limit it to the context in which it is relevant! This is why I think the hierarchal views found in directories are great, they can give you direct context of data, natively (i.e. look at the DN of a user object) - if you build these trees correctly you have some great information to leverage. Let's take it one step further, look at a virtual directory - where you can change the labels and tags as you want, giving the DN a more explicit meaning.If your confused, don't feel bad, I've confused many on this topic - but if you can get your head around it, it will pay off!!

read more | digg story

Five Steps to Better Data Management

In this article Michael Daconta spells out in his vision what steps need to be taken to ensure successful future growth of your enterprise architecture. http://www.gcn.com/print/27_2/45685-1.htmlPay attention to step#4. Install a data services layer in your service-oriented architecture plumbing. This isn't just an SOA thing, don't wait for SOA come to you, create a data service layer now. You will be one step closer to SOA (if planned well, so go ahead and ask the vendors you talk to, what the plan is for SOA integration in future releases) and one step closer to unbelievable flexibility and an almost end to this constant reinventing the wheel for each application you bring online.

read more | digg story

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

MDM without boiling the ocean

The concepts are the same for Identity Management, you don't have to solve every problem in the world to get started solving your integration problems... BUT you can make some savvy choices, like planning ahead and going with solutions that have "legs". If you have read my blog entries you know I love the data-virtualization concept and benefits. The author of this article (http://www.it-director.com/blogs/Fern_Halper/2007/12/MDM_without_boiling_the_ocean.html) is starting to see some of the benefits of the data-virtualization idea, its too bad there isn't any examples given or benefits achieved. Identity Management can be as daunting as MDM (master data management), and in many ways more critical. My recent run-in with Blue-Cross of California shows my point, they have decided to integrate their multiple systems (e.g. star, gemcorp, etc) into a web service so that members can access information and services at a single point - sounds simple enough right? on the contrary, its not working and they are puzzled as to why... members who are in multiple systems, perhaps inactive in one data silo and active in another for example, can not access the website or retrieve registration information. As of my last contact with that group, they have no ETA on when they will solve this problem, nor have they isolated where the problem lies... amazing... It is obvious to me that it lies in the choice of data integration tools, it looks like Blue Cross will be relying on their old systems, and a lot more member calls (btw their tech support is reporting a minimum wait time of 25 minutes as of yesterday), and upset customers for awhile longer.... Create an abstraction layer that can grow with you. Solve one piece of the puzzle at a time, when you have a piece in place, implement it without disrupting other current systems.... this one of the largest benefits I am finding in using data-virtualization tools like virtual directories, I don't have to use it for everything at once (I can implement authentication via ldap proxy using a virtual directory server, and later add services such as provisioning or user management), and it operates into my current environment natively as I need it to (i.e. ldap, or sql, or xml/web services, etc) not some new custom protocol. How do you eat an elephant? one bite at a time! Break your project into small pieces, with your eye on creating tools for the future, you just might be able to boil the ocean yet...

read more | digg story