Virtual Directory as Database Security

I've written plenty of posts about the various use-cases for virtual directory technology over the years. But, I came across another today that I thought was pretty interesting.

Think about enterprise security from the viewpoint of the CISO. There are numerous layers of overlapping security technologies that work together to reduce risk to a point that's comfortable. Network security, endpoint security, identity management, encryption, DLP, SIEM, etc. But even when these solutions are implemented according to plan, I still see two common gaps that need to be taken more seriously.

One is control over unstructured data (file systems, SharePoint, etc.). The other is back door access to application databases. There is a ton of sensitive information exposed through those two avenues that aren't protected by the likes of SIEM solutions or IAM suites. Even DLP solutions tend to focus on perimeter defense rather than who has access. STEALTHbits has solutions to fill the gaps for unstructured data and for Microsoft SQL Server so I spend a fair amount of time talking to CISOs and their teams about these issues.

While reading through some IAM industry materials today, I found an interesting write-up on how Oracle is using its virtual directory technology to solve the problem for Oracle database customers. Oracle's IAM suite leverages Oracle Virtual Directory (OVD) as an integration point with an Oracle database feature called Enterprise User Security (EUS). EUS enables database access management through an enterprise LDAP directory (as opposed to managing a spaghetti mapping of users to database accounts and the associated permissions.)

By placing OVD in front of EUS, you get instant LDAP-style management (and IAM integration) without a long, complicated migration process. Pretty compelling use-case. If you can't control direct database permissions, your application-side access controls seem less important. Essentially, you've locked the front door but left the back window wide open. Something to think about.

TEC 2010: Optimal IdM

The third and final TEC 2010 vendor to participate in a video message is OptimalIdM who was at the conference demonstrating their Virtual Directory solution and its ability to simplify deployment of Sharepoint 2010.

Querying AD from SQL Server

This is a great how-to article on querying Active Directory from within SQL Server. I've written in the past about using Virtual Directory technology to query SQL data via LDAP. This is the reverse and I can envision many use-cases where this would be useful. This isn't exactly new technology, but it's a new write-up on how it's done and very easy to follow.

For example, you could use this approach to extend the information available to an application without doing any data synchronization or introducing new data sources. If the application's logon ID is the user's email address, you could query AD based on that email and get info about the user's group memberships, attributes, manager, location, etc. and have that returned to the application as if the data were stored in the local app's database.

...another useful approach to keep in your development toolbox.

Provisioning to the Cloud

I posted recently about identity in the cloud. Many identity vendors are doing interesting things to get their solutions 'in the cloud' or available 'as a service'. It's a lot of buzz, but there's also some actual cost savings and operational efficiencies at the bottom of these efforts.

Today, Optimal IdM announced their cloud provisioning solution. Similar to what Identropy is doing with IC2, Optimal IdM's solution leverages existing provisioning solutions and acts as a connector to cloud applications.

This use case of acting as a connector for remote, unknown, complex, or varied systems is a perfect fit for virtual directory technology. MaXware released a similar connector for Salesforce in 2006 while I was still an employee. Perhaps they were ahead of their time? The virtual directory solution can be added to virtually (no pun intended) any environment and provide immediate connections up to numerous, complex cloud systems, thus saving cost and effort as compared to developing custom connectors.

Having said all those nice things about the virtual directory approach and once again encouraging IAM integrators to consider virtual directory solutions while whiteboarding on how to meet requirements, I should be fair and point out an alternate viewpoint. If you already have a provisioning solution from the likes of Courion, Novell, Oracle or IBM, and a requirement to provision to cloud applications, you owe it to yourself to take a close look at Identropy's IC2 offering before making any purchase decisions. That's exactly what it's designed to do.

Another interesting note - I spoke to someone from Arcot today (think secure token-less authentication) who informed me that all of their solutions for secure authentication are now available as a service. They already have one of the most widely deployed authentication-as-a-service solutions on the market, so it seems to be a natural migration to offer their other solutions from the cloud as well.

Who recently said there was no more innovation in the IAM space? The latest innovation in this space is in direct response to the market complaints that IAM is too complex. Once simplicity is realized, innovation will no doubt trend elsewhere. I call that a success in meeting customer demand.

Weighing in on Persistent Cache

Ash, my experience says that Mark is correct. I believe the top vendors can all brag about similar throughput. But, my understanding is that's only what the VD puts on top of the process. There's still the back end data lookups, etc. To Mark's later point, that may not be a big deal either if those sources perform well.

Let's use a telecom example:

In a scenario where the VD serves an attribute that is a composite of multiple attributes from various sources (a mixed ODBC and LDAP call) or across numerous sources (customer databases from companies that merged or partner) and the attribute is needed to make a decision (does the subscriber get this feature) in real-time (the time between hitting "send" and hearing a ring) for millions of requests each second, effective use of cache can help – even though throughput is already relatively quick. In many (perhaps most) enterprise identity infrastructure uses, cache may not be of enormous value – or at least it's not the most compelling reason to use a Virtual Directory.

I can tell you that customers ask for it whether they need it or not. Probably because they have performance or availability concerns. But, from what I've seen the performance concerns are usually unfounded (unless the back end systems have serious problems). And VD cache isn't a great way to provide redundancy because it's implemented at an attribute level and cached based on use. If the idea is to put the entire data set somewhere else, you could argue that it'd be better to just have another directory instance there and do real-time synch (replication).

My opinion is that it's a nice feature to have in the tool bag when needed, but it's not always needed.

Litmus Test for Metadirectory vs. Virtual Directory

No, I don't want to re-open a debate. Just floating someone else's idea...

I already mentioned some of the things I overheard at DIDW 2008 and the panel titled Lessons From Successful Virtual Directory Deployments. I was looking at my notes today and wanted to float an idea that one of the panelists offered (I think it was Divya Sundaram of Motorola). He said (paraphrased):

If you front-end data (or a data store) that you don't own (or don't have control of), then you need to replicate/sync data (instead of virtualizing the view).

Is that a good general litmus test for the Metadirectory vs. Virtual Directory debate?

As I've said numerous times, I can think of clear use-cases for both scenarios. But this might be a good general rule of thumb. BTW - the panel seemed to unanymously agree that both capabilties are useful and should be part of the toolbox.

DIDW 2008

I saw, heard, and did a lot of interesting things this week at DIDW in Anaheim.

First, thank you Ping Identity for a good mid-week party at the HoB. (We should all publicly thank Ping and give them reason to continue hosting such events.)

We had a bloggers meet-up, though you won't hear too many others talk about that (maybe Ash). I did get to meet a number of folks who I've only previously met online. And I had many good conversations.

I heard more about the consulting (and other) capabilities of companies like Identropy, CoreBlox, and Optimal IdM – all worth a conversation if you need some Identity consulting help. And each has unique strengths. I wonder if you would all benefit from some kind of cooperative network rather than having the perception of competition. I'll have to think about that.

We gave away a lot of sticky eye balls. One became known as the eye in the sky.

I learned about important things like:

• The Identity Assurance Framework
• Marty's Identity Model
  (with which more of us should be helping)

And heard a lot of interesting discussions and tidbits, including:

• The US Treasury Dept transfers more than $1 Billion each day via PKI
• There seems to be consensus that enterprises will be affected by market forces on consumer identity and Web 2.0. ...perhaps TPS reports will be replaced by Twitter.
• Searching on "Identity Management" has declined throughout 2006, 2007, and 2008. My own research reveals that searching on "Microsoft", "Oracle" and "Active Directory" have all declined at a similar rate. So, it may mean nothing.
• One interesting case for synchronization vs. virtualization: If you front-end data that you don't own (and therefore can't control), you should replicate data and sync rather than using a totally virtual approach. It sounded like someone learned that the hard way.
• Not all Virtual Directories are created equal. I heard a panelist ask vendors for a feature that I know exists in at least two Virtual Directory products.
• Virtual Directories might be able to fill a gap in the real-time link between physical and logical security (grant access only when employee is swiped in).

On the flight back, a crazy thing happened. I heard a horrible scream outside the window of the airplane and when I looked outside, I saw something that seemed to be flying past us at a close distance. I quickly grabbed my camera and got a shot of it. (OK - you probably had to be at DIDW to appreciate that.) If you weren't, use this short waste of your time as inspiration to go check out Symplified and see what they're doing with SaaS-based Web Access Management. Pretty cool stuff. Their model removes a lot of the pain that gave Identity Management a bad name in its early days. And no, that's not Che.

I guess that's it for my DIDW update. For now.

Ouch

Dave Kearns calls my argument smoke and mirrors and labels it FUD. His argument is that the Global 2000 have more users and are therefore more important? Should their needs drive solutions for the mid-market?

Dave, I don't think the number of users is even relevant. What is relevant is the experience of those customer organizations and how they can meet their requirements. The number of infrastructures is more relevant than the number of end users in this discussion. I don't think a huge amount of them have a need or desire for multiple user directories. They seem to run off of AD and seem to prefer to have apps leverage AD instead of figuring out how to use a virtual directory (or metadirectory for that matter). Where is the FUD in that? Where is the smoke? What would be my motive to raise smoke and mirrors?

The discussion of how should Oracle build a product is very different than whether customers should consider metadirectory as an alternative. I think they should. I think there are still plenty of environments that could benefit from that approach. But I conceded Clayton's point -- if Oracle wants to build a virtual directory into it's suite to enable flexibility for customers, that's great. I just don't think a virtual directory is the answer to everything (and I spent a lot of time discussing the various use-cases that cry for one).

I would just hate to have people shy away from a good technology because some people say it's no good anymore. That doesn't make sense.

Ultimately, we might agree. Dave's conclusion is one that I've echoed over and over:

The need for, and uses of, virtual directories is growing and is still a few years away from peaking.

Let's just not declare something dead because it no longer seems cool to the in-crowd. It's OK to take a pragmatic approach to whatever challenge your organization is facing. That's my point.

Metadirectories: What's left to say?

If you haven't been following the flurry of conversation since my post last week stating that metadirectories aren't dead, well you're in luck. We couldn't have asked for a better recap of the conversation than the one provided by Ian Yip (although I think he gave Nishant a bum rap on this one).

There were so many different angles explored that I'm not really sure where to start or what's left for me to say.

• I'll restate that I see perfect use-cases for both metadirectory and virtual directory. Now and in the near future. In the far future, there will probably be better ways to achieve the same goals.


• Also, it sounded like Clayton took my comments to mean that "everyone needs to be using Active Directory for everything", which was (I think obviously) not the intent. My point is that although the top 500 or 1000 companies may have a number of directories for various strategic uses, there are probably 20x that number of companies that use only Active Directory as the central and primary user store because of it's network and email integration. And those companies might like for their application vendors to offer direct plug-in to AD as an option.
  
  Plugin to LDAP might be another good option and virtual directory technology would be a great enabler to incorporate various vendors, schemas and even relational databases through that single mechanism. But those mid-market companies probably would prefer not to take on the complexity of virtual directory (even if relatively simpler than writing numerous connections) if they could just use AD natively. And I think some percentage of the Fortune 1000 would see AD as strategic enough to ask the same as well.
  
  That's my guess based on a customer perspective as opposed to a software vendor's ideal state of architecture. And I don't think this is limited to companies who are 100% Microsoft shops. AD just has a very far reach and because it holds email in most of those companies it will already have an account for every employee, be available, etc..
  
  I don't think any of this should be seen as threatening to the role that stand-alone directories or meta- or virtual- directories play. The difference in viewpoint between me and Nishant & Clayton (if I can group them together) might be in the types of customers we've been talking to. There are still a ton of companies out there that aren't super-strategic about their Identity Management architecture. Or that just want a point solution because it fits the current business needs.

I think that's it. For now.

[UPDATE] - forgot one:

• Bavo, I wasn't requiring that the HR database is the primary source for account creation and status. I also wasn't telling you that the HR database should be the primary source for Identity information. (However, I think it's more true than you think.) I was stating a requirement (one that I've seen many times). HR has been deemed THE authoritative source for employee existence in a majority of the companies I've worked with. My experience seems to differ from yours. [That's at least interesting! ...and one of the reasons I blog – to engage with people that have different experiences.]
  
  Yes, companies struggle with getting HR updated for the employee's start date. But, I've actually seen more than one customer implement a complicated AD-to-HR-back-to-AD process to accommodate for the issue. One customer integrated the candidate review system into the provisioning system. I think the reason for HR being authoritative is usually for deprovisioning. They want a disabled HR account to ripple downward.
  
  I think what you call the IDM system assumes a provisioning solution with work flow and its own internal store. These are luxuries that are not always available. In my scenario, the cost and complexity of a provisioning solution is probably overkill based on the requirements. And that's my point. There are scenarios where the simplicity of a metadirectory are not only sufficient to meet the requirement but actually a bit more of an elegant way to meet the requirements.

OK, now I'm really done for the night.

Metadirectories Aren't Dead (They're Just Aging)

Nishant Kaushik updated his blog and one of his old posts showed up on PlanetIdentity reminding me of the recent discussions on metadirectories and virtual directories between him and others (Dave, Jackson, Kim).

Not that I want to pick a fight with any of these guys, but for anyone who thinks the metadirectory is dead, I have a simple (albeit a bit late) scenario for you.

There are three identity stores:

• An HR app built on a black-boxed Oracle DB
• A custom-built line of business app built on MySQL
• Active Directory

Requirements:

• The HR system needs to be authoritative for account creation and status.
• Active Directory needs to feed email address to the other apps upon creation (and occasional changes).
• Systems should be updated within 4 hours.

That's it. What do you think? Is a virtual directory the best solution to meet these needs?

I love virtual directory technology as much as the next guy (Hi Mark), but claiming that any technology is superior to another without a discussion of the specific requirements being met just doesn't seem to make sense. Companies, departments, and projects within departments have different needs.

I've said it before. They're just tools. So, when James McGovern asks what the role of virtual directory should be, I don't have an answer. There is no should in this discussion. Ian Yip had a similar pragmatic answer. And Nishant echoed with "the mantra should always be to choose the right tool that solves your problems". Exactly.

If the idea is simply to talk about what the future should look like, I think James hit on something. There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. And it's probably what Jackson was alluding to (Quest enables *nix systems to leverage AD).

Another possibility is that apps will support SOA-based authentication and authorization, though that hasn't quite spread like wild fire quite yet.

Don't get me wrong – I don't think the need for virtual directory technologies will go away anytime soon, but I wouldn't be surprised if it never becomes a standard in the mid-market. And I don't think it'll ever completely replace metadirectory technologies.

Metadirectory may be aging, but hey, 50 is the new 30. It's not dead yet.

Proliferation of Multiple LDAPs

I was questioned today by someone who read my post on Synchronization versus Virtualization, which is topical given the recent blog debates by many of the big names in identity blogging on whether metadirectories are dead. Back then, I was trying to convince the world that there are cases that require a virtual approach. Now, the tables seem to have turned. I've stayed quiet on that debate, but I believe there's still a place for each method. Honestly, I'm not sure why there's such intensity behind that debate – they're just tools. My idea for Enterprise Identity Services Architecture included a layer for Identity Data Services, which is analogous to the proposed Identity Hub or Bus. It has a box for both synchronization and virtualization because there are use cases for both types of technologies often within the same infrastructure.

End of digression.

The question proposed was about how large enterprises (hundreds of thousands of users) are addressing the proliferation of LDAP directories in their environments. The person asking comes from a well-known and reputable company. The first thing I thought is here's the exact reason why we still need metadirectories. Many companies still haven't dealt with the user-store sprawl. In a general sense, I think metadirectory technologies can help get you to a place where you refine and consolidate your infrastructure and can then leverage virtual directory technologies where appropriate for applications that need access to data in multiple stores and/or multiple formats.

What the questioner was really looking for is research that discusses how other companies have handled the challenge. Here's my answer:

My recommendation is to find an experienced group of consultants who have tried various approaches with different clients. There are a number of them out there and I'm happy to give recommendations privately based on geography, technology, comfort-level with small vs. large companies, etc.. Whether you engage them contractually or enter into discussions via user groups, trade shows, etc., real world experience is priceless. Anybody that pushes one particular approach to this problem is probably biased (either by product or by their own limited experience). My experience suggests that most scenarios require a unique approach based on business goals, actual technologies, future plans, etc.. But you probably need someone to spend some time understanding your own scenario before recommending an approach.

Some questions you'll want to explore:

• 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?

The answers to these questions will drive your architectural decisions and help you prioritize next steps.

If you'd like to comment and provide a pointer to field research, whitepapers, or contact info for how you can help with this situation, feel free.

The Year of Virtual Directory?

I have blogged quite a bit on the value of Virtual Directory technology in directory services infrastructure. I was pleasantly surprised yesterday while attending a Burton group webinar titled VantagePoint 2008: The End of Command and Control is Near (you must be a client for access). The fifth and final agenda item was Trends for Directory Services in which the speaker focused almost entirely on the evolution toward (and value of) virtualization of identity information. 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. It's nothing new to long-time readers of this blog, but seeing it as the center of the Trends section in Burton's webinar probably means that customers are telling them that Virtual Directory is moving up the prioritization ladder. That's a good thing -- it means Virtual Directory vendors will be able to continue to invest in this very cool technology and implementation teams have a better chance of getting this very useful tool to leverage in their bag of tricks.

re: Synchronization versus Virtualization

In his entry on Novell’s Cool Blogs, Volker Scheuber discusses the use-cases for virtual directories versus metadirectories and asks for input. Considering my number of previous posts on this topic, I felt an obligation to respond.

I've done a significant amount of services work around both metadirectory and virtual directory technologies. My last company had both and my current company offers neither. The bottom line is that if I were designing an IdM solution, I would want both options to be available. As with any enterprise technology, there's usually more than one way to accomplish a given goal. Most IdM data integration requirements can be met with either meta or virtual technologies. However, there are some scenarios that, for all practical purposes, require one or the other. A while back, I posted some common scenarios where a virtual directory can be really useful.

Even for some of these scenarios though, you may be able to achieve a similar result by standing up another data store and setting up data sync rules with a metadirectory. But it often requires a significant amount of programming that would need to be maintained in addition to the new data store (LDAP or other) and related infrastructure.

Here’s an example:

Let’s say you were deploying a COTS application for insurance claim processing and security is important. The app uses an Oracle database for system data and is built to leverage an enterprise LDAP store (eDirectory, Active Directory, etc.) for authentication. Each employee that needs access to the system already has an account and credentials in the enterprise directory (ED). The system leverages the ED’s groups to grant or deny access. And of course the ED user needs to be enabled.

Due to the sensitive nature of the material, a requirement is made that the system should not allow access to the app unless the employee is punched-in to the company time-clock system. So, if an employee were to piggy back off of a manager’s home VPN connection, they could not access the system unless physically punched-in at work where all claim processing personnel are monitored. The time-clock system has a MySQL database with both system and user data. The APIs for the claim system and the time-clock system are both difficult to work with and complex to maintain.

What are the various ways to meet this requirement?

You could potentially try to work with the API’s and write a custom authentication module that would connect to the time-clock system and verify that a user is punched in before granting access. This would require some internal training, development time and will need to be maintained as either vendor releases new versions in the future.

You could implement a metadirectory solution that sets the ED user as disabled each time status changes in the time-clock system. This may require some custom code, but should be fairly easy to implement. However, we don’t want to disable users in the ED each time they’re punched out. They still need access to HR benefit info and other systems. Not to mention that disabling a user in the ED may trigger other unwanted events to occur (de-provisioning).

You could have the metadirectory solution switch to a different attribute instead of disabling the user, but you’re back to writing a custom authentication module. Also, these metadirectory options will likely introduce some latency because metadirectory sync jobs are typically scheduled. So, there may be some window of time between when the user punches out and when the system denies access. This time window can be exploited to circumvent the intended security controls.

Or – you could have the claims app connect to a virtual directory that is configured to join data from the ED and the MySQL database in a way that is transparent to the claims app. The app sees the virtual directory as an enterprise LDAP directory, but when the user is not punched in, the user appears to be disabled. This is generally a very simple thing to configure for a virtual directory. And if the claims app expects a single group to grant or deny access but the ED groups are arranged differently, the virtual directory can display group memberships however is most appropriate for the app.

Let’s further suppose that the business rules are changed to grant restricted access for the user when punched in but at an alternate location. The virtual directory can be easily configured to set a flag indicating restricted access based on the requestor’s IP address. This is not easily accomplished with a metadirectory solution.

And it’s a plus that the same virtual directory can be used to display user data differently for any number of systems that need access to it – and without altering or moving the data. As we move toward increased regulations and encrypting sensitive data where it lives, reducing the number of data stores that need to be managed and encrypted is an advantage in itself.

Having said all that, I can come up with a number of examples where a metadirectory is clearly a better option than a virtual directory, but I think those are generally easier to see.

Hope this is useful.

Dave Kearns on Virtual Directory

Dave Kearns' latest newsletter states: Virtual Directory finally gains recognition. He writes:

"Virtualization is hot and a virtual directory is the building block, or foundation, you should be looking at for your next identity management project"

So, it's not just me. Thanks for getting my back Dave ;)

Network Layer Identity Management: Part II

I recently posted an entry about Identity Management in the Network Layer. I wanted to follow-up with some ideas about how MaXware can help companies looking to achieve access management at the network layer.

Deploying access management requires an identity store containing user and access rights information. Solutions like the one from Trusted Network Technologies can use an internal store or leverage an existing store such as Active Directory. The process of designing and creating this store is obviously going to be a big task. Based on roles, policies and other security constructs, data will need to be structured, organized, cleansed, aggregated and integrated. For many organizations, a single Active Directory will not hold the entire universe of network users. There are non-employee business associates, partners, customers, disconnected business units, recently acquired companies, etc..

MaXware Virtual Directory (MVD) can serve as an abstraction layer for this identity and authorization data. MVD can provide the access control software with a single place to look for identity and permission data. MVD can present the data as an LDAP hierarchy or in any other preferred format. Identity and access data can continue to live and be managed in its proper location regardless of format. And if you'd prefer to leverage or build an LDAP directory to hold the identity and authorization data, you may need to synchronize data into that store on regular intervals. MaXware Data Synchronization Engine (DSE) provides a robust and easy-to-implement solution for synchronizing data to and from virtually any type of repository.

MaXware News

The whitepaper I mentioned previously, Identity Management in a Service Oriented Architecture (SOA) is now available on the MaXware website.

Also, MaXware is offering a lite version of its Data Synchronization Engine free of charge through July 31, 2006. DSE Lite is a great way for organizations to build real value while getting familiar with MaXware products. It provides a flexible data synchronization solution for bi-directional sync between any two data repositories. There is also a comparison between DSE Lite and the full version of DSE.

Lastly, MaXware just released a new version of the MaXware Virtual Directory with many upgrades, including built-in connectors for SAP and Salesforce.com. These connectors enable querying and account provisioning to/from these systems over standard protocols (LDAP, SPML, DSML, etc.). Kudos to the MVD development team for a very nice release!

Common Virtual Directory Scenarios

The discussion regarding possible uses for Virtual Directory is on-going. The following are 8 easy-to-understand scenarios for Virtual Directory in no particular order. This is by no means an exhaustive list, but I think it covers the simplest scenarios. I look forward to questions or comments.

1. Protocol Translation - Provide access to relational and other non-standardized data over standard LDAP and Web Services protocols without altering the data.


2. Web Service Enablement - Respond to identity data requests made via DSML, SPML or any other service-oriented data format (standards-based or custom).


3. Multi-Repository Search - Enable a single search over standard protocols to return a single clean result-set containing identity data that resides in multiple repositories in multiple formats.


4. Joined Identity View - Enable a search that returns a view of single identities that are comprised of data from multiple repositories. e.g.) A single user record is presented with name and phone number from the HR system and the email address from Active Directory.


5. Permission-Based Results - Enable a customized view into a single data universe based on which application or which user is performing the search. e.g.) Employees inside the corporate firewall see a full view of fellow employees while customers accessing an external-facing application see a reduced set of attributes and phone number is formatted using the (toll-free + extension) format.


6. Dynamic DIT - Build an on-the-fly Directory Information Tree based on identity data attributes. e.g.) The application calls for LDAP views based on job title so the virtual directory dynamically presents an OU for each job title in the database and presents employees within the appropriate OU based on their job title.


7. Authentication - Enable pass-through authentication from a single point of entry into multiple identity data stores. e.g.) Authentication requests are directed to a single point. The Virtual Directory authenticates non-employees against a back-end Sun Directory and employees against Active Directory.


8. Real-Time Data Access - Provide real-time access into back-end systems. Because requests are passed to the originating data source, the search results can be as real-time as required.

Summary

Virtual Directory technologies eliminate boundaries. Hassles related to LDAP object types, attribute definitions and other schema-related issues are eliminated by virtualizing the view into the backend identity stores. You're no longer limited by the existing data format or database branding. There's no requirement to migrate the data from a relational database into an LDAP directory in order to make the data LDAP- or Web Service- accessible.

One more post on Virtual vs. Meta

So, I already wrote that the question of Virtual vs. Meta is not the right question - they are complimentary solutions. One more thought on identifying where each would fit.

Every organization embarking on an IdM journey needs to begin by identifying data stores and collecting, cleansing, transforming & reconciling data. At this stage, traditional synch tools (metadirectory) are probably the right tool for the job.

If you already have a reasonably good set of data and are looking to provide additional or customized views into that data (via LDAP, SOAP, etc.), then Virtual Directory is probably the answer.

Of course, this is a very generalized view, but I think a good starting point. One of the things that make this question confusing is the functional overlap between the two solutions -- and there is plenty. But the point is to find the best fit solution for a given set of business challenges.

Internal users, AD password synch and Virtual Directory

At MaXware, we have a product that hooks into Active Directory to capture password changes. Once the change is captured, we can synch passwords downstream to connected data stores (directory, SQL DB, etc.). Like other implementations of this type of solution, ours requires having a component installed on each AD DC to identify and pick up the password changes. Although it's not generally preferable to install software on Domain Controllers, it serves a specific purpose in this case and AD administrators have been known to give-in to their business counterparts to make it happen.

The underlying need is probably obvious - multiple apps each have associated passwords. And more passwords means more to remember, less likelihood of utilizing strong passwords and higher likelihood of non-secure password practices (written notes, etc.).

As we all know, another way to solve the problem is to implement Single Sign On or Reduced Sign On solutions that enable applications to leverage a common authentication mechanism (or at least a common auth store). These solutions are complicated to implement and costly. And you usually need to find a way to synch with AD anyway since corporate users typically change their passwords using Ctrl-Alt-Delete.

ADAM directories serve as one possible solution for some of this pain. You can implement an ADAM directory to serve as the application identity store or even as a central authentication store and pass authentication request credentials through to Active Directory. This means a single password stored in Active Directory that can serve the network environment as well as the apps that leverage ADAM as the Auth Store. If you centralize the store, you don't really NEED to centralize the authentication mechanism, which might be nice in some cases. In environments with a large amount of custom-developed applications, a centralized mechanism would probably provide significant value even if there's already a common authentication store.

Wouldn't it be nice, though, if you could do the same thing without needing to implement ADAM directories and without storing the AD password in two locations? What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? You could potentially use the Virtual Directory to expose only specific attributes to given applications, reduce the overhead of an additional directory infrastructure, eliminate the need to store the AD password in multiple locations (and the need to install agents on AD DCs) and still achieve authentication to multiple systems using a single set of credentials.

[UPDATED Mar. 8, 2006] - Shorty after posting this, I was informed that MaXware Virtual Directory (along with its competition) does, in fact, support passthrough authentication to AD. I guess I thought ADAM was doing more than a simple bind, which is not the case -- I think I learned that years ago and forgot it again. So, I removed the question on technical feasibility. I guess the question becomes why aren't more people talking about this? It seems like it would be an incredibly useful application of our product.

[UPDATED Mar. 18 2009] - I posted more information about ADAM passthrough authentication.

The Value of Virtual: Part II

For the past week or so, I've been thinking about the value proposition for virtual directory technology (Virtual-D). Since I was first introduced to it, Virtual-D was presented to me as a new way to sync data -- an alternative to metadirectories and traditional sync tools. So, I initially thought about its value in relation to that of metadirectory/sync (as in Virtual-D vs. Sync).

Today, a co-worker and I discussed the significant overlap in the two feature sets and the various scenarios that might call for one or the other. Our enlightened conclusion was that Virtual-D and sync tools are complimentary parts of a complete IdM solution.

Then, on the drive home, a light bulb went on. Virtual-D doesn't replace metadirectory, it replaces... [drum role] directory. Hence the name. In an end-to-end IdM solution where you might want multiple directory instances with application-specific attributes and/or security mechanisms, you can replace much of the cost and complexity of numerous directory instances with a Virtual-D solution.

If the goal is to LDAP-enable an application (e.g. SSO, white pages) with enterprise identity information from existing clean data stores, Virtual-D is much less complicated to implement than traditional sync solutions. It doesn't require another data store and it helps circumvent typical political data ownership issues. However, Virtual-D requires clean, current data.
So, if you don't have good identity data available, you might look to aggregate data from the numerous data sources around your enterprise and to create an enterprise directory (or database). This is probably best accomplished using traditional data sync tools. Then, Virtual-D can use that newly compiled identity data store to expose relevant subsets of your identity data to your various applications. And without the need for additional directory instances. And it does so regardless of the data layout or the technology used by the sync tools.

With Virtual-D in the toolbox, it's easy to see why your metadirectory and your enterprise directory don't actually need to be directories at all. They can be relational data solutions. It's easier to store, manage, and sync data in relational formats. And most companies already have relational database expertise (and usually even licenses). When it's time to expose the data to an application, Virtual-D presents it in LDAP format achieving application interoperability and minimizing risk by presenting only relevant attributes to each app.