I’m gearing up to go to the NSTIC convened steering group meeting in Chicago next week. Naturally, my inner nerd has me reviewing the founding documents, re-reading the NSTIC docs, and combing through the by laws that have been proposed (all fo which can be found here). I am also recalling all the conversations where NSTIC has come up. One trend emerges. Many people say they think the NSTIC identity provider responsibilities are too much risk for anyone to take on. With identity breaches so common now that only targets with star power make the news, there does seem to be some logic to that. If your firm was in the business of supplying government approved identities and you got hacked then you are in even hotter water, right?
The more it rolls around in my head, the more I think the answer is: not really. Let’s think about the types of organization that would get into this line of work. One that is often cited is a mobile phone provider. Another is a website with many members. One thing these two classes of organization – and most others I hear mentioned – have in common is that they are already taking on the risk of managing and owning identities for people. They already have the burden of the consequences in the case of a breach. Would having the government seal of approval make that any less or more risky? It’s hard to say at this stage, but I’m guessing not. It could lessen the impact in one sense because some of the “blame” would rub off on the certifying entity. “Yes, we got hacked – but we were totally up to the obviously flawed standard!” If people are using those credentials in many more places since NSTIC’s ID Ecosystem ushers in this era of interoperability (cue acoustic guitar playing kumbaya), then you could say the responsibility does increase because each breach is more damage. But the flipside of that is there will be more people watching, and part of what this should do is put in place better mechanisms for users to respond to that sort of thing. I hope this will not rely on users having to see some news about the breach and change a password as we see today.
This reminds me of conversations I have with clients and prospects about single sign on in the enterprise. An analogy, in the form of a question, a co-worker came up with is a good conversation piece: would you rather have a house with many poorly locked doors or one really strongly locked door? I like it because it does capture the spirit of the issues. Getting in one of the poorly locked doors may actually get you access to one of the more secure areas of the house behind one of the better locked doors because once you’re through one you may be able to more easily move around from the inside of the house. Some argue that with many doors there’s more work for the attacker. But the problem is that also means it’s more work for the user. They may end up just leaving all the doors unlocked rather than having to carry around that heavy keychain with all those keys and remember which is which. If they had only one door, they may even be willing to carry around two keys for that one door. And the user understands better that they are risking everything by not locking that one door versus having to train them that one of the ten doors they have to deal with is more important than the others. All of this is meant to say: having lots of passwords is really just a form of security through obscurity, and the one who you end up forcing to deal with that obscurity is the user. And we’ve seen how well they choose to deal with it. So it seems to me that less is more in this case. Less doors will mean more security. Mostly because the users will be more likely to participate.
I’ve had the privilege to witness many IT funerals. By my reckoning, Mainframes, CORBA, PKI, AS400, NIS+, and countless others are all dead according to the experts. Of course, that means nearly every customer I talk with is overrun with zombies. Because these technologies are still very much alive, or at least undead, in their infrastructures. They are spending tons of money on them. They are maintaining specialized staff to deal with them. And, most importantly of all, they are still running revenue generating platforms on them. Now some of the the venerable folks speaking at CIS2012 want to count SAML among the undead. It’s a sign of the ever increasing pace of IT. SAML, if it’s dead, will be leaving a very handsome corpse. But I think it’s safe to say SAML will be with us for a very long time to come. This meme feels like another flashpoint in the tensions between thought leaders like the list of folks discussing this on twitter (myself included) and the practitioners who have to answer to all the folks in suits who just want to see their needs met. I try to split the difference. It seems to me that the only thing that makes something dead is when people are actively trying to get away from it because they are losing money on it. SAML is nowhere near that. But if dead is defined as not being a destination but rather a landmark in a receding landscape, then maybe it has died. But it’s chasing after us hungry for our budgets and offering being impervious to pain as a trade for that funding, which sounds like some kind of zombie to me. Using SAML will make you impervious to the pain of being so far ahead of the curve there is no good vendor support, impervious to the pain that there are not enough people with talent in your platform that you can’t get things done – or have to pay so much to get things done you may as well not do them, and impervious to the pain of being unable to get what you need done because there aren’t enough working examples of how to do it. Based on what i hear from practitioners, they may like being impervious to all those pains. So the IT zombie legions grow…
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.