Identity Services Drill Down

In my last post, I presented an overview illustration of Enterprise Identity Services. Here I'll drill down into each layer to provide some further explanation. For each layer, I'll present an overview, its interactions with other layers, current implementation landscape and emerging technologies.

Identity Services

The Identity Services industry has used many terms to describe the overall umbrella under which all (or most) of its products and services fit. Among them are Directory Services, Identity Management, and Identity & Access Management with Identity Management being the most widely used term. Since Identity Management has come to be used in many cases specifically for user provisioning and delegated admin... And since an identity platform typically provides a service out to the larger organization... And since the larger IT industry is moving toward a software-as-services model... it makes sense to me that we start using the phrase Identity Services to describe the umbrella under which our products and services fit.

The Identity Services layers are:

• Access and Policy Services
• User Services
• Identity Data Services
• Data Storage Services

Access and Policy Services

This is the layer at which policies and access permissions are enforced. As people attempt to access resources throughout an organization, this layer grants or denies access based on user identity information and access policies.

The Access and Policy services layer relies upon the identity data services and data storage layers to provide accurate and up-to-date information about users, rights and policies. The user services layer relies upon this layer to control access to its own services.

Commonly found in this layer are Web SSO and Enterprise SSO applications. But implementations vary widely. In the past, access management was handled individually by each individual application. It was difficult to manage and control. The ideal future-state scenario is to have a single centralized enterprise access control platform that every application would leverage. Most organizations today that have already begun to offer identity services are somewhere in the middle.

Emerging technologies in this layer include federation products and standards, network-based access control, user-centric solutions and standardized policy management infrastructures (XACML).

User Services

User services include software and services that enable business efficiency and functionality. Generally, services at this layer are driven by user interaction. Managers manage their employees, grant and deny access, perform attestation duties and run audit reports. System users manage their own information, reset and recover passwords and request access permissions.

The user services layer relies upon the access and policy layer to ensure that people can only perform operations to which they're entitled. It relies on the identity data services layer to achieve the proper view of the data it needs to act upon. And it obviously relies on the data storage layer to store the results of operations performed at this layer.

Typical applications found in this layer include user provisioning and deprovisioning systems, password reset and recovery applications, access management tools and audit reporting. The majority of traditional Identity Management and Identity Services projects and discussions are based in this layer.

Technology emerging in this layer includes advanced attestation reporting, improvements to provisioning, workflow, self-service and password management services and web service enablement.

Identity Data Services

The identity data services layer provides vital services to the overall identity services infrastructure. At the top two layers (access & policy services and user services), systems interact with data that resides on the data storage layer. Each system and application has its own set of requirements and its own data needs. This presents a great challenge for organizations implementing identity services. Identity data is spread out across organizations in network OS and email systems, HR systems, application databases, identity-specific directories and more. This layer provides identity services and applications access to those heterogeneous and disparate data stores in an organized and controlled manner.

The identity data services layer relies upon the access & policy layer to present valid credentials for the user, service or application requesting data access. It presents data out to the access & policy and user services layers but its primary interaction is with the data storage layer where its job is to act as a librarian of sorts. It catalogs identities across systems, joins accounts in multiple systems and presents the data in the format and structure requested by its consumer.

Metadirectories and data synchronization tools have traditionally ruled this layer. Many companies have made progress in identifying identity data throughout their organization and using synchronization products to create reliable sources for identity. Some companies create an enterprise directory that stores a common attribute set that is available to the identity services infrastructure for consumption. Others use synch tools to maintain the existing data stores. Typically, though, there are challenges associated with allowing applications and services to directly access your organizations data stores. Enter Virtual Directory technology. Virtual directories have been steadily proving their worth and will likely emerge as the dominant technology in the identity data services layer. A virtual directory can present a virtualized view of identity data out to the identity services infrastructure for consumption. The view can be customized based on the user or application making the request and can be transformed into multiple formats as appropriate for each consumption point.

Emerging technologies at the identity data services layer includes additional built-in connectors for meta- and virtual directories as well as adoption of emerging protocols and standards.

Data Storage Services

The data storage services layer is the simplest to understand. Organizations have had this layer in place for years. This layer holds the databases, directories and other data storage systems that hold identity data throughout the organization. Typically, there are many different types, structures and sizes of identity data stores in a single enterprise.

The data storage services layer may interact with each of the other layers to provide identity data as appropriate. In some cases, the data storage layer is masked by the identity data services layer so that the upper two layers do not directly interact with the data storage layer.

This layer is by far the most mature in terms of technology and adoption. LDAP directories and relational databases have proven their usefulness and are well understood amongst IT professionals. The implementations are as plentiful as the organizations that rely upon them.

Emerging technologies in this area include the adoption of new data storage standards, data virtualization (not to be confused with virtual directories), improved security & encryption and general feature & functionality improvements.

Enterprise Identity Services

A few months ago, I generated this view of the enterprise identity services landscape. The main goal of identity and access management solutions within an enterprise is to manage users' and applications' access and interactions with corporate assets.

There are a number of service layers that comprise the overall identity infrastructure that enable, restrict and audit this access. Each layer may be comprised of multiple technologies. As I've written in the past, Identity solutions will be implemented as services as we move into the future. Each layer should be built on open protocols that facilitate easy communication across layers. Companies should store and manage data in whatever format they're most comfortable. And employees should be empowered to perform their job functions without technical restrictions.

The layers of enterprise Identity Services as I see them are:

• Access and Policy Services
• User Services
• Identity Data Services
• Data Storage Services

Note: updated 7/25 with some minor enhancements

Network Layer Identity Management: Part II

I recently posted an entry about Identity Management in the Network Layer. I wanted to follow-up with some ideas about how MaXware can help companies looking to achieve access management at the network layer.

Deploying access management requires an identity store containing user and access rights information. Solutions like the one from Trusted Network Technologies can use an internal store or leverage an existing store such as Active Directory. The process of designing and creating this store is obviously going to be a big task. Based on roles, policies and other security constructs, data will need to be structured, organized, cleansed, aggregated and integrated. For many organizations, a single Active Directory will not hold the entire universe of network users. There are non-employee business associates, partners, customers, disconnected business units, recently acquired companies, etc..

MaXware Virtual Directory (MVD) can serve as an abstraction layer for this identity and authorization data. MVD can provide the access control software with a single place to look for identity and permission data. MVD can present the data as an LDAP hierarchy or in any other preferred format. Identity and access data can continue to live and be managed in its proper location regardless of format. And if you'd prefer to leverage or build an LDAP directory to hold the identity and authorization data, you may need to synchronize data into that store on regular intervals. MaXware Data Synchronization Engine (DSE) provides a robust and easy-to-implement solution for synchronizing data to and from virtually any type of repository.

Identity Management Architecture Interoperability

Neil Macehiter of MWD published a document a in May 2006 titled What drives identity management requirements. It's available on the MWD website (with registration) and worth the read. He states:

Enterprises need more than a rich portfolio of identity management functionality; they need an architectural approach which promotes interoperability.

Very true.

One of the on-going trends in IT is a move toward service-based architecture. The introductory rise of software-as-a-service has already taken place. As new applications are rolled out into organizations, IT managers are keeping on eye on making the platform open and interoperable. I've seen this in Identity Management projects. The people implementing IdM within an organization are doing so as a service to the larger organization. Systems and applications throughout the organization need to be able to interoperate with the IdM infrastructure to grant and deny access, verify privileges, create accounts and more. The main point of the paper seems to be that an IdM infrastructure ought to be built with a clear architectural approach that meets these increasingly more prevalent requirements.

I see this as another important reason why businesses should be including a Virtual Directory as part of their IdM infrastructure. Adding a virtual directory into the solution immediately improves the solution's ability to be flexible and interoperable. Virtual directories enable organizations to make their identity data:

• As open and available as the organization wants it to be
• Accessible with a completely flexible and dynamic organizational structure that can be customized for each application that is accessing the data
• Accessible via LDAP or virtually any other data structure
• Accessible as a web service via DSML, SPML or other protocols
• Available in real-time to applications across the organization regardless of protocol on the back-end data store

Plus:

• The organization can continue to manage identity data in its preferred system and format
• There's no need for multiple repositories to support multiple sets of application requirements
• There is virtually unlimited flexibility in how data could be presented

Virtual directory as an abstraction layer eliminates much of the complexity associated with getting the other IdM components connected appropriately to the data stores. IdM services like provisioning, federation, authentication and access control can leverage a single point of contact to an organization's identity data.

The document provides a blueprint for next generation IdM architecture. And it's a blueprint that makes sense.

Network Layer Identity Management: Part I

Mark Macauley of Trusted Network Technologies has been making the case for Network Layer identity management. It's a very compelling concept. Eric Norlin of DIDW has also posted about NAC - and more than once. Eric sees NAC as front-and-center, one of the major IdM themes for 2006 and possibly the new provisioning. Another TNT blog makes the distinction between Network Access Control and Network Admission Control. It's an important distinction. I was recently at a trade show standing across from a large banner that read Network Access Control. When I inquired, I was given the spiel on what is really Network Admission Control (by Eric's definition). For that company, the distinction really doesn't matter - access to the network vs. admission to the network... who cares? They both sound the same. For TNT, it matters because they provide much more than just binary access to the network. For my purposes, I mean access control. That is, NAC as controlling who has access to what at the network layer rather than at the application layer.

Placing security at the network layer seems to be more secure than at the application layer. The goalie (for lack of a better analogy) wouldn't have to protect the goal if opposing players weren't even allowed on the field. And users who plug a non-compliant laptop into the network have no chance of reaching protected data. You need to be attempting access from a NAC-approved system in order to have any chance of gaining access to the requested resource.

There are still plenty of finer technical points (is packet spoofing possible?, etc.) about NAC that I don't fully understand, but I do see some business challenges. Assuming a NAC implementation works exactly as I would want it and there are no technical concerns, I still think there are some business-related hurdles to overcome before widespread adoption of network layer access control would take place.

1. From what I've seen, the IT industry has moved away from installation of agents on desktops and laptops. So, the carrot needs to be very sweet in order to convince IT managers that agents are the way to go. Complete enterprise single sign on and elimination of all user names and passwords other than the network is a pretty sweet carrot -- we're talking Carrot Halwa. But, is that really achievable? I have no experience with this so I'm actually asking. Have people achieved this?

2. Companies are comfortable with the idea of controlling access at the application layer. Applications have user names and passwords and identity stores and policies that control who can get in. Turning all of that off for every application across the enterprise is a very tall order. I believe it would take a significant amount of time to convince organizations that it's safe to open all the safes in the mansion and take comfort that only those with appropriate permissions to a particular safe will be able to get into the rooms with that safe. It may be purely an emotional obstacle, but one nonetheless. It's just the kind of obstacle that could prevent a very good technology from ever reaching widespread adoption. If I were a NAC vendor, I think I'd spend a huge portion of my time and budget attacking this fear. Find a single high-profile customer, give away the software and make the case. ...just an idea.

3. In the long-term, if organizations do begin to adopt a NAC identity management architecture, NAC vendors will need to either pair-up with the major platform vendors or prepare for a long hard fight. Building identity into network requests and responses could eventually become part of the network OS, desktop OS and server applications. Of course, no single vendor could solve the entire problem without some common standards. I think I smell a new set of protocols out on the horizon waiting to come to fruition as soon as customers get over the fears mentioned above.

...in part II, I'll discuss how I think application-layer identity management solutions (like MaXware's) add value to network layer access management solutions.

* Thanks again to Mark Macauley (who may or may not agree with my thoughts) for providing me some background info on TNT.

Business Value of the Identity Metasystem

For as many years as I can remember, I've been handing out this little pearl of wisdom:

The secret to life is perspective.

The main point, of course, is that ultimate happiness (life's true goal) is easily achieved - if not by accomplishing some measurable goal then by re-evaluating one's perception and understanding of the goal and making adjustments as necessary. I'm not saying it's OK to set the bar lower in order to make goals reachable. I'm saying that often what we perceive to be an important and worthy goal does not hold up under closer scrutiny. And a realignment of the importance of things will often help you see the positive aspects of a situation as outweighing the negative. I'm certain that I wasn't the first to achieve this realization, but I arrived at it when I was young and its truth has been consistently reinforced as I navigate through life.

How does it relate to identity management?

Well, it's analogous to the concept of context-based identity. Woven throughout the fabric of the Identity Management blogosphere is the notion of user-centric identity, the concept of context-based identity and the questions of who owns identity and what defines a system user's identity. In the real world, identity is contextual -- Your identity differs depending on the perspective of the viewer. Sometimes it's because you intended to shape that perspective but other times it's the viewer or the situation itself that shapes the light in which your identity is cast.

People necessarily present some unique subset of our overall identity superset each time we interact with the world. Even those we most love and trust will see only partial aspects of our identity. We don't expose our Las Vegas selves to our children. And we may not expose our caring, nurturing side at our monthly poker game. We all have friends to whom we expose aspects of our identity that we don't expose to others. Do you share your Star Trek convention identity with the people you work with? Or your girls-night-out identity with your local bank teller? Identity is extremely driven by context and perspective.

This is even more true in the world of systems and applications. Our electronic identity, as it's used in practice, is another small subset of your total identity. Often, your identity for any given application consists of authentication credentials and some application-specific identity information. The context boundary seems most often to be at the application but may also be driven by access method (phone vs. Web), geography (home vs. at work) or some other factor. The real problem that we (the Identity Management community) are trying to solve is: how to effectively and efficiently deliver the appropriate identity context to wherever it's needed in order to enable secure and easy interactions between people and computers (or any combination thereof).

So when the question of User-Centric identity comes up, I wonder about how any one entity could hold all (or even most) of its own identity information. Identity, being subject to perspective, is only half-owned by the one being identified. The other half is owned by the viewer of the identity and/or the situational context. Young children see their parents as super heros. Most of those parents (I realize not all) wouldn't hold super hero to be part of their identity if they were holding all the cards. The child needs to maintain some aspect of the parent's identity. In the same way, a financial services company defines and re-defines a customer's profile based on the customer's progress, the company's special knowledge and the performance of the economy. Surely, a consumer can not own those aspects of their own identity. So what are we really talking about when we discuss user-centric identity? Authentication? Authentication plus some basic profile information (age, citizenship, contact info)? Something more?

Bob Blakley recent posted a blog entry titled The Meta-Identity System in which he makes the case for Identity Oracles rather than Identity Providers. His points are important. In fact, it hadn't even occurred to me that anyone would choose to implement an identity provider that actually sends identity data rather than identity metadata. Bob's point is that identity providers in the Identity Metasystem ought to provide answers to basic questions rather than shipping real identity information. e.g. Am I over 21? rather than What is my birth date? But this information still seems very generic. The receiving application will still own relatively half of the user's identity (as regards to the user's interaction with this particular system). The user really only owns the portion of her identity that is non-specific to the application (or not context-restrained).

So is this entire user-centricity effort really about minimizing the effort to enroll in various sites by duplicating name, email, address and credit card? To make this huge undertaking worthwhile, I believe there needs to be more value to it. If it's only to simplify enrollment and authentication, then it's really just Microsoft Passport 2.0 but with your own choice of identity provider. Is simplified enrollment and authentication really the goal of user-centric identity solutions?

I realize that the concept that identity is contextual is not new -- it's even part of the original identity metasystem concept. And the metasystem also acknowledges that existing identity systems are not replaced by the metasystem -- they still own part of the identity. So, it's not asking us to give the entire identity to the user. I just want to be clear about what we stand to gain. Is it:

• Fewer sets of credentials for users to manage?
• Consistent user experience? (Are enrollment and authentication activities really confusing people with complex interfaces?)
• Greater degree of user control over their identity? (really?)
• Facilitate use of existing identities across boundaries? (like federation?)
• New market opportunities? (examples?)

It sounds a lot like an authority-neutral Microsoft Passport. I'm unfortunately somewhat behind the eight ball on user-centric identity. From my perspective, it's been a debate about how to build the next generation Internet identity infrastructure and I've been pretty focused on the current generation. But I'm starting to give it some thought. I'm playing catch-up and I'm wondering: What am I not getting? Am I just underestimating the frustration associated with multiple sets of credentials? Maybe it's because I use a Digital Persona system don't worry much about multiple usernames and passwords. Enlighten me. What will drive the world to invest in an identity metasystem?

Don't get me wrong. I do get it to some degree. I realize the Internet experience will be better for everyone if we tackle the issue of the many identifiers that connect us one-by-one into systems and applications. I just don't know if I've seen a business driver that's big enough to drive an effort as big as a global identity metasystem. So clue me in. Is it just about making the world a better place? If so, this is a bigger story than I suspected.

Beyond Simple Federation

One of the typical scenarios we've encountered when discussing our federation solutions with customers includes dynamic account provisioning. A number of people at Network World in Chicago last week were asking me about this capability, so here's an overview:

Typical federation scenarios include a person attempting to access an application that lives outside of the security domain in which the person is currently authenticated. This is achieved by authenticating the user within the current security domain and passing an assertion to the requested application stating that the user is authenticated (and providing the user's identity information). This assumes that an account has been created in the foreign application for the user. The process of creating and managing accounts for this purpose is typically a manual process due to the distributed environment. Whether manual or not, the process that's in place usually kicks off whenever a new employee account is created within the originating security domain and ultimately concludes with an account being created in the external environment in a ready state - waiting for the user to come along at some later date and logon. Apparently, there are a number of possible reasons why you might not want accounts created for system users who may only potentially access an external application.

MaXware's Federation Server (MFS) is built on top of our Virtual Directory product (MVD). MVD enables account authentication to one or more heterogeneous back-end data stores. It also enables account creation to one or more heterogeneous back-end data stores. So, one of the scenarios we've implemented for a customer in the past (and will likely again sometime soon) includes on-demand federated account provisioning. In this scenario, the user is authenticated in their home environment and an assertion is sent to the external application environment. MFS on the application side leverages its internal MVD to dynamically create an account in the requested application. And to take it a step further, MFS actually opens a session on behalf of the user so that when the user is redirected to the application, there is no need to logon again. So, it also serves as a distributed SSO environment. But, that was the original point of federation, wasn't it? Pretty cool stuff. You don't have to worry about orphaned accounts if they don't get created in the first place. On-demand federated account provisioning -- the next big thing? Maybe not, but it's good to know that it's there if you need it.