I sat down with a very smart group of folks and they were saying how they think SSO is very, very hard. If your world is all Active Directory (AD), it’s easy. But that is true in a tiny percent of the world. Everywhere there is some odd ball application and in most places there are just as many applications not using AD as there are using it (even if they buy Quest solutions, sadly). The cloud, something everyone is forced to mention in every tech blog post, also complicates this. How do you do SSO when the identities aren’t under your control? Or, reverse that, how do you get SSO from your cloud vendor when your on premise applications aren’t under their control? But every time I have the SSO conversation at length with people the conclusion is always the same. If all you have are applications from the last 10 years and some cloud stuff, there are approaches, including Quest’s, that can fully solve that problem. You can integrate into your commodity AD authentication, put up SSO portals, or use widely adopted standards like SAML – or all of the above in a clever combination. Even thick client GUI applications can be tamed with enterprise SSO (ESSO) solutions at the desktop. The things that always end up falling through all the cracks are older applications. Things that are often the crown jewels of the business. Applications that are so old because they are so critical that no one can touch them without huge impact to the business. But the older technologies resist almost every attempt to bring them under control. Even ESSO, which is the catch all for so many other laggards, can’t tame many of the odd green screens, complex multi field authentications, or other odd things that some of these applications demand at the login event. When I’ve spoken to our SSO customers, they always seem happy with 70-80% adoption on their SSO projects. They know they will never get that last group until the applications change. But there doesn’t seem to be any compelling event for those applications to be changed. So SSO continues to seem hard, but we all know that’s not exactly true.
Many are talking about a surprising move by Microsoft, buying Sentillion. The press release doesn’t say it all, that’s for sure. My esteemed colleague, Mr. Shaw, asks some very interesting questions. I think some of the answers are right there in the discussions. More of the tweets I’ve seen so far (as of 2:30pm EST on 12/10/2009) use terms like Microsoft buys a “Healthcare Software” company. And, as @jacksonshaw points out, the acquisition was driven from the haelthcare division at Microsoft. It is entirely possible that the FIM team found out exactly when we did. I doubt this because I’ve always seen Microsoft as being a bit better at internal communications than most vendors their size, but things like that are very common in very large companies.
Also very common in larger firms are duplicate offerings across different business units. And so maybe having more than one provisioning offering is not going to be as painful as it may seem at first blush. After all, how many forms of HR application does Oracle sell right now? And that’s a core piece of corporate plumbing, not just an IT infrastructure component.
I’ve never seen Sentillion outside the healthcare niche, though I’m sure they are to some degree. They always posed the biggest threat when context management (in the CCOW sense) was a big part of the requirements. Most of these healthcare RFPs I’ve seen have been more about context than SSO. So it seems to make sense to me that the healthcare folks at Microsoft would want this in their bag as a way to capture more of their clients’ attention and budget.
My bet is that this is going to stay very healthcare focused – simply due to resources required for transition. Focus is a struggle during any transition. Adding another business unit (IDA) into the mix would be asking for trouble.
And, to finally arrive at the point in the title, the WIF focus has all been on federation. There is a definite tension between ESSO and federation. If you have the problems handled with ESSO, why spend the money and time on getting applications federation ready? So there is likely some tension there that will need some thinking through before making any attempt to glue these offerings together. Though I’d like to be a fly on the wall when someone asks Microsoft if they would support a WIF federation approach or an ESSO approach for a mid sized company if both reps with Sentillion and WIF in their bags are in the same room. That would be a fun few moments of silence…
lots of talk about sso and authN at TEC 2009. what fascinates me is how many people are espousing the merits of having completely different credentials for many systems. they all claim that the reason is security (at least all of them that i have heard). one of our senior products folks has an analogy they use that i like to discuss this. he will ask, if you were building a house would you want 8 weak doors or one strong one? and i think that really gets to the heart of the security issue.
but even if you grant that perhaps many credentials could potentially be stronger than one, the question becomes what is the trade off? basically, we’ve been working de facto under the multiple credential world for the whole open systems era and no one thinks we’re in a good security state. i would submit it’s because of all the other issues that come from many credentials like more to manage and burden on the users. so i’d ask if there is really a way to get rid of the burden on the users and maintenance issues? some say synchronize, but then you have one door again (or at least one key that works on all the doors). and now you have extra infrastructure on top of what you already have.
sso and AD briding has a role. so does sync. but whatever the stuff that powers this stuff, sso seems like it will always be the one strong door when it’s done right. what do you think?