Friday, January 19

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.

3 comments:

Sitaraman Lakshminarayanan said...

Virtual Directory actually complements a Meta Directory Solution.

You would use Meta Directory Solution to Syncrhonize Enterprise Identity Data
across all the data stores to keep the informatiion Consistent.

If you take a look at any large enterprise, there are atleast 10 different Systems
each having your Identity Information such as First name, Last Name, Phone, Address, etc.

In this scenario, Meta Directory solution helps to keep the data in Sync
with all the data stores.

However, as Organizations build new systems, buy other COTS products
two basic requirements they have to address:
Keep the User Identity data in sync with enterprise data

Enforce Strict Access Control (it will be tough to move all the
old and new Products or Systems authorization information
into Enterprise Directory)

Now if you were to use Enterprise Directory (syncrhnozied
using your Meta Directory product) there is a significant
effort involved in creating those sync rules with new data store.

However if you use Virtual Directory,
you can join any data store on the back end and can control
access to applications without having to deploy
a meta directory solution (especially for access control).

Another Example:

Authentication/Aurhoziation often times is not a straightforward
LDAP Bind/validation alogn with Group or RBAC.
Especially applications in Insurance, HealthCare, Financial, etc requires more than
just validating uid/pwd to authenticate the user.

If you deploy just a Meta Directory Solution,
a) you have to syncrhonize data with Enterprise Directory
b) Think about the time it takes to syncrhonize 10 data sources into
one directory and the time the user has to wait if they need access
to all the 10 applications.

Thanks
Sitaraman Lakshminarayanan
(Ram)

Matt Flynn said...

Thanks for the comment Ram!

Anonymous said...

nice post