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.

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.

Financial Model - Tips for Startups

If you're an entrepreneur, this is gold. Real data!
This is the stuff I get to read while everyone else is having fun at Catalyst. There's always next year.

ESSO/Context and Healthcare, in the Trenches (Part 2)

In my last post, I focused on the first lesson: In-House Homework first, Hold Back the Vendors. In this post I'll go on to speak about the importance of executive sponsorship as well as the application inventory.

Executive Sponsorship

I think a ton has been written about this so I won't go into detail. I'll give two live examples. The first example was from a client that was seeking a Provisioning solution. We spent significant time with the right folks, or at least we thought they were the right folks. According to titles and apparent job function, we had an executive sponsor on board for the project. We identified a solid road map, the right resources on both sides of the fence, everything seemed dapper. At the last moment (and I mean legal approved contracts, pens were drawn), the CIO pulled the plug on the project by simply stating, 'I don't like this solution.' Everyone was baffled.
Example number two has a more positive ending. This time, the correct executive sponsor in place. The organization is going through a massive re-org, and it seems that the project will continue running smoothly. The project hasn't completed yet, but so far, so good.

A lesson learned:

Lesson 2: Validate 'Executiveness'

Just because a sponsor seems like he or she has leverage, it's important to understand the dynamics of the relationships in the organization. Each company is different with vastly different cultures. Does the sponsor's superior respect his or her decisions? Does the person have a track record of pushing projects forward?


Application Inventory

On to application Inventory. What is an application inventory and why is it important? I have yet to meet a Healthcare organization that has less than 50 apps. The last one I've dealth with has 1400+! That means that for clients who wish to ESSO/Context enable their environment, we need to identify which applications exist in their infrastructure, how important they are for ESSO/Context Management enablement, the technical difficulty to enable the application, etc. This information will help provide relevant context for the usage of the applications and which applications to focus on first.

Here is a list of things to document regarding each application:

1. General info on the app: name, version, app owner, number of users, app function, etc.
2. Application type: client/server, web, terminal emulator, java, etc.
3. Does the client seek to SSO and/or Context enable this app?
4. What is the driver for enablement? security reasons? audit trail?
5. Ranking importance level for enablement. I.e., how badly does the client want to enable this app vs. other apps?
6. What are the processes around this app? (Login Screen(s), Login Success Screen(s), Login Failure Screen(s) - Note Different Screens based on User Role (Physician, Nurse, Admin, Staff, etc.))
7. Is the application CCOW enabled ?
8. Application Credentials - Does this application have it's own credentials repository or share one with other applications? Application Credential Submission - Does this application use auto submit? (Some applications require users to select printers-ESSO can not auto submit.)
9. Is Change Password functionality supported by the application ? (If Yes, does the application have a configurable expiration timer? What are the valid characters? Do you want to automate Change Password and Auto Generate Passwords?)
10. What is the Business Process of the application Change Password Feature Change Password Screen(s), Change Password Success Screen(s), Change Password Failure Screen(s) - Note Different Screens based on User Role (Physcian, Nurse, Admin, Staff, etc.)
    

This should give you and your team a good handling on your existing application infrastructure vis-a-vis ESSO. In my next post, I'm planning on taking a step back and talk a little about the technologies.

ESSO and Healthcare, in the Trenches (Part 1)

I've been involved in the early stages of a fairly large ESSO project as of late. Since it's been a while since I've been involved hands-on with a project, I've decided to write a short series regarding my experiences. The goal is to impart some practical lessons that a PM could use the next time they decide to undertake an Enterprise Single-Sign On project, with special emphasis on healthcare.

I love working with healthcare institutions. There's always hundreds of apps to support, disparate teams with fragmented goals, and pushy users with lots of power (clinicians). Sarcasm aside, its always interesting given the unique landscape.

Lesson 1: In-House Homework first, Hold Back the Vendors

The client had been embarking on this project for nearly two years. Out of the gate, they called every vendor under the sun to see which products fit their needs. The problem was that they didn't clearly identify their needs up front. The good news is that the client was smart enough to recognize their mistake. They put the vendor calls on hold (indefinitely), and decided to do some in-house homework. The client identified that improving the clinician's experience was their primary driver, which helped a ton with the steps to come (as I'll demonstrate in future posts). They followed this up with the following very intelligent steps:

* They garnered some serious executive sponsorship
* They completed a thorough application inventory


In my next post, I'll dive a little deeper into the two points above. Anyhow, this experience rang loud, especially in light of the recent storm of articles on KPMG's Identity & Access Management Survey findings (here, here and here):

"More than two thirds (68 per cent) of executives surveyed for KPMG’s 2008 European Identity & Access Management (IAM) Survey believe the effectiveness of projects is hampered because they put too much focus on technology and fail to address the organisational and procedural changes that are required. As a result, only a handful, (11 per cent) are fully satisfied with the outcome of their IAM projects."

Ouch...SIs better do something and quick. (I'm sure that KPMG has nothing to gain from that!)

An Interesting Identity Management Use case for Healthcare

I've been meeting and talking with a number of healthcare customers, and thinking about common scenarios that identity technologies could be applied to. And of course, you have the run of the mill common scenarios that address HIPAA (like ESSO, deprovisioning, etc...which are useful, but let's face it - common). But one scenario peaked my interest because it was pretty unique to healthcare, and really provided significant value to Healthcare IT in general, and in specific to Compliance.

Remote physicians' offices often have access to a slew of clinical apps, such as applications that allow a physician or staff member of a remote office to view patient data, x-rays, lab results, etc. In order to demonstrate compliance, some hospitals hire contractors to get in their cars, drive to each remote office (which could be in the 100s), and 'attest' which users still exist at that office, note changes to hires/fires, and each user's application access requirements. Then they leave and drive to the next office. This happens every 6 months or so as a part of the institution's compliance recertification efforts.

Federation would be able to provide remote offices the capability to control authentication of accounts on their end, allowing the hospital to manage authorization profiles...but some (many) of these offices are just 2 or 3 people. A doctor or two, maybe a nurse and a secretary. The only thing you could guarantee regarding their infrastructure is internet connectivity, let alone the skills and infrastructure to deploy a federation server. Anyhow, this falls more into the control category than the audit category.

On the other hand, Attestation fits perfectly here. (Nishant wrote a good entry on attestation here.) Instead of having a person drive around gathering a paper trail of access levels for accounts belong to remote offices, provide the remote offices a web interface to attestation workflows, which allows them to periodically 'attest' to who is still there, who is new, and what they have access to. Simple, not technically complex, but darn useful. Clients love it because it addresses a real scenario with real benefits. Sometimes the coolness of a use case has less to do with the technology, and more to do with how it makes otherwise painful tasks a little more bearable.

Practical Identity Management for Healthcare

Shahid Shah, the Healthcare IT Guy, recently asked me to write up a guest post on his blog. Here it is. Enjoy.

Random Thoughts on Novell's Recent Press Releases

Reaching 6000 users. Impressive, but how does it tally? Is it me, or does that sound high? How is that broken down per product? I'd also be interested in the $33m they reported in revenues for Q4 and how that breaks down per product. They categorize it under the "Identity and Security" umbrella, $30m of which came from identity... Is there a report that can help distill their real marketshare, as well as for other vendors? Either way, its impressive.

On another note, Novell's CTO Jeff Jaffe talks about FOSSA in an interview, and describes Identity as one of the pillars. When asked about how open-source their identity product line is, he honestly states:

Very little. We have some open-source projects; but it's still growing. From the point of view of where the customer wants go with agility, we need it all, but in practice it's going to mature at a different rate.

Given their interest in the open source space, I wonder if the folks at Novell are looking to existing open source initiatives in the identity space and how they might work together?

Neuenschwander, Burton Group, SIs and Philosophical Rantings

I haven't blogged in a while, but something in a press release a few days ago really got me thinking. Mike Neuenschwander recently left his position as Research Director for Identity at the Burton Group to join Mycroft, a systems integrator here in NY.

My first reaction? Pretty impressed with those folks at Mycroft and their recruiting skills.

My brief second thought was - is Mike going to be in NY now? And I wonder if I could pick his brain over lunch about Limited Liability Persona, Relational Continuity Sockets Layer, and guitar smashing.

But then I started pondering another matter all together: the relationship between theory and practice. Burton is mainly about research and advisory services, while System Integrators are all about practical implementations - where the rubber meets the road. Quite a contrast. Research, clean. Integrations, dirty. Research, what ought to be. Integration, what is. But then again, sometimes research describes what is. I suppose I shouldn't write blog posts when I should be sleeping. But before I do that...note to self (and anyone who might be reading): figure out the role of "research and advisory services" for an integrator besides the typical introductory advisory services provided before selecting and implementing a solution.

Open Source Provisioning - VELO!

Earlier this week, Jim Yang and the open-source IdM folks at Safehaus released Velo, an open source provisioning solution. These are the same guys who developed Penrose, an open source virtual directory product.
So as for all those asking for an open source solution in the provisioning space, here it is! And unlike other projects that make claims but nowhere to download and play, Velo is readily downloadable at sourceforge.
Very very cool beans.

On Garter's Provisioning Report, Notes and Inquiries

Gartner's User Provisioning report came out a few weeks back. I had a few questions/thoughts about it.

The first is the notable addition of Novell and Courion to the leaders quadrant. Courion's addition is especially interesting, as its now the only boutique in the leaders' quadrant, which says alot about their product and market presence. The fact that they could play with the big boys is notable, and I've seen alot of clients asking more about their products lately.

The second point is more of a question. When speaking of Sun, they that Sun "...also has a strategic commitment to open source, with open-source versions of its user-provisioning software...". Is that true? I haven't heard of it. I did blog previously about openptk, but as I mentioned - that's not an open source version of Sun's provisioning application, but rather a toolkit. So what's the deal? Am I missing something or did the folks at Gartner goof?

Open Source Provisioning!!!...toolkit

I've been having a few conversations with colleagues about the absence of an open source solution for automated provisioning (keep an eye out here...something cool to come out soon), and then today, I made my way to the openptk website.

Now, I know that these guys don't have an actual provisioning solution, but rather a toolkit of APIs, web services, HTML taglibs, etc. that plug into existing provisioning solutions. Unfortunately, there isn't alot of info on their site, but its absolutely intriguing. Affiliations aren't hidden - all three contributors are Sun employees, and their site clearly says: "The architecture supports several pluggable back-end services including Sun's Identity Manager, Sun's Access Manager and LDAPv3."...but theoretically, this could plug into any provisioning solution, or am I being too optimistic?

IdM Processes...Existing vs. Future

Corbin Links put together a thought provoking post the other day on identity management implementations, and how companies are looking for a magic tool that could resolve their identity management woes, when they should primarily be focusing on their processes.

"Don’t start with the tool. Don’t start with even thinking about vendors. Don’t think “gee, now that we have fully committed to Identity and Access Management we will just outsource the whole thing, and a third party will take care of our business process for us.” Instead, make the commitment to work through processes. Don’t worry yet about higher-level tasks such as “role engineering” and “compliance baselining.” If you start there, chances are it will not be worth the paper it’s printed on by the next fiscal quarter. Instead, collect processes. Start with “business snippets” and work up from there."

This got me thinking of a conversation I had with a few folks who are part of the professional services arm of an IdM vendor about this (although this may not be what Corbin was hinting at), and the individual was educating me on how they engage a client on an IdM project. His advice: don't waste too much time on their existing processes, because they are going to change anyway.

I suppose this advice works (even then, only partially) for a company that is willing to completely change existing processes based on advice given by a few individuals that probably know little to nothing about their business - which I can't imagine are many.

One notable exception are the companies in the SMB market. My definition for SMB companies from an identity perspective lie between 200 and 2000 (perhaps that's a little generous). There are many companies in this space that have the regulatory pressures, but are typically flexible to change their processes to "template processes".

Nonetheless, for companies that don't fall into this category, regardless of size, the question is - what are the inherent dangers of glossing over existing processes, and focusing most of the attention on future processes? Perhaps missing some of the "must-haves" in new processes, but not necessarily. With that being said, time for a movie...to be continued?

Apple's New Product (not the iPhone)

Yup...got the iPhone. Love it, but getting used to the keyboard.

So - Apple is already launching new products...take a look.

Am I obsolete already?

On Anonymity

www.gapingvoid.com

Federation Woes

Techtarget has an insightful article on the difficulties surrounding Federation and its abilities to penetrate the market. Alot of the content arises from Burton Group's Neuenschwander, and his work on the topic. Neuenschwander eloquently sums it up: "Businesses have inescapable constraints and markets are brutally pragmatic."

Very true. In my experience, companies who may have a business need for managing authentication and authorization for externally facing apps more effectively with specific partners - BUT don't view it as absolutely critical for their business will opt not to deploy federation for two reasons:

1. The invasiveness of the technology vis-a-vis the partner's environment. i.e. the requirement of deploying a federation server in the client environment.
2. The legal ramifications involved as to liability and data ownership ("who owns the data associated with various identities and who has the final say when the data doesn’t agree") ... Phil Windley has written some interesting points regarding this.

I've dealt with a number of companies that were very interested in the technology, but decided to go with other, less elegant solutions because of the complications involved with these two concerns. On the other hand, when the business case is strong enough - federation is a wonderful solution.

A few years back when I got interested in federation, I was very impressed and was looking forward to aid federating the world. Unfortunately, it didn't turn out that way. As Neuenschwander stated... "the world isn't as it is in developers' dreams...businesses have inescapable constraints and markets are brutally pragmatic."

Wireless Sour Grapes

Verizon CEO: "We need to let iPhone hit the market and see what then reaction is," Seidenberg said. "It doesn't change our game plan. The burden is on [AT&T and Apple] to see if the market will change."

Burden on AT&T? Verizon could lose a million subscribers, they've lost the innovation battle (Prada?), and it seems that they'll be content with a healthy second place. How's that for leadership?

Thoughts on Rapid Identity

An interesting quote I pulled off of Mark Dixon's Identity Trends Presentation from JavaOne.

“I have recently noticed customers more willing to adapt their business process to out-of-the-box capabilities and industry best practices. There seems to be a large shift in maximizing costs and conforming to standards based provisioning. If this trend continues to thrive, average implementation costs and maintainability will become more palatable for customers looking to get the most out of their phased identity deployments.”
- Robb Harvey

Well said. Also, here are some points from Mark:

• Template-driven rapid implementation methods will be used to reduce Identity Management
implementation time and cost.
• Best practices captured in rapid deployment tools will allow enterprises to minimize customization and increase system effectiveness.
• Rapid implementation tools will allow Identity Management systems to be deployed in smaller enterprises.

It's an interesting notion for business process to morph to templates. I recall when I first started in the identity space, that was the battle we would try to win. Never did though...business processes, however warped they might have been, would for the most part remain the same and we would architect the identity solution around it. Regarding the SMB market, I would have to agree that they are definitely more flexible...but the template approach is extremely difficult for me to envision coming to fruition. Even with our iRim product (Identropy Rapid Identity Management), our prepackaged workflows end up going through some rigorous tweaking before clients are happy. But I must admit that there is an inverse relationship between the size of our library and the amount of tweaking we do.

Kerberos, a la Shakespeare

I just read an excellent kerberos primer in the form of a play, full with Dramatis Personae and Scenes. Athena and Euripides exchange thoughts on open network environments, and validating identities. Identity was relevant back then just as it is today...here's an small excerpt:

Euripides: Your workstation system sounds really good Tina. When I get mine, you know what I'm going to do? I'm going to find out your username, and get my workstation to think that I am you. Then I'm going to contact the mail server and pick up your mail. I'm going to contact your file server and remove your files, and--

Athena: Can you do that?

Euripides: Sure! How are these network servers going to know that I'm not you?

Athena: Gee, I don't know. I guess I need to do some thinking.

Euripides: Sounds like it. Let me know when you figure it out.

More IdM Services Company Acquisitions

Two more, to be exact...the first is our very own Identropy, which is in agreement with Earthling Security to acquire it. Although Earthling is more of a general security company, IdM was the major part of the reasoning for the acquisition.
Secondly, a press release today stated that ProtechT was acquired by Integralis. Integralis CEO stated:

With this acquisition, Integralis’ portfolio will be expanded by ProtechT’s
extensive knowledge in identity management and its expertise in multi-modal
biometric and smart cards.

According to ProtechT's website, it also seems like a general security company. In fact, it is self-described as an "Information Technnology Security" company. Nonetheless, the acquiring company's reasoning for the acquisition was identity, according to the quote above. These two acquisitions add to the Sun's Neogent acquisition from last year, as well as Novacoast's eNvision acquisition, and Secured Services, Inc. acquisition of Cybrix Corporation's Identity Management PS team. Perhaps this is an indication of further maturation in the Identity Management M&A game?