Posts Tagged ‘Virtual Directory’

Virtual Directory as an API

July 20, 2013

In only a few years, we have gone from the “new kids on the block” to leader in the industry as the only vendor to actually be creating innovation in the space and we are not done yet.  A bit overshadowed by our Best of TechEd win, Optimal IdM quietly announced back in June that we now offer our award winning Virtual Directory as an API!  “Virtual Identity Server Framework”, is a .NET API that allows developers to fully embed the power of a Virtual Directory directly into their applications.  This removes the additional layer that is traditionally present when connecting to a Virtual Directory.  Now, you can perform all of the typical LDAP operations easily and efficiently.  Authenticating users, LDAP searches, modifies, deletes, adds, compares, etc. all as simple as 1 line of code and without the developer needing to know much about LDAP.

The possibilities become endless with how quickly we can roll out new supporting elements with the API, such as being able to expose VIS to web services (SOAP, REST, WCF, etc.) or being able to now leverage VIS directly from PowerShell.  That’s right as part of this rollout we have used this API to build PowerShell Cmdlets that once again bring the full power of VIS now into PowerShell scripting.

Advertisements

What you can’t do in under 5 minutes

September 21, 2009

Optimal IdM recently released a video showing just how easy it is to install and configure the Virtual Identity Server.  The video takes just 5 minutes, mainly because, well, that’s all the time you need.  So, I was beginning to think about things that you can’t do in 5 minutes.  Here’s just a snippet of my list:

  • Smoke a cigarette
  • Wash your car
  • Take a shower
  • Make Breakfast (toast doesn’t count)
  • Drink a cup of coffee
  • Commute to work (well, this one wouldn’t apply to telecommuters) – Heck, I’ve seen red-lights that last 5 minutes!!

My point here is that it’s incredible to think of how easy we made the installation and configuration of VIS.  This allow our clients the ability to spend more time on planning and thinking of just how to benefit from this technology, and less time thinking/worrying about how to get the darn thing to work (out-of-the-box).  Be sure to check out some of the other videos in our growing collection.

Top 10 Laws of a Virtual Directory (Part I)

September 10, 2009

As more and more people are learning about Virtual Directories, they are asking better questions, so I decided to address them in my “Top 10 Laws of a Virtual Directory”.  This blog is Part I (Laws 1-5).  Stay tuned for Part II (Laws 6-10).

Law I:  A Virtual Directory MUST REDUCE complexity:  If you find your Virtual Directory deployment seeming to be somewhat complicated, then you either:

  • Selected the Wrong Virtual Directory vendor
  • Did not implement the solution correctly
  • Both of the above

Law II:  A Virtual Directory MUST NOT create more issues than it solves:  Yes, there are Virtual Directories on the market that set out to solve problem “x”, but in turn while doing so, create problems “y” (and sometimes “z”).

Law III:  A Virtual Directory SHOULD NOT be asked to solve ALL identity related issues:  For some odd reason, people feel the need to “compare” Virtual Directories with synchronization or federation, then saying which is better.  Each has its own pros and cons and should be used in the right situation.  There is no “silver bullet”, especially in the Identity Management space.

Law IV:  A Virtual Directory SHOULD NOT take long to deploy:  When selecting the right Virtual Directory for you, be careful if you are using a System Integrator (SI).  VIS can be deployed in as little as a few hours and normally no more than a few days (depending on the span of the project).  SI’s are only after deploying (and therefore recommending) products that increase their billable time.  They are often times NOT interested (i.e. incentives), on necessarily recommending the “best” solution for a given client.  Sad, but true.

Law V:  A Virtual Directory SHOULD NOT increase administration costs:  A Virtual Directory that requires you to hire more people just to manage/maintain it…is a bad choice.  In actuality, a “good” Virtual Directory (like VIS of course), should effectively “decrease” administration costs.  VIS does this through compliance and automation elements that are built into the product.  Another example is the tight integration that VIS has with SharePoint.  Don’t be afraid to ask your vendor (and their references) how much administration is needed.

Please watch for Part II in this series for Laws 6-10…

You don’t have to have multiple LDAP’s to benefit from a Virtual Directory

September 4, 2009

I can’t wait for part III of Bob’s blog series on “Why are Multiple Directories Deployed and Virtual Directories Ignored?“.  I’m afraid that people will associate using Virtual Directories only to solve the multiple-directory problem as being the only use, when in fact; the uses go on and on.

A Virtual Directory can provide significant value to clients whether they have a single LDAP, or hundreds of them. As I mentioned before, the perception is that “…if I only have one LDAP, then why would I bother with a Virtual Directory?” Well, I could ask the question “…is there any value in using a database view if I only have a single table?” or if I have a single web server, is there any value in using a reverse proxy? The answer to both of those questions is obviously YES, and likewise to that of a Virtual Directory in a similar scenario.

Oddly enough, the benefits in using a database view and the benefits in using a reverse proxy are the EXACT same benefits in using a Virtual Directory. Think about this:

Database View:

  • Provides the ability to filter out data that you don’t want to publish to the consumer of the data (Data loss/leakage Prevention).
  • Provides the ability to perform data translations to the data in real-time. This includes changing the names of fields to either obfuscate them or simply make them easier for consumption.
  • Provides the ability of an added layer of security to the back-end tables. They can be read-only or updatable.
  • Provides the ability to join like data from other tables in a merged view.

Reverse Proxy Server:

  • Provides the ability to mask the server names (obfuscation).
  • Provides the ability to join multiple back-end web servers and host them under a consolidated namespace.
  • Provides the ability of an added layer of security to the back-end web servers
  • Provides the ability of additional caching of information for performance gains of high-traffic websites.

So, I listed 4 common benefits of using a database view and 4 common benefits for using a reverse proxy. My list is obviously not a comprehensive list, but rather just a small sampling of the benefits. Ironically, ALL 8 benefits (there is some overlap), are the same EXACT benefits to using a Virtual Directory! Here is an updated list for Virtual Directories (again, most of these benefits have nothing to do with the number of LDAP’s you have either):

  • Provides the ability to filter out data that you don’t want to publish in LDAP searches (Data loss/leakage Prevention).
  • Provides the ability to perform data translations in real-time. A great example of this is virtually changing the OU structure of your data. Here you can flatten hierarchical data and conversely convert flat data to a hierarchical structure.
  • Provides the ability of an added layer of security to your back-end LDAP data. In addition, VIS provides auditing and reporting as well.
  • Provides the ability to join data from back-end LDAP’s (as well as other types of data stores such as databases, etc.).
  • Provides the ability to mask backend LDAP’s (and provides automated failover/redundancy as well).
  • Provides the ability to merge back-end data into a consolidated namespace.
  • Provides the ability to cache certain data to increase overall performance. (This topic is a blog or two on its own). A good example of this is an application (such as SharePoint), continually pulls data from AD on the user that is currently logged in. Enabling cache (say for just 5 minutes), could save hundreds of back-end searches to AD!

The bottom line here is that as scary as Virtual Directories sound, the benefits they provide are already in wide use today. It’s all about applying the technology in the proper way.

Virtual Identity Server | “The .NET Virtual Directory”

Why not use a Virtual Directory?

September 2, 2009

Bob Bobel from Quest posted an interesting blog today, posing the question “Why are Multiple Directories Deployed and Virtual Directories Ignored?“.  Basically stating that based on the concept of what a Virtual Directory provides, that everyone should have one (or want one).  In his quest to find out why clients don’t have or don’t use a Virtual Directory, his general feedback was that “it just doesn’t fit our needs”.

Hmmm, that’s interesting that this would be the hightlighted response.  In our experience, when talking with organizations (with multiple LDAP’s), most people really don’t know what a Virtual Directory is and exactly what one can do for them (although, they don’t want to seem behind on new technology, so they say things like “it just doesn’t fit our needs”).

It really all boils down to the lack of education on this emerging technology and the fact that there really isn’t much information on how they work or where to truely discover the benefits.  When Microsoft comes in to help a client solve technical challenges around LDAP (AD, AD-LDS, Multiple-Domains/Forest, etc.), they mostly won’t recommend technology that they don’t have to sell.  So clients miss out on opportunities to get educated on newer technologies that can help in certain situations.  For example, Microsoft will almost always recommend to synchronize instead of virutalize, because that’s all they know and sell.  Makes sense to me, but the client loses here by not always using the right tool for the job.  Take a look at this for a quick guide to using a Virtual Directory.

Anyway, I look forward to part II of Bob’s blog on this topic.