by Fernando Gebara Filho

Summary: The purpose of this article is to show thereaders how digital identities are evolving over time, from the needs of asingle user running within a single computing platform to today’s world ofmultiplatform identity federation and privacy concerns. It can be used to helpinfrastructure architects design effective identity infrastructures that arenot over-engineered, but instead based on current and projected needs of theorganization.

Contents

A (Very) Brief (and Simplified) History of Identities
A Nontechnical View of the Digital-Identity Anatomy
The Managed and the Unmanaged User Spaces
Competencies, Commoditization, and Real Value
The Challenges of Identity Strategies
Conclusion

There was a time when very few people needed a digital identity.They were specialized workers in a brand new profession, nowadays known asInformation Technology (IT). They used a very limited set of devices, accessinga very limited set of applications. There was no online access; the only way tomake the machines understand what to do was to feed them tremendous quantitiesof punched cards, loaded with machine-like language constructs. There were veryfew bad guys those days; the worst were the ones who hustled you, so that allof those carefully ordered punched cards were spread out over the floor.

This is not the reality today. We live in a globally connectedworld; the vast majority of people who use the technologies that once werereserved for scientists and hardcore engineers are now lay users—with little tono understanding of all of the processes that are running inside theircomputers. There are unknown numbers of very bad guys who want to spy on you inorder to determine your password to your banking account, so that they are freeto steal from you without the need for proximity. These malicious users canlive far way from our homes, but it takes just a few seconds for them to trackall of our activities. Some of them don’t even want our passwords; they want tosteal our home-processing power to run complex hacking algorithms ordistributed attacks to carefully chosen targets in the Internet. And, so,computer programmers must constantly work on digital-identity technologies inorder to handle all of those changing landscapes.

A (Very) Brief (and Simplified) History of Identities

In the beginning...

… there was almost no interest in creating and managingidentities and their security contexts. Why? We lived in a world of mainframesand mini-computers, submitting huge computational jobs through punched cardsand printing stacks and stacks of paper on mechanical printers (but only if wewere IT professionals or attending University classes at that time). Ouridentity was nothing more than an identifier, determining who submitted the joband who owned that big amount of paper (usually, printed on the first page ofthe paper stack).

There was no security context at all in our identities. The username/password pair was even printed in the punched card set, so that there wasabsolutely no secrecy involved. However, there was no need for it, especiallyin the commercial/academic world; except for a few individuals, there was nointerest in stealing other people’s jobs (JCL jobs, that is). The onlynecessary secrets were in the realm of military installations. Identities wereused only in the context of a single machine. If you wanted to use anothercomputer, another user name/password pair had to be created, and there was noconnection among the identities in the machines that you were allowed to use.

Basically, identities were not used to really identify you. Theironly purpose was to generate an identity under which a process was run and theresults could be sent to you. There was a very weak connection between you andyour digital identity.

With the advent of distributed computing, network logon became anecessity, and technologies and protocols were specially created to handlethose needs. But they evolved from the context of the so-called workgroupcomputers to the full domain-based central directory. Workgroup computers werereally a set of workstations with a “master” element that took care ofpresenting the individual members as a cohesive entity. However, this was onlya view of the reality: You could enumerate workgroup members and resources but,when trying to access one of them, you had to be registered in the localidentity database of the member that held the resource; and this workgroupmember was responsible for checking if the credentials you used were correct.

The workgroup concept evolved alongside the network. When fileand print servers became popular, they were also responsible for holding theuser identity database and running the algorithms that checked the presentedcredentials’ validity. Initially, one server was enough for daily jobs, but asquickly as we could spell “network,” the need for networked servers showed upin our lives. This brought the challenge of presenting the user identity as aunique entity among all of those computational resources: If I wanted to use aprinter, no matter which server held the printer queue, I had to identitymyself using my single set of network credentials and get the job done. In thefirst years of the networked servers, a simple and effective (at that time)artifact was used: identity database replication. All servers that were part ofa known and trusted set of servers replicated its user database, effectivelyimplementing the concept of a single sign-on to network resources. Obviously,this mechanism had its limitations. When dealing with a large number ofservers, replication delays and even inconsistencies were commonplace.

This may have been one of the first times when there was a clearrelationship between identities and the individual who held them, because thesame set of credentials (user name/password) were used to access a set ofnetwork resources.

Then came the concept of the network domain. In it, a set ofworkstations and servers are managed under a central credential database,effectively allowing the creation of a common security context among all domainnetwork resources and processes. In the network domain model, not only usersbut printers, workstations, and services are assigned a set of credentials thatallow the execution of processes and communications among them. A user’scredentials will validate only on a workstation that is part of the samedomain.

This model also allowed the creation of trust relationshipsbetween disparate domains. With it, users who are controlled by domain A canaccess resources from domain B, if and only if domain B is set to trust thecredentials from domain A. This allowed for more flexible identity management,because there was no need to replicate or clone identities from domain A todomain B if the trust relationship has been previously established.

Unfortunately, this model requires that all domains that are partof the same trust mesh use the same set of technologies, making it verydifficult to share resources among loosely coupled directories or directoriesfrom different technology platforms.

New sets of technologies were created and standardized to handlethe transmission of user identities among loosely coupled network domains. Theyare collectively called identity-federation systems: A predefined,cross-platform, standardized set of protocols designed exclusively to transmituser security contexts to allow one network domain to share resources withanother network domain. These sets of standards-based protocols are friendly tothe Internet infrastructure, allowing the sharing of resources even in theabsence of dedicated network links.

As can be inferred from the preceding paragraphs, digitalidentities had to evolve from a single pair of user name/password to a verycomplex set of protocols that transport lots of user-related claims andattributes.

A Nontechnical View of the Digital-Identity Anatomy

Because of this evolution of the use and sharing of identities, anew understanding of digital identities was needed. In a simplified,nontechnical view, a digital identity can be seen as a set of at least fourlayers (see Figure 1):

Figure 1. Layered view of a digital identity

1.     Identifier

2.     Credentials

3.     Main profile

4.     Context-based profile

In this model, the innermost layer is the unique identifier ofthis digital identity. There should be no identical unique identifiers in thesame security domain. Users must have unique identifiers to be easilyrecognizable by any system to which they have access.

To have access to this identifier, the user must present to thesecurity system a set of credentials that will be checked against the computingsecrets stored in the identity database. This is the nearest that we can get interms of proof of possession. A user is entitled to access their own uniqueidentifier if and only if that user presents the correct set of credentials tounlock this magic number.

After the user unlocks the unique identifier, a set of commonattributes (called the main profile) is accessible to a system that may requirea little more knowledge than the unique identifier itself. This can be, forexample, the user name, department, Social Security number, company name, andso on. These attributes do not vary from system to system; they are the samewherever the user logs on. They are a fixed set of values that are tied to theuser during the lifetime of the logon session.

But not all systems need to share information. There are sets ofinformation that are only meaningful in the context of a system or relatedsystems. For example, frequent-flier miles are meaningful only under thecontext of an airline carrier, losing most of their semantic meaning if theyare moved from one carrier to another. However, they share the same semanticcontext when they are used by the mileage program associates (restaurants,hotels, credit cards, and so on). These sets of attributes are stored in thecontext-based profile.

One digital identity can have only one unique identifier, alimited set of credentials (user name/password pair, digital certificate/PINpair, biometrical data), a unique set of main profile attributes, and anunlimited set of context-based profile attributes.

The separation of the unique identifier from the set ofcredentials that are used to access it allows us to evolve the securitymechanisms without the need to create a different ID for the same user overtime. It makes a unique identifier last for the lifetime of the individual whois the subject of the identity. This is also the base of the currentidentity-federation systems: No matter what protocols and credentials are usedto unlock the unique identifier, the same value will be presented any time thatit is required.

The separation of the unique identifier from the multiple sets ofprofile attributes also helps us evolve the semantic and syntactic meaning ofthese attributes without affecting the user ID. One can use binary orXML-encoded data to store and/or present user-profile attributes withoutinterfering in the now stable unique identifier.

The Managed and the Unmanaged User Spaces

Today, digital identities fall into two different, and sometimesincompatible, worlds: the managed and the unmanaged user spaces. What are thedifferences between them, and how can we build an effective digital-identitystrategy?

Managed users are the ones to whom you can apply corporatesecurity policies during the lifetime of their interactions with your networkresources. They are full-time and part-time employees, vendors, trainees, andso on. They normally have signed a labor (or equivalent) contract with yourcompany, and so they are subject to all corporate policies regarding workinghours, safe Internet browsing, workstation and laptop security procedures, andso forth. The internal IT staff controls every device that it uses and is ableto block the access to any network resource when it detects misbehavior. Also,the managed users are subject to full auditing on their activities and are notthe owners of the data that they store on local and network storage.

Unmanaged users live in a different world and have completelydifferent security and privacy requirements. The unmanaged user is yourcustomer or your business partner; it can be you, a managed user in yourcompany’s internal network, but a customer (unmanaged user) at an onlinebookseller site. Unmanaged users are the owners of the information theyproduce, the owners of their financial data and your IT staff has limitedaction, except in the case of misuse of the resources or fraudulent actions.Essentially, they use your systems when they are connected to the Internet anddo not have direct access to the resources in your corporate network. They canimagine what your network looks like, but you have to create and manage allnecessary resources (or views) that hide the internal network’s topology andfunctional specifications from their eyes.

Unmanaged users pose another, different set of challenges thanthat of managed users: privacy. Privacy issues are difficult to handle andexposure of user data to theft can put your company’s reputation at risk. Thesechallenges resulted in the proposal of Kim Cameron’s seven laws of identity(see http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdffor more information):

Law #1     UserControl and Consent

Technical identity systems must only reveal informationidentifying a user with the user’s consent.

Law #2     MinimalDisclosure for a Constrained Use

The solution that discloses the least amount of identifyinginformation and best limits its use is the most stable long-term solution.

Law #3     JustifiableParties

Digital-identity systems must be designed so that the disclosureof identifying information is limited to parties that have a necessary andjustifiable place in a given identity relationship.

Law #4     DirectedIdentity

A universal-identity system must support both “omnidirectional”identifiers for use by public entities and “unidirectional” identifiers for useby private entities—thus, facilitating discovery while preventing unnecessaryrelease of correlation handles.

Law #5     Pluralismof Operators and Technologies

A universal-identity system must channel and enable theinterworking of multiple identity technologies run by multiple identityproviders.

Law #6     HumanIntegration

The universal-identity metasystem must define the human user tobe a component of the distributed system integrated through unambiguoushuman-machine communication mechanisms offering protection against identityattacks.

Law #7     ConsistentExperience Across Contexts

The unifying identity metasystem must guarantee its users asimple and consistent experience, while enabling separation of contexts throughmultiple operators and technologies.

Competencies, Commoditization, and Real Value

Faced with so many choices and challenges in identity management,some users are asking: Should this be at the core of my IT services or should Idelegate all of these activities to a third-party? This question leads to adeeper business question: What is the value of all of these identities for mycompany? How much time/money do I spend with identity management, and what isthe corresponding return on investment? In the world of Software + Services andSoftware as a Service, how do I create value from identity management? Is therevalue in outsourcing it? We must choose solutions to these problems carefully,because (as expected) they are highly dependent on each company’s businessmodel and current technology infrastructure.

When drilling down the business justifications and currenttechnology trends, one can reach the following conclusions:

1.     Identity management is not a core business activity for the company.

2.     There is no value that can be obtained from identity management.

3.     Identity management is still a nontrivial technology, so that specificcompetencies must be nurtured inside the IT department.

4.     Identities are becoming a commoditized IT function.

You have to understand how digital identities are being used byyour systems and what kind of resources you are providing, allowing, or denyingaccess to. When protecting internal network resources, it makes sense to retainthe identity-management competency in-house, mainly because it is being used tobuild and maintain strict access-control lists (ACL) and is generating tons oflogged data that will be used later when required by law or by internalauditing procedures. On the other side, customer access to internal resourcesis rare, and you can get much more value from a consistent and updateduser-profile and historical interaction data than from the identity-managementactivities. Customers usually have access only to application-generated viewsof data and business logic, and do not interact directly with internal IT dataor equipment.

There is another aspect when dealing with customer-related data.Some countries restrict the storage location of their citizens to in-countryhosted servers, demanding that you build and manage a local serverinfrastructure to handle their data and associated tasks.

This brings us back to the digital-identity anatomy presentedearlier. Companies can extract more value from the information contained in themain and context-based profiles than from the identifier and credentialslayers. Only companies that are dedicated to the business of generating andmanaging digital identities (like digital-certificate issuers) generate valuefrom the two innermost layers. The handling of the processes of authenticationis being commoditized, with little value coming from them. The value lies inthe information that can be generated from users, and not the processes thatauthenticate the user.

The Challenges of Identity Strategies

If you are building a new digital-identity strategy for yourcompany, first think about the audiences with which you will be dealing and theinfrastructure that your company will be using.

There are two audiences you will be exposed to: internal usersand external customers. You cannot get rid of your internal users:

They will be the ones who will help the company be successful,the ones who will create value for the business. They are part-time andfull-time employees, vendors, and trainees. Depending on your business, youmight not have a significant number of external online customers. Customerswill always exist, but they might not always be represented by digitalidentities and might not be worth tracking online. However, if you are part ofthe IT team of an online bookseller, for example, you will have to think abouthow you will handle the IDs for external customers.

For internal users, you might build an identity-managementinfrastructure to handle all authentication, authorization, and internal networkresource accesses, providing the correct auditing functions for future behaviorand fraud analysis. However, if your company is a start-up and wants tominimize the costs of building and maintaining its own infrastructure (and ifthe regulations allow), you will probably use cloud services to host yourcomputing needs. If so, use either state-of-the-art identity-management systemsthat are able to federate with external systems or identity cloud services(like Windows Live ID) to handle all of your internal users’ needs.

For external users, I tend to recommend the use of identity cloudservices for managing IDs. As explained earlier, the value lies in the main andcontext-based profiles, and not in the identifier and credential layers. Youwould have to build an infrastructure that was big enough to handle current andfuture customer audiences, which can lead to a big infrastructure that isdedicated to customer identity management. Also, think about the benefits ofattracting more users, because you are using a system that already has millionsof preconfigured users that will not have to register a new set of credentialsand will not have to learn new procedures for authentication.

Conclusion

Digital identities and their use are still evolving, based on theevolution of online services that are provided by the ubiquity of the Internet.Identity management is no longer merely a set of procedures for authentication,authorization, and provisioning of user accounts. If you understand how adigital identity works and how the protocols are evolving over time, you willbe able to build for your company a much stronger and lasting identityarchitecture. Today, building a new identity architecture means working withsystems and protocols that allow identity federation—further enhancing the useof your internal and/or external identities.

About the author

Fernando Gebara Filho is an infrastructure architect in theDevelopment and Platform team at Microsoft Brazil. He joined Microsoft in 1999as an infrastructure consultant at the local Microsoft Consulting Servicesteam, where he specialized in Active Directory and Microsoft Exchange projects.In 2004, Fernando joined the Development and Platform group in theinfrastructure-architecture role, where he had a chance to get more involved inthe identity-management space and get a more agnostic view of the subject.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the ArchitectureJournal Web site.