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 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.
Overall, the conversations at RSA have been more focused this year than last. Most people came asking project focused questions. The most popular was two factor, of course. Many asked about auditing, some about SSO and the rest asked about controlling directory content and delegation for SoD. So I’ve been talking a lot about Defender, InTrust, Authentication Services and ActiveRoles Server, respectively. It also seems like there are more senior people here this year. Many titles with director, VP and executive in them are speaking to us. I think it’s a sign of how much more seriously identity and security are being taken now.
The biggest a-ha moment for me so far was sitting in the IDC breakfast yesterday. Sally Hudson from IDC was talking about the penetration of identity and access management technologies into applications. She mentioned how most of the technologies, SSO, TFA, etc, were not new but were only now starting to become part of the majority of applications. What occurred to me was only now is identity technology getting to the point where applications can easily consume its services. Pieces that are easy to use have great penetration, which accounts for the success of LDAP and products like Site Minder. But for more advanced identity that incorporates federation capabilities, provisioning integration, fine grained access control and other advanced functions, it’s only now that we’re seeing technologies deliver. And it’s not that applications don’t do these things now. Applications that need to federate do, applications that need access control have it. Those services are built on demand and typically without COTS help, though. With the rise of standards and the maturity of application ready toolkits and protocols, now the application teams themselves and business groups they aim to please are thinking about these things as features they would like to have for any application not just stuff with identified, immediate needs. My experience is that when the applications want it, that’s when the market is real. That time may have finally come.
Another cool thing for me was meeting some of our partners face to face. Especially cool was getting a new visual aid from our friends at NagraID Security. I’ve been pushing the idea of multi-function multi-facto devices for a long time. Now I have a working one to use as a visual aid in meetings. It has a smart card chip, OTP capabilities by pressing a button on the front, a picture printed and two different scan spots (barcode and box). I can’t wait to break it out in my next meeting with a client. I’ve already been showing it off on the show floor.
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…
last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.
everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.
wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…
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?