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.