Poor Man's Deprovisioning

In this economy, I've been repeatedly pinged by clients on how to maximize their investment in their existing Identity Management software investment. In other words "I want to do all this stuff, but I don't want to buy more software, and barely buy any services."

So here is an idea that came from a conversation with one of our engineers. This is for clients that own a Password Management solution only, but want to be able to deprovision users. They could create a workflow to change the password to all target systems to a random password that no one knows. In effect, the user would be locked out of all accounts. A small program could be written to call the workflow's SPML interface (assuming it has one) based on a feed from Payroll or HR as well for a nightly process. No new software, barely any services, but an effective deprovision of accounts.

I'm noodling if this would pass an audit, but I doubt it would since the account is still active. But it would work, it would leverage the clients investment in connectors built for all target systems, and could be accomplished in no time.

I think it's the best thing since sliced bread, but I'm sure I'll find a new favorite tomorrow. Would this work?

Identity, Holidays, and a Little Marketing

Fun.
Enjoy!

Virtual Directories and Persistent Cache

I got drawn into a debate lately about the pros/cons of persistent cache in a virtual directory, and the practical implications of it. (I know this is an old debate. Better late than never?) A persistent cache is basically storing a copy of data locally at the virtual directory, so it doesn't have go get the data each time.

The first question is 'why add this capability? isn't the whole point of a virtual directory provide real-time access to backend data?' In my conversations, I basically received one answer: performance. Virtualizing and transforming the data can slow things down a bit.

Clayton Donley makes a case against persistent cache in an older post. To summarize:

• Persistent cache will mean data isn't real-time, which means the 'freshness' of data will be compromised.
• There are security concerns with adding another place to keep the data.
• There is pain associated with managing yet another directory.

(i.e., if you want a metadirectory, then get a metadirectory!)

So, I've come up with a few questions, and was wondering if anyone has any thoughts about it...

1. Since performance is the main point here, does any one have numbers on the performance hit caused by virtual directories?
2. Is performance the only real justification for persistent cache?

Managed Identity Services Winner

Thanks to everyone who filled out the Managed Identity Services survey. We finally identified the winner of the giveaway....and the winner is Niall McLoughlin! Enjoy your new iTouch! Thanks Ian for all the work on the survey, and thanks Matt for aiding with the whole winner selection thing.

A Few More Snappy IdM One-Liners...

In response to my request for snappy one-liners that would be applicable for identity projects, Jeff Bohren and Mike Conklin (welcome to the blogosphere, Mike!) provided some input. Here are some of my favorites:

• The dirty little secret about provisioning is that it’s really all about deprovisioning.
• You shouldn’t start out trying to do account management by adding another account to manage.
• It doesn't matter what you do on the back-end -- if the end users (and project sponsors) can't see tangible results that affect their day-to-day activities, all the process re-engineering and data clean-up in the world is going to go unnoticed and unappreciated.
• For whatever reason, hearing the exact same thing come from an outside consultant actually sinks in with management, but this never seems to happen for internal people :)

Seems like fun so far... so, I'm tagging Matt F., Matt P., Azeem Khan, Mike Trachta, Ian Yip and Jackson Shaw (just to throw a little product in the mix) to contribute their wit to the conversation.

It's About the Business...

I just got back from another long day with a client to aid them lay out their identity management roadmap. I've noticed a few interesting recurring themes:

• Good technology can't compensate for bad processes (although it might make it less painful)
• Fixing your data without fixing your processes is like painting your house on a rainy day
• Throwing more software at an identity problem usually exacerbates it
• A dollar in an identity project doesn't take you as far as you'd expect (even though its well worth it)
• What business users think is happening is quite often vastly different than what is happening under the hood
  

Any other snappy one liners?

Repealing SOX and Identity Management

Newt Gingrich and David Kralik wrote an op-ed in today's San Francisco Chronicle about repealing SOX. I've been following the buzz around this for a few months, but it always has a bit more bite when it comes from a former Speaker of the House. Gingrich and Kralik outline a number of convincing reasons to repeal SOX, including its negative impact on the IPO market as well as its failure at "...preventing insolvencies and accounting shortfalls in companies such as Bear Sterns, Lehman Bros., American International Group (AIG) and Merrill Lynch." The last lines of the article are very action oriented,

With a new presidential administration and a Congress convening in less than three months, now is the time to begin thinking through the solutions needed to address our economic challenges. Economic growth in a sound market economy requires smart regulation, not destructive regulation that hurts economic growth. Sarbanes-Oxley fails that test. It should be repealed.

I've written previously on the need to move away from compliance as *the* driver for identity. A legislative act such as this could force our hand as an industry. Being personally involved in the process, I am acutely aware of the impact that compliance has on quickly approving budgets for projects, and the way IT has leveraged SOX in order to push projects of their liking (even if its true ability to demonstrate compliance was suspect). This hyper-compliance environment may have created complacency on our end from the perspective of demonstrating the true value of identity for the business. Anyway you slice it, if SOX gets repealed (or slimmed down, as I expect it will be), we're going to have think a little harder, and I think that's a good thing.

Random Thoughts on Hitachi and Construction Cranes

Looking outside of my window this morning, I noticed a construction crane with the label "Hitachi" on the side. I kind of chuckled at the notion that a company could provide Identity Management software and construction machinery at the same time. Being part of startups nearly my entire career, where focus and niche is everything, my narrow view of the world makes it difficult to comprehend that a company could do such vastly different things effectively. Then again, it's not the first time. Siemens has its foot in the Identity world, and makes hearing aids and dishwashers too.
Does laser focus in the startup world not apply to larger corporations? I'm sure there are a few dozen books on the topic...time to go find 'em.

The Answer is...On-Premise Managed Identity Services

Ian has posted his findings from his Managed Identity Services survey. My primary interest around the survey was to see if data could be collated that could identify characteristics of a managed services solution around IdM that would make customers "comfortable". (In the past, I've posted on the "comfort vs. security" notion). Anyhow, some tasty nuggets are below. Go to the real survey findings for more.

• 67% of respondents have already completed a provisioning implementation (3% as SaaS, 10% have done it in some type of managed service offering, 37% have host and manage it themselves)
• When asked what model they would prefer, 19% wanted SaaS, a whopping 36% wanted an on-premise managed service, 19% wanted an hosted managed service model (that's a total of 55% who are looking for a managed service offering!), while only 13% want to handle it all themselves.
• When asked about what was the barrier preventing them from outsourcing IdM, 22% identified security risks around data being held outside of their infrastructure, 20% said risks regarding external people access their environment, 14% said cost, 11% said loss of control.

So, it seems that although most respondents managed it themselves, over half wanted a managed service model. The risk around data being held outside of their infrastructure could be alleviated by an on-premise model, although I don't think that the significant 20% who didn't want outsiders accessing their environment will be appeased by any solution.

A Few IdM Vendors Responding to the Market

Courion put out a press release today around their Jumpstart program for Password Management deployments. Undoubtedly not a coincidence given the market conditions. It's worth a look - 4 target systems, ROI in 30 days, fixed-price delivery. Not too shabby.

Also, Symplified has a webinar coming up entitled 'Scary Economic Times Heighten The Need for SaaS Security' with Jeff Kaplan: "With the current economic downturn pressuring enterprises to freeze capital spending on software and quickly find ways to lower spending on IT, the move to SaaS has never been more compelling. This has accelerated already rapid SaaS adoption in an effort to save costs and reduce IT spending."

I'm sure more to come....

More on IdM in the Economic Downturn

Over lunch with an NYC VC, conversations inevitably turned to the economy and it's impact on startups. A telling takeaway was that cost cutting in IT budgets is going to be deeper than previously expected. Gartner and Forrester until just last week stated that IT spend will grow less than expected (Gartner placed it at at 2.3% and Forrester at 6.1%). On the other hand, the gentleman I had lunch with stated that those predictions will most likely be changed dramatically, and that the number on the street is that cuts will be in the ballpark of 20%. Now given that typically 65% of IT budgets are dedicated to maintenance and upkeep, that leaves about 15% on the table for new initiatives. Ouch is right!

In my opinion, if IdM projects are to survive these cuts, it has to be positioned around 2 areas simultaneously: 1. The project has to be linked to core business and 2. Cost cutting capabilities. If the project can't rally around both, it's probably a gonner.

A good case in point is how salesforce.com made it through the 2000-01 scenario. It provided an easier way to do CRM (critical to core business) in a more cost effective way.

So the question is...who's going to be the salesforce.com of the identity world? Or from a project perspective, which initiatives will be able to survive?

A few random thoughts: I like SSO/Context Management in healthcare. Great impact on the business (especially for clinicians) and cuts cost. Password Management is pretty good, except impact on the business in most cases is negligible. The same goes for provisioning and role projects, although a better case could be made for impact on core business. Unfortunately, I think the new kid on the block, privileged access management is in trouble because of its positioning as primarily a security play. I'm still noodling this, but I'm sure this scenario will bring about some interesting innovations in our space in the coming year. Nonetheless, the forecast is pretty cloudy from where I stand.

Selling Identity in an Economic Downturn

Rough week. And it's Tuesday. In the wake of the current financial crisis, I've received 3 phone calls in the past 3 days from potential customers (who were almost surely moving forward with an Identity Management deployment) to tell me that the project is in serious jeopardy. All three happen to be in the healthcare sector. One of them was given a mandate to cut $1m from his budget. Another simply stated that all new initiatives that haven't been inked yet are frozen indefinitely. The third stated that their organization's revenues were deeply impacted because of cuts in Medicare/Medicaid, and any and all projects not directly related to core business will be cut.

I've been able to position the projects to be possibly salvaged by quickly shifting drivers from compliance to ROI and cost avoidance opportunities. Thank God we're in an industry that supports multiple and varied drivers! I think that trying to sell Identity from a compliance and security angle in this environment is just a lost cause, which will probably impact the types of technologies that will be deployed. Any thoughts on other business/tech drivers that might be used? Which types of identity projects will live and which will die?

How to Make a Better Identity Management POC

Mike Trachta responded to my previous post about lackluster POCs by highlighting the difficulty posed to SIs to live up to the fantastic show presented by the POC folks.

"...the customer remembers more about the POC than you think. They remember how pretty the screens were. They remember how seamlessly all the pieces fit together, and how quickly each task executes. What they don’t realize is that all of the data is massaged and simplified. Of course the POC could do these things! It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment. When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex."

Jeff Bohren put together an eloquent post as well, pointing to his experience as the developer in the background helping out both the POC folk, as well as the SI who has to make this happen for real. It's a great read and provides insight from both ends of the spectrum.

I have a few suggestions that might make your IdM POCs a little better. So here they are:

1. Couch your immediate goals in the context of a larger Identity Management initiative that ties it to your business objectives. Jeff already hit on this point in his post, "Instead of doing a POC of who has 'The Most Magical Bullet', enterprise would be better suited to craft a long term IdM strategy and chose a vendor whose product best aligns with it." This approach voids the notion that phase 1 of the project has to cover everything under the sun. A fantastic way to do this is to engage an SI that understands the game, and can walk you through an Identity Management workshop that speaks to both your business and technical objectives.

2. From your workshop findings, carve out a Phase 1 of the project that is attainable - the best way to do that is to write up a handful of detailed use cases that boils the expected deliverables down to non-technical language.

3. Highlight the top X number of use cases to focus on for a POC. Keep it limited (but representative) of your expected project deliverables. Identify the vendors who might be able to respond, and request a technical architecture document outlining their approach to solving the use cases you have identified and have a Q&A session with them. Filter out the vendors who don't make the cut (yes, I know that's a loaded sentence), and identify the top 1 or 2.

4. Prepare a POC lab. (Another loaded sentence).

5. Bring the vendors in, but don't allow them to touch anything! OK, this suggestion point might be a bit much but I suggest that, as much as possible, have the vendor's experts sit on their hands, next to your techies while your techies drive. If the vendor whips out a canned script, your guys will know it (and document it in the findings). If the vendor has to make a nasty directory schema change, your techies will know it. If the vendor has an ugly hack that inserts pages of code into the presentation layer of the "ultra configurable identity app", your techies will know it.

6. Have a structured way to present the findings.


While I know that the approach above requires a lot of background knowledge and support, it just seems to be a much more valuable experience that actually tells you something that a demo can't. If help is needed, supplement the team with an SI that has strong experience in the space. Either that, or save everyone time and effort and just make your decision based on sales demos and references.

Why (most) Identity Management POCs Suck

For those unaware, POC is an acronym for "Proof of Concept", and consists of a client requesting a vendor to bring their software in to demonstrate ("prove") that their software can perform in their environment as promised ("concept"). The engagement usually lasts for a few days to a week, and typically the vendor foots the bill (if the potential deal is large enough). Most often, POCs are borne out of a conversation between a client and an industry analyst who completed a 2 hour identity management market briefing, concluding that it would be a good idea for the client to host a POC. A few vendors are selected to strut their stuff, and after reviewing which vendor did a better job, a winner is hailed and ultimately awarded the contract.
After being involved in one too many POCs, I've come to the following conclusion: IdM POCs suck. Usually. And here are a few reasons/scenarios that explain why:

1. A typical POC is just a glorified demo. So, wisdom states that if the vendor is integrating their software with your target apps, then it's not just a demo, but undeniable evidence that their software is good for you and your organization. That is both true and false. Just because software can be made to "seem" to work with your apps is not evidence that the integration is robust or production ready. Hacks are very common in POCs, and a lot of what is demo'd at the end of the POC is a lot of smoke and mirrors and doesn't prove that what was completed is production ready, or more importantly, can ever be production ready.

2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy. The vendor that has the best duo typically wins the deal, which may not reflect the best software solution for your environment. A good SE can make crappy software work (with his arsenal of scripts and tricks), and a good POC-demo-guy can bedazzle almost any audience. On the other hand, a bad SE can make good software break, and a bad POC-demo-guy can put a lively audience to sleep.

3. A POC is typical technology focused. Most IdM deployments are business process centric. When decisions are made based on the number of out-of-the-box connectors or the long list of supported standards without considering how it all applies to your specific set of business processes, the wrong vendor can be selected.

Well, I'm sure there are more reasons, but I'll leave it at that for now.
But the picture isn't that bleak. There are ways around the problems above, and exciting approaches that will not only make POCs not not suck, but actually make them effective and useful...a topic for another blog entry.

Managed Identity Services - OOOH, A SURVEY!

Ian's done it again. I've come to admire his style of blogging-outside-of-the-box.
Over the past months, a number of bloggers have commented on the notion of managed services in the world of identity management, and speculations around customer attitudes towards it due to security/privacy concerns, as well as from a process perspective. Ian decided to cut through all of the speculation, and put together a survey on managed identity services aimed towards clients, in order to capture a sampling of actual client feedback. Brilliant.
I immediately saw the value in this, and decided to reach out to Ian in order to see how Identropy could help out. Ultimately, we decided that a simple giveaway might spur user participation, but agreed on keeping the marketing mumbo jumbo to a minimum at the same time. This is about getting clients involved in our discussions, reporting on the findings and hopefully initiating more practical conversations around the topic in the community. I'm very excited about working with Ian, and he has turned out a very well put together survey.

A last note: This survey is geared towards actual customers rather than vendors or integrators. If you are in touch with customers who have an identity infrastructure in place, please forward them this link ( http://www.surveygizmo.com/s/68286/ian-yips-managed-identity-services-survey ) if they want to participate. They do NOT have to provide any personal information if they do not want to. Our only interest is assessing attitudes out in the marketplace towards this notion, and the wider the participation, the better the data Ian gets to report on.

Is WAM Complex?

Jeff Bohren responded to my post on Symplified yesterday, stating that although he agreed that most WAM solutions are complex, the OpenNetwork/BMC (now Symphony) solution doesn't fit that mold.
Admittedly, I don't have experience with the BMC solution, but Jeff makes a good case for its simplicity:

(it) could be deployed with nothing more than AD and access control agents on each web server. The access control agents served as both a PEP and PDP. No policy servers, APIs, or proxy servers required. The same accounts used for intranet login could be used for web access control and the policies could be expressed in terms of AD security groups.

A few questions, (pardon my ignorance). What if apps want to query policy information (for example, does this user have access to that resource)? Do they query AD directly? Might that not get complicated if there are a complex array of rules to crunch through? Some environments seek a web services based API rather than the (typical) java API. Who stands that up? What about the admin console? Who manages that? Also, doesn't agent management become a headache? Keeping up with different web server versions, and handling upgrades could cause admin overhead. I agree that the solution sounds easier, but for an admin with a mediocre skill set, it seems that it would prove challenging. I'd love to hear your thoughts/real life experiences.

My experience falls more in the cleartrust/siteminder/oam realm, and clients constantly complain about maintenance. Here is an example. Some years back, a company sought an access management solution, found one, bought it and contracted a consulting firm to implement it. They did, and left them with documentation just as any good firm would. Years later, policies required updating, certs started expiring, web services API was requested, redundancy was removed/neglected, and general failures became more frequent. I rummaged through old docs, and found a diagram from existing documentation (sanitized).
Besides the components shown, there was a BEA server that hosted the management interface, as well as a web services wrapper for the WAM API, and of course, agents on each web server. The infrastructure also included a CA used exclusively for the WAM environment (don't ask), and was therefore considered part of the same admin burden.
The client wasn't especially tech savvy, and explaining the difference between an authorization server, dispatcher, entitlements server, and how to ensure they were appropriately set up in failover mode, and how to troubleshoot when specific problems arose wasn't particularly easy. Most importantly, it wasn't the client's "fault" - they had a host of other applications they were tagged with managing (including a metadirectory, provisioning solution, security event management, directory services, etc.), and handling a WAM solution was just another component waiting to be neglected.
I don't think that this is an unusual scenario. Now even if the complexity level were cut in half, it's still quite a bit of infrastructure to handle for an admin staff that is already overburdened. Now imagine someone offers all of this in a hosted model, and a pretty appliance (or 2) in your infrastructure that you really don't have to worry about managing...

My Latest IdM Crush

At DIDW, I got a chance to sit down and chat with Eric Olden, CEO of Symplified. Symplified brings Web Access Management into the SaaS world. Their approach resonated with me immediately.
A few clients we had just been dealing with over the past weeks had "fires" that needed containing. For one client, after 48 hours of dispatching consultants, phone calls to support, and just hard core technical work, all was well...for the time being. Soon after, another client had a similar situation. Things were going down all over the place, and no one knew why. After significant investigative work, the culprits were found and dealt with. But the real culprit wasn't a person or an inopportune config change. The real underlying problem was a complex (and perhaps antiquated) IdM infrastructure put in place by a team of consultants years ago coupled with an IT team that didn't provide the identity management infrastructure the appropriate level of care and feeding. Unfortunately, this toxic combination is not uncommon in mid market enterprises.
Enter Symplified. Anyone who knows idenity knows that WAM infrastructures are rather complex. Agents, proxy servers, APIs, Policy Servers and a host of other moving parts. Eric walked me through Symplified's approach to "symplifying" (get it? i just did) this complexity. Think of a proxy based WAM architecture. Symplified provides an "identity router", which is an appliance dropped in the client's infrastructure that acts as the proxy. All traffic to protected apps get routed through the identity router, which acts as the policy decision point as well as the policy enforcement point. Identity data can be consumed from your existing identity stores. For example, you could have the router point to AD to pick up users, but policy information is stored in the router itself. So where does the SaaS component fit in? The admin interface is hosted in Symplified's SAS 70 Type II data center and allows access policies to be defined. Once completed, the policies can be pushed down to the identity router in the client environment. Symplified also provides a slick option to deliver the identity router as a virtual appliance. They call it the GTV form factor, and it can run in an existing ESX environment.

The last word: the client has less infrastructure to manage. Compare this to the number of components in your typical agent based WAM solution, and the value Symplified is providing should be pretty obvious.

The VDS Use Case

I attended Radiant Logic's workshop today at DIDW. An interesting tidbit that they shared with us was that a whopping 90% of field usage of virtual directories today are around solving authentication problems.
Given all the wonderful use cases that virtual directories solve, I'm a bit surprised the lopsided real world usage. For folks in this space, is this what you're seeing as well?

Words of Wisdom: Sell Early

Phil Windley has a fantastic post giving good startup advice. The basic idea is, don't wait to sell your product/service. Never wait until its "ready", because chances are, you'll never think its really ready. An eye opening point he makes is that selling to customers and speaking with them helped him up his pitch-game more than talking to VCs and raising capital.

As a consequence of all this, I wish we’d been positioned to start selling well before we started raising money. Unfortunately, because of various timing issues and our own understanding, things didn’t work out that way. If I do this again, I’ll start selling much earlier.

A question that pops into my head: is there a point where you are just too raw to go out there with your product. I suppose there is an inverse relationship between how ready your app is and the patience (and free-time) of your first customers. Anyhow, keep 'em coming, Phil.

The Worst IdM Product Review Article. Ever.

A product review should...umm...review the product. Talk about the features, where it shines, where it doesn't, etc. This one in specific is just really, really bad. (I'm not saying anything against the product, just the review.) Here are a few nuggets:

The P Synch package performs the single sign-on component of identity management. The ID Synch package is primarily a web-based package that uses SSL for protecting the data during transmission.

...now that is just wrong info.

The web-based configuration of the M-Tech product suites felt intuitive and easy to understand. For example, each of the major headings in the menus reflected commonly used terms in the field of identity management.

...?

The PDF files are large and a more advanced search function could also help speed the reader’s search to find the correct passage.

...are you listening adobe?

Apologies for the sarcasm this morning.

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.

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.