Exclusive Research: Why Identity Management Is Critical Right NowBreached partners, mobility, SaaS, consumerization. If you don't know exactly who's doing what on your network, you're cruising for data loss.
Sometimes, we're our own worst enemies. A much-publicized 2007 Microsoft study showed the average employee had about seven logins to remember. Now we're piling on SaaS and mobile applications while granting trusted status and network access to partners without fully vetting their security--and just ask one CIO whose organization was breached how that worked out. Yet just 27% of the 438 business technology professionals responding to our 2011 InformationWeek
Identity Management Survey say their companies have what we consider comprehensive identity management (IdM) deployments, defined as company-wide internal IdM programs plus cross-domain use for outside vendors and partners. Adoption increases are miniscule since we last surveyed readers on IdM, in 2009.
No wonder people still use sticky notes to manage user names and passwords.
Done right, identity management employs a mix of software and processes to accomplish a single, deceptively simple, goal: make sure people are who they say they are, then give them the right levels of access. IdM encompasses five main pillars: authentication, user provisioning and deprovisioning, role mapping, setting up identity stores and directory services, and auditing and reporting. These, along with cryptographic signatures and other enabling technologies, lay the groundwork for secure interoperability among employees, customers, and partners.
In our 2009 report, the big buzz was around cross-domain federation with external suppliers, where each business acts as both an issuer and a consumer of identity credentials; the holy grail was to give users access via single sign-on to every member of the federation. Today, companies like Facebook and Twitter are advancing this concept by espousing "bring your own identity," or BYOI, which we'll dig into more later. Vendors are finally committing to standards, like OAuth. It's exciting stuff. But at the end of the day, you're still on the hook to verify that people accessing sensitive data are who they say they are. And that remains a challenge.
The yen for identity management has been around for as long as we've used role-based access control and directories. The idea of a single spot where we define our users, their roles, what they have access to, and their user name and password combinations makes a lot of sense, even to the most nontechnical executive. Everyone likes having a quick and decisive way to cut off access if you find out an employee is leaving to work for a competitor. And in theory, with this repository in place, whenever IT needs a new application, the development team could simply tap into the directory store and use the IdM system to provide authentication and authorization. Done.
One problem though: The world's messy. The ROI from identity management is directly dependent on how strictly an IT organization integrates all applications and services into its IdM program. Every single piece of software that isn't connected, or is only partially so, requires a unique set of authentication and authorization processes, and that means pricey customization. Eventually, you have gaps.
Since it's so difficult to centralize on just one identity management system, companies have looked to federation products that sit on top of disparate IdM systems and promise to provide integration. For example, with federation, you could (in theory) use Active Directory for operating system logins but employ Oracle IdM for databases.
The problem here is that identity management has to be about more than just internal logins and identities. Most companies let suppliers and contractors access sensitive data. However, when you attempt to link your federation technology to that of an external party, you can generally forget having your IdM products communicate using the same language, because of a lack of widely adopted standards.
To make matters worse, most applications and network systems still can't talk to IdM products, period: In our survey, only 18% of those enrolling cloud/SaaS application authentication in their IdM program say these applications integrate with their user directories; 49% do expensive custom development to integrate with their SaaS providers, while 44% provision user access and manage passwords manually.
Even given all this frustration, federation isn't dead--just hibernating. Within the next two years, we expect to see some stronger players, such as Ping Identity, Microsoft, and Oracle (Sun), embrace standards and pull away from the pack.
Meanwhile, of poll respondents who are skipping IdM altogether, 70% say it's because they don't see a need. No other factor even registers double digits. This suggests that vendors busily revamping, repricing, and renaming their products and hammering on low cost and ease of use are missing the point. Just 5% cite complexity, and only 4% say cost is holding them back.
Our message to at least some of that 70%: You're in denial. We understand why IT has a sour outlook on IdM, given the lack of integration and standards support. But we're now facing advanced threats while simultaneously throwing cloud services and personal devices into the mix. Profile your typical employee in terms of using Facebook, Gmail, and a variety of other Web-based applications. They likely have seven to 15 user name/password combos; meanwhile, your company is probably using or considering cloud services that, by definition, aren't playing nice with Active Directory.
To read the rest of the article,
Download the Sept. 26, 2011 issue of InformationWeek