Showing posts with label idaas. Show all posts
Showing posts with label idaas. Show all posts

Wednesday, September 02, 2009

Identity Services, SaaS, and Another Matt

Matt Gardiner over at the CA blog makes some interest points regarding identity services and SaaS. (I'm a new reader of Matt's blog, and want to personally thank him for adding yet another Matt to the list of identity bloggers I have to keep up with. What's up with identity bloggers and the name 'Matt' anyhoo?)

Matt questions the value/feasibility of providing identity services in a Software-as-a-Service format, since there's a difference between apps and infrastructure. Infrastructure, he argues, must be "appropriately integrated into the enterprise premises and processes". He continues to argue that identity services in a SaaS format can't ignore on-premise apps in favor of identities in the cloud, and mentions the traditional concerns around "outsourcing" compliance and security.

Ironically, I had an interesting conversation just yesterday with an industry colleague regarding the exact issues mentioned by Matt, where he presented some new emerging paradigms in the 'Identity as a Service' world, including what he dubbed "Enterprise Looking In" and "Enterprise Looking Out" (more on this in future posts). Here are a few questions/direction for the conversation (more questions than direction)...

  • Let's nail down the definition of 'identity services'. If not for the industry at large, at least for this conversation at hand. In my opinion, a lot hinges on that.
  • Is the notion of 'Identity Services' in a SaaS format an either-or paradigm for on- and off-premise apps?
  • Can technology help blur the internal vs. external line? Does this lead to a new category of infrastructure?
Matt does acknowledge that he sees the opportunity for some areas of identity to be outsourced. Perhaps this conversation could help clarify what areas in specific...

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.