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.

Identity Management for SOA

From my soon-to-be-released MaXware whitepaper titled Identity Management in a Service Oriented Architecture:

As companies continue to deploy identity management solutions throughout 2006 and 2007, they should do so with an eye toward their enterprise SOA strategy. Organizations that implement identity management solutions will benefit most over the long term when IdM solutions are offered as a service. Companies are beginning to move toward Service Oriented Architecture models and adoption is already gaining momentum. IdM will be a critical component of SOA infrastructure securing service access to applications as well as access to the services themselves. Applications will be looking to access identity data throughout the organization over standard service protocols like DSML and SPML. MaXware is uniquely positioned to meet the current and future needs of organizations looking to build, manage and secure an SOA infrastructure.

There is certainly a significant amount of hype about SOA, but that doesn't necessarily mean that it's only hype. SOA done right has the potential to greatly reduce application integration costs, which has been an albatross for many large organizations. I expect a gradual adoption over the next few years as software vendors provide SOA hooks into their software. I don't really see companies rolling out enterprise-wide SOA infrastructure, but as more apps become service oriented, communication between platforms will become much easier to facilitate. Organizations will obviously need to consider security for the SOA infrastructure but they should also expect that Identity Management solutions (provisioning systems, identity data stores, etc) should be available as a service over standard protocols. If you're interested in the whitepaper, check our web site -- it should be available within the next few days.

SAML for Secure SOA

I've been researching Service Oriented Architecture (SOA) and came across this article on the JavaWorld site - Secure your SOA.

from the article:
"In the past, most systems were designed under the assumptions that a single system would posses all of the information necessary to make access control decisions and all the data would be recorded in the audit trail. However, large-scale distributed systems are always built by multiple organizations with a mixture of products. Thus, users may be authenticated by different authorities using different methods. In addition, different authorities retain different information about user properties and attributes. Centralizing all capabilities and information is just not practical. SAML provides standard formats to express authentication and user attributes, and the protocols to request and receive. "

With regard to service-enablement for our customers, I've been primarily focused on the ability of our Virtual Directory to enable service-based access (DSML, SPML, other) to identity data in practically any back-end format. I see this as very cool technology. Simple, but effective.

This article lays out another concept I've been thinking about, which is IdM as providing security for the SOA environment itself. That is, playing its role in locking down access to and from the services themselves. I've seen a number of articles and analyst reports that expect SOA deployments to take off throughout 2006 and 2007. Even if companies aren't ready to transform their entire infrastructure to an SOA, we can expect some degree of adoption within most large organizations.

An efficient and flexible Identity Management infrastructure is going to be critical in securing access to the SOA services themselves and their access to other systems and applications. Our Federation Server, using SAML, is an ideal candidate for enabling a secure SOA environment.

The scenario would look like this:

1. Application-A (portal) requests data from Application-B (HR System).


2. Federation Server authenticates Application-A and generates a SAML assertion.


3. Application-A forwards the assertion to Application-B, which verifies the assertion and grants or denies access to its resources based on the information in the assertion.

The scenario would work the same if it were a user attempting to access an application instead of an application-to-application interface. Or potentially, in a portal scenario, the portal requesting access on behalf of the user with multiple layers of trust. Interesting stuff.

The next step might be to add-on a provisioning environment that captures audit data on service access rights for SOA governance. I'd be curious to hear how people are implementing SOA governance. Would traditional user-provisioning systems fit the bill?

Security and Password Myths

Kaliya Hamlin pointed to an article about password security and what its author (Prof. Eugene Spafford) calls security myths. It's an interesting article, but I don't agree with the main point, which is that mandatory password changes do not increase security. He calls these policies folk wisdom and claims that best practices are "intended as a default policy for those who don’t have the necessary data or training to do a reasonable risk assessment". Well, I don't agree with that statement or Prof. Spafford's conclusion.

Best practices as I use the term describe an ideal state without knowledge of a given environment. Every environment has exceptions and special needs. Therefore, it's not always possible to implement best practices. But, they should serve as an ideal to work toward. Default policies, on the other hand, are often what's easiest to implement -- just ask any company that sells hardware for wireless home networking products. These products are usually shipped with default settings that make it easy to setup. Best practices, however, require that the installer configure encryption keys that prevent people in close proximity from accessing the network.

Let's move to the password change policies. While there are certainly (as Prof. Spafford writes) a number of password failure modes, these policies are in effect to minimize the effectiveness of one of those failure modes - cracking. We may only differ in our definitions of weak cracking. This article by Geodsoft discusses password cracking techniques. The takeaway is that with a strong password policy, a brute-force cracking attempt will take over two months at 6 characters and two years at 8 characters. It's certainly possible to improve that timeframe with heavy hardware infrfastructure, but I think the policy will serve it's purpose of reducing the threat. And that's ultimately the goal. We all know that nothing in IT is 100% secure, but we should probably implement as many practical policies and solutions as possible to reduce the potential threat.

IT Pragmatism

There's been a lot of blog discussions lately about IT practicality, software companies and enterprise architecture. It's refreshing to hear people taking a step away from large, complex and "enterprisey" architectures. I'm a pragmatist. I think IT solutions should solve a business problem and NOT introduce new ones. When I was in the services business, I tried to design and implement solutions that were simple, easy-to-use and efficient. I joined MaXware because they have very practical software products that work without complex architectural requirements. People that want to spend years to implement an IT solution seem to me to be confused - the business requirements will change drastically over those years. You need a direction and a goal to work toward, but implement quick-win real-world solutions that provide value and you'll move toward your goal while minimizing cost and frustration. I think this has been especially true of Identity Management solutions and will continue to be so for years to come. So, if you're embarking on an Identity Management journey, try to work out a 3 month cyclical pattern of building real business value while driving toward a long term goal. You'll generate executive and team support for the project by showing quick success and you'll be ready to adapt as the business landscape changes.