Chief Identity Officer?

My colleague Matt P. recently introduced the concept of a Chief Identity Officer (CIdO) and a related Identity Management department. It's an interesting question -- who owns enterprise user identities? He's not asking who actually owns them now, but rather who should. If a CIdO presided over a department of IdM, which included HR, what would that mean for identity security and enterprise identity management? Well, I agree with Matt that one owner would certainly make IdM projects easier to manage, but that's not the greatest benefit.

I would think the CIdO would need responsibility for all user identities -- employees, partners, customers, etc.. She would find ways to enable the business while mandating the IT organization to implement solutions that follow strict security guidelines. All applications requiring user interaction would need to work through the CIdO office to get user enabled. In the real world, this seems like a long shot, but introducing the concept may provide a wake-up call to organizations with no executive sponsorship of user identities (and they do exist). I guess my vision would include a Director of Identity that reports to the CIO or equivalent. She would be responsible for compliance, attestation requirements, establishing Identity policies, ownership of IdM solutions, backup and recovery solutions for identity-enabled applications, etc..

Having a single office responsible for identity in an organization would yield numerous benefits. First, the people responsible for email systems, network OS, perimeter security, HR employee solutions, application development and others would be able to concentrate on their own responsibilities. Second, somebody would be 100% focused on how to provide the best identity solutions to the business while maintaining the highest standards of security. It's natural, for example, for application owners to make decisions that will enable their app users while diminishing audit capabilities. A director of IdM wouldn't think in those terms - she would need to find solutions that enable the business, facilitate ease-of-use and also maintain strict security guidelines. IdM solutions span the enterprise and the design, architecture and management thereof ought to be central. We've all heard the cliche - a chain is only as strong as it's weakest link. Well, if identity solutions are managed by strict policies from a single office, perhaps we would be less likely to lose a laptop holding the identity information of 250,000 people. In fact, we'd be less likely to have a laptop with important identity information at all. Less total links means less weak links in the chain. And to beat the analogy to death, a Director of IdM would mean somebody is there with a welding torch maintaining the chain and designing improvements rather than each group owning their own link. Something to think about. ...especially if you're one of those organizations with no executive IdM oversight.

Whodentity? Tor Who.

Mark Dixon posted a blog entry announcing a page called Whodentity? on which he lists a number of people who are influential Identity Management characters. In his blog entry, he mentioned Eric Norlin's Top 10 most important people in Identity and asks was he correct? I think the answer will (and should) vary depending on your perspective. For example:

• For Identity Management solution implementers, I can't think of anyone who has provided more valuable information than Mark Dixon himself. His blog series on IdM Implementation Risks is well worth the price of admission alone and should be required reading for anybody planning an IdM project. I think we're still waiting for full entries on the final two risks (no pressure Mark).


• If you're a product manager thinking about what features to next build into your IdM products, you might look to Microsoft's Kim Cameron for food-for-thought about the future of Identity technologies.


• If you're an enterprise IT manager and need to understand what products are out there and how they might help your organization, you might turn to Dave Kearns or Digital ID World's Phil Becker & Eric Norlin.

So I think every person's top ten may be different, depending on what information they need. Mark's post inspired me to re-read the Top 10 and I saw in the number one spot Jamie Lewis of Burton Group. No doubt that Jamie has contributed a great deal to the industry. The text states that he wrote the original white paper outlining the concept of a metadirectory and that the white paper "essentially gave birth to the identity industry". This may be true, but it got me thinking. My research tells me that the Burton paper came out in 1996 shortly before the ZoomIt metadirectory product, which was also released in 1996 and later became Microsoft Metadirectory Server. And so we can conclude that people building Identity Management expertise in 1996 are considered innovators and should be praised for their foresight.

And so with that background, I'd like to contribute another name to the discussion - MaXware's own Tor Even Dahl. Tor Even wrote what I believe to be the world's first metadirectory product in 1995. That product remains to this date at the core of our data synchronization and provisioning products. And although it's architecture was different than what ZoomIt was building around the same time, Microsoft re-built MIIS to have a similar architecture when they started from scratch in 2002 - which only proves that that the architecture has withstood the test of time. Tor Even went on to write the world's first virtual directory product in 1998 (then called an LDAP proxy). So, here's a guy who wrote both the first metadirectory and the first virtual directory but has no real industy recognition. He probably likes it that way. Like many Norwegians, Tor Even is humble and he'll probably cringe to see his name mentioned like this, so let me apologize in advance (Sorry Tor Even). But, I thought his accomplishments worth mentioning to the larger community.

With the help of a few other people, Tor Even Dahl built one of the first pure-play Identity Management companies and today remains the CTO of a successful IdM company that has over 300 customers in 30 countries around the globe. So, here's a toast to Tor Even Dahl, as they say in Norway, "Skal!"

...and thanks Mark for Whodentity? It's a list that is sure to provide many interesting viewpoints.

MaXware News

The whitepaper I mentioned previously, Identity Management in a Service Oriented Architecture (SOA) is now available on the MaXware website.

Also, MaXware is offering a lite version of its Data Synchronization Engine free of charge through July 31, 2006. DSE Lite is a great way for organizations to build real value while getting familiar with MaXware products. It provides a flexible data synchronization solution for bi-directional sync between any two data repositories. There is also a comparison between DSE Lite and the full version of DSE.

Lastly, MaXware just released a new version of the MaXware Virtual Directory with many upgrades, including built-in connectors for SAP and Salesforce.com. These connectors enable querying and account provisioning to/from these systems over standard protocols (LDAP, SPML, DSML, etc.). Kudos to the MVD development team for a very nice release!

Password Solutions

One of the primary business drivers for Identity Management has always been password management. System users don't want to remember multiple passwords -- especially if the systems require password changes on different cycles and have varying policies for password length and structure. The frustration is more than understandable. And we've all seen the reports that state the cost associated to that frustration. Password-related Help Desk calls cost $x per call and x number of calls each year per each thousand users equals the enormous cost of managing passwords. I didn't even mention the security implications of having too many passwords.

What we haven't heard often is that there are a number of possible solutions to this problem. We may have heard each of these solutions individually, but usually from a single perspective. I believe that technology infrastructures are complex and dynamic. They're not one-size-fits-all. Every enterprise has a unique environment and somebody needs to (or at least ought to) put forth some actual thought about how to best approach any given environment. So, with that, here are four approaches to the problem of passwords. They are not mutually exclusive and depending on the size of an organization, it might make sense to look at more than one of these approaches.

1. Password Management (Reduced Sign On)
These solutions synchronize passwords across multiple systems. They enforce strong passwords that adhere to the policies of each of the connected systems and remember password histories so that people can't repeatedly use the same password. One of the nicest features of password management solutions is that they allow end-users to recover lost or forgotten passwords through some type of self-service mechanism. This cuts the helpdesk costs and leads to real ROI. System users are left with multiple user accounts which have a common password.

2. Centralized Authentication Infrastructure (Single Sign On)
These are the typical SSO solutions that leverage some type of access policy server. The SSO system identifies a user and determines whether or not to grant access to the requested resource. SSO vendors typically leverage LDAP to authenticate users against an enterprise LDAP directory. If an organization prefers to manage data in a relational database, the SSO system can send LDAP requests to a Virtual Directory which would then pass the request to a back-end database (or any other set of data stores). SSO solutions centralize authentication to a single account and enable management of permissions to access enterprise resources. On the back-end, these systems require access to an authoritative identity data store and therefore usually require either some form of identity data synchronization or a virtual directory implementation (as previously mentioned). One example of multiple back-end data sources is leveraging Active Directory for employees and an Oracle database for non-employees.

3. Single Authentication Source
In this scenario, an organization would forgo the expense and infrastructure of implementing an SSO environment, but would implement a single authentication source with varying authentication mechanisms and logic for each application. If there are a limited number of applications, the value of a true SSO implementation may not be fully realizable. Each application in this scenario would verify credentials against a Directory or Virtual Directory server. Just like in the SSO scenario, a Virtual Directory would enable lookups to one or more data sources on the back-end. This allows the organization to leverage a single set of credentials for authentication to multiple applications.

4. Enterprise Single Sign On (ESSO)
ESSO solutions reside on an enterprise network and manage user access to various resources. The user experience is pleasant because there is only a single point of authentication. Each application maintains its own set of credentials, but the ESSO solution maps user accounts for each system and performs the authentication process on behalf of the end user. Some things to consider are application password change policies and how access from external locations would be handled. The user still has multiple system accounts each with its own password, but the logon process is made transparent by the ESSO solution.

Federation solutions offer another way to handle authentication across multiple systems and may be able to provide an additional solution to password challenges. However, federation solutions are typically implemented for authentication across security domains whereas passwords are typically managed within a given security domain. User-centric identity solutions are another way to approach access across multiple security domains. Ultimately, organizations should consider the alternatives and implement solutions that will provide value within their own given environment based on their own specific requirements.