Healthcare Applications and Identity

Healthcare applications are notorious for using proprietary identity systems for user authentication and authorization. It’s a problem in many industries but seems to be most rampant the healthcare industry and continually challenges most every healthcare customer that comes into the Microsoft Technology Center (MTC) in Chicago.

It is surprising, but not expected. As healthcare application developers seek to get their product to market quickly, and the fact that the application is typically sold to the “almost” end user customers at healthcare providers, little consideration is given to see if the application has the ability to honor any kind of enterprise directory IT may have, or even leverage a common identity provider like LDAP or Kerberos.

I have yet to speak to a client in the healthcare field that comes to the MTC to consolidate down their identity management where this doesn’t come up. And it always comes up as a hindrance as they try to reduce infrastructure complexity and get to reduced sign on, let alone single sign on.

This prevents optimization of healthcare IT environments. Our healthcare clients are unable to increase their IT maturity without driving down the complexity around identity.

The biggest reason application providers don’t do this correctly, I’ve found, comes down to education. Let’s look at a much better way for the app developer to have this necessary functionality and be a better IT participant.

The most beneficial way for application authors to compose their application is to embrace a mechanism that can allow for a local authentication source, yet be able to honor an upstream enterprise directory. While this sounds complex, it is actually easier to follow some preferred practices that can actually reduce the effort and time for an application developer to offload this component of plumbing for any and all applications.

Microsoft offers several methods for an application developer – Active Directory Lightweight Directory Service, or AD LDS (previously known as Active Directory Application Mode, or ADAM) is ideal for a standalone application that requires a store for managing users and identity. This is ideal for standalone applications – can store applications settings in addition to the basic LDAP signon. But what if this application needs to authenticate to an enterprise directory based on Active Directory? No problem – the AD LDS can honor an upstream Active Directory (AD) implementation. What’s even better is the local application settings can reside in AD LDS while the authentication still happens at the AD level. No extra replication. Keep in mind that AD LDS and AD use the same interface calls and parameters, so its relatively easy for app developers to leverage AD skills for AD LDS.

Customers of these applications, in an attempt to streamline and optimize are starting to use this criteria in selection of healthcare applications. We are advising all customers that come through the MTC to challenge their application vendors to honor their enterprise directory source.

Lots of information on how to use AD LDS on microsoft.com, here’s a link to the FAQ: https://www.microsoft.com/windowsserver2003/adam/ADAMfaq.mspx