Tuesday, July 08, 2008

More on Virtual Directory Pervasiveness

Nishant and Clayton Donley have written some solid responses to my last post (and Jeff Bohren's post) here, here and here. (You've gotta love the responsiveness of the Oracle folks!)
I'd love to hear their thoughts regarding apps that seek to leverage some of the benefits from "advanced integration" with AD, as Jackson Shaw mentions in an old post (please don't ask me to explain them out)...

"...But I'm really interested in advanced integration with Active Directory like "serverless bind", Group Policy integration, the ability to modify permissions on resources...automatic failover in an Active Directory environment without any additional hardware or software..."

The comments section of the post is pretty interesting, given our current discussion. But putting that aside, would it be possible to leverage some of these AD specific capabilities, but benefit from abstraction using a virtual directory at the same time? Perhaps something like a virtual directory plug-in that allows an app to leverage some of the AD specific capabilities mentioned above, but still allow a COTS app that expects to see data in a specific way (e.g. shallow trees) to leverage a virtual directory to ensure that data is represented appropriately?

Pervasiveness of Virtual Directories?

Does anyone know what the actual market penetration of virtual directories is? How many mid to large sized organizations actually use a virtual directory in their infrastructure? With all the debate on virtual directory vs. metadirectory recently in the blogosphere, one of Nishant's comments caught me off guard, when he was responding to Matt's statement that there "...has been a ground swell of apps that directly support Active Directory as the user store":

"And how are more applications supporting AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions. A number of applications in the Oracle stable today claim to support AD as the identity store. The mechanism for all these is moving to Virtual Directory NOT because Oracle has a Virtual Directory product, but because maintaining adapters/connectors/plugins and what have you for all LDAP variants is a colossal nightmare."

Woah...that is a a huge claim there. Is it possible that the "groundwell of apps that directory support Active Directory" is due to "emergence of Virtual Directory solutions"?
Although I usually find what Nishant has to say as thought provoking, and the fact that every organization should be running a virtual directory solution is pretty evident by now, that claim sounds pretty absurd to me. What are the actual market numbers of the virtual directory solutions in production? (I know Radicati had some numbers around this, although I haven't gotten my hands on the paper yet.) Now compare that to the number of companies running AD. Even without the numbers, I think that Nishant is way off here. App support for AD is due to its undeniable pervasiveness, not because of the emergence of virtual directory technology.

Jeff Bohren has some interesting comments on the same post. Check it out.

Thursday, July 03, 2008

ESSO/Context and Healthcare, In the Trenches (Part 3)

From my last post, I promised a post to go a bit deeper on the technical side. Instead of reinventing the wheel, there are a few docs that could provide a good starting point. I think Gartner's report provides a decent high level technical overview of the products out there, although the vendor analysis seemed a bit superficial. The most notable area from the report is the "Architectural Differences" section.

The following is a terse explanation of how it works:
ESSO tools serve as a proxy between client devices and target systems. Target systems still maintain independent credential stores and will present their own unique, sign-on prompts to users' client devices. ESSO tools provide various mechanisms to sense sign-on, password and password change prompts for different target systems. Automated sign-on logic can fail when sign-on or password update prompts change with new releases of target applications or operating systems (OSs).
Two-tiered architectures will require schema modifications in AD (or whichever repository is being utilized), although it gets to leverage the benefits of your directory services infrastructure, like redundancy, fault-tolerance and performance. N-tiered approaches require a separate set of ESSO boxes (midtier architectural components) - i.e. more stuff to maintain, and vendors in this world tend to battle on how many concurrent users their boxes could handle (Don't confuse the number of users on a box, with the number of concurrent connections the box could handle. Sales folk love to muddle those two). On the other, this approach may prove useful if your directory infrastructure leaves something to be desired, or if your data is dispersed in more than one repository. In that case, a synchronization strategy is pretty typical from the various data repositories to the internal ESSO repository. Although I have yet to see it, I would love to see an ESSO/Virtual Directory model here. On paper, this seems like an elegant solution, allowing (for example) physician data to remain in eDirectory, employee data in AD, and the ESSO solution pointing to the Virtual Directory that intelligently routes requests based on user type. At least this would not mangle things with a metadirectory, though I'm not about to get into the whole 'metadirectory is dead/almost dead' debate.

Instead of going into depth on every ESSO feature, I've decided to put together a list of technical areas that are important differentiators. Each vendor may have a different approach in dealing with the situations described below. Anyhow, these questions are a good place to start:

* What directories does the ESSO solution support - in terms of storing ESSO data?
* How are username changes managed? For example, someone changes their last name, and their username changes...how does the ESSO system manage that?
* Every healthcare institution has a pretty involved Citrix environment. How will it deal with physicians accessing applications externally through a portal? Will it still provide the appropriate ESSO experience? Does the solution support authentication by generic accounts using virtual channel?
* Most healthcare institutions have areas with shared workstations, in which generic accounts are used for authentication. How does the ESSO solution deal with that? What about multiple session private desktops?
* How does the vendor support remote users (i.e. users connecting via VPN)? How does it support for a user connecting via VPN from a non-domain controlled PC?
* Does the solution support fast user switching?
* How easy is it to integrate new applications? Is the point and click wizard really that easy to use? (In a POC, make sure your techies get hands-on. An expert can make it look easy, so don't be fooled.)

On another note, if you are looking for a detailed analysis of the vendor offerings, at over 400 pages - the KLAS report on ESSO and Context Management is quite a comprehensive paper (Sorry, I can't seem to find the link right now), and definitely better than Gartner's magic quadrant report from a vendor analysis perspective.

Up next...a bit on Context Management.

Tuesday, July 01, 2008

IDaaS, Identity Services, SaaS-ish Identity, Whatever

Thanks Matt, for yet another wonderful term.
I think we've got to settle on some terms here. I recall a presentation by Earl Perkins of Gartner some time back distilling the distinct notions that are all referred to as "Identity Services." According to Mark Dixon's recap of Lori Rowland's presentation at Catalyst this year (I didn't get to go, and no, I'm not bitter), "Burton has encouraged Fischer to "give back" the "Identity as a Service" term to the industry." Anyhow, putting that problem on the side for now, I think Matt was referring to what the industry seems to be settling on as Managed Identity Services. I like Andrew Cser's breakdown, which refers to it as as an offering where "...a Managed Service Provider (MSP) provides on-site or off-site services to the customer, such as provisioning, directory management, or operation of a single sign-on service."

In Matt's post, he states,
"I don't think security or reliability is a good argument against buying into IdM as a service. Data can be encrypted. Admin activity can be monitored. Redundancy can be built-in."
Well said, Matt. Even a completely hosted solution like Symplified (which is a true SaaS offering - as opposed to Matt's SaaS-ish), can get around the security concerns, and even claim that they'll do a better job at it.
"The Symplified Identity Cloud combines a highly scalable grid architecture with massively multi-tenant design, and is housed in a secure SAS 70 Type II data center. This level of security is unmatched by mid market enterprises and many of the world’s largest organizations."
"The Identity Cloud resides in a hardened data center with enterprise-class security monitoring and defenses. A virtual private LDAP directory and 256-bit AES encryption secures credentials."

So, theoretically, the technology is there for security. But in my experience selling Managed Identity Services, the biggest concern is that customers are just not comfortable "outsourcing" the business processes that are so intrinsically tied and specific to their corporation. A SaaS model wouldn't necessarily face this hurdle, although a managed services model would. Customers still want to be involved somehow, but can't clearly elucidate why. In my opinion, the reason is more emotional that rational. The market just isn't ready, emotionally, to completely outsource the management of their IdM systems. The whole thing seems so tied to their environment, to their business processes, that handing the management over to a third party just feels wrong.

Ian Yip has some interesting insights into this point:
"IDM is like taking HR functions, "one-of-a-kind" custom business processes, all your people and all your IT systems and throwing these together into a mixing bowl and hoping you get a nice cake out of it. It usually takes a few attempts before you can even get a simple sponge cake. The first few attempts usually result in some inedible mess of a cake that you give to the dog to eat while you go try again. Problem with IDM is that there is no dog. You have to eat it yourself while trying to figure out why you've got dog food.

All the variables make IDM outsourcing destined to fail (for now). There are too many moving parts. Business processes are too specific to your organisation (e.g. every bank has different processes for the same thing). You're kidding yourself if you think you can make it someone else's problem just by outsourcing it. IDM will never be someone else's problem. It is always your own problem because you're managing YOUR users using YOUR business processes."

Although I agree that business processes are specific, my experience differs with Ian's claim that IdM can't be outsourced. I've been personally involved in accomplishing exactly this for clients, (although we did the implementation to begin with, so that made it a lot easier.) Matt sums it up well: "I think most companies are already outsourcing IdM – they just do it on a project basis..."
I think that the only solution is a pragmatic one, where there is shared management. The customer can still feel "in control", but hand over day to day ops to a third party. Control can be put in place to allow customers to enter in requests, ability to accept/reject change requests, approve any fixes, and transparency into any and all changes that go through. Focus on "control" (and honest discussions regarding the caveats) in conversations with customers, and they'll end up going a heck of a lot smoother. Also, the actual management goes smoother as well. Customer's get to gradually let go, and initially lean on the service provider as a very knowledgeable augmentation to their staff. Once the comfort level sets in, customers can lean a bit harder, grant "persistent approvals" for break/fix scenarios, and reduce management staff for identity.