Identity Management: A Primer - Softcover

Kent Spaulding

Softcover

ISBN 10: 158347093X ISBN 13: 9781583470930

Publisher: MC Press (US), 2009

Synopsis

In an age in which the boundaries between the real and the virtual are becoming increasingly blurred, this timely guide teaches both the key issues of identity management as well as appropriate strategies and preventative measures for ensuring personal safety in the virtual world. In a corporate setting, it is essential to identify and control the way in which the organization deals with customers, suppliers, employees, and other users who may interact with the information systems of the company. Providing strategies for overcoming this task in real-world terms as well as questions that assist in focusing on the key issues in each chapter--ranging from role-based access control to single sign-ons and electronic identity smart cards--this text provides students and professionals alike with a valuable tool for understanding the complexity of identity in a virtual world.

About this title

About the Author

Kent Spaulding has extensive experience in software development and engineering with leading-edge expertise in identity-management. He is the current CTO of Skyworth TTG Holdings, Inc, and is the current chair of the OASIS Provisioning Services Technical Committee. Ilan Sharoni has extensive experience in identity- and access-management consulting work, particularly in the area of role management. He currently works for Eurekify with their flagship product Sage, a leading worldwide role-management tool. Graham Williamson is the CEO of Internet Commerce Australia. David Yip is an identity-management specialist with extensive experience in the field. He is a director of Gamatech, a specialist identity-management consultancy and systems-integrator firm based in Hong Kong.

Excerpt. © Reprinted by permission. All rights reserved.

Identity Management

A Primer

By Graham Williamson, David Yip, Ilan Sharoni, Kent Spaulding

MC Press

Copyright © 2009 MC Press Online, LP.
All rights reserved.

ISBN: 978-1-58347-093-0

Contents

Title Page, 
Copyright Page, 
About the Authors, 
Foreword, 
Introduction, 
Chapter 1 - Identity, 
Chapter 2 - Managing Identities and Identity Stores, 
Chapter 3 - Directories, 
Chapter 4 - Authentication and Access Control, 
Chapter 5 - Provisioning, 
Chapter 6 - Role-Based Access Control, 
Chapter 7 - Single Sign-on and Federated Authentication, 
Chapter 8 - Governance, Risk, and Compliance, 
Chapter 9 - Implementation and Roadmap, 
Chapter 10 - Public Key Infrastructure, 
Chapter 11 - Electronic Identity Smartcards, 
Appendix A - Case Scenario, 
Appendix B - Standards, 
Appendix C - Glossary, 
Appendix D - Public Key Cryptography Standards, 
Appendix E - X.509 Specification, 
Appendix F - Key Lengths, 

CHAPTER 1

Identity

A person's "identity" is a nebulous concept. We perceive a person's identity as an innate definition of a person that uniquely describes that person as an individual.

In reality, our understanding of a person's identity is built upon an incomplete set of attributes that we deem sufficient to differentiate one person from everyone else, but this attribute set is generally far from complete and is at an insufficient level of granularity to uniquely define a person. We normally rely on some level of human recognition that we consider sufficient.

If we meet someone in person, we typically rely on our visual recognition of the person. If we haven't seen the person in several years, we make allowances for the fact that he or she will look older. We still might be surprised if the person has aged significantly since our last meeting, but in general we are able to "identify" the person.

If we don't get to meet face-to-face but only talk to the person on the telephone, we rely on our auditory recognition of the person's voice.

We expect the accent, speech patterns, and voice inflections to match our recollection of the last time we talked. Again, we must make allowances for aging, particularly if the person is young, and we must compensate for poor telecommunications services. In effect, we are content to make compromises in our determination of a person's identity.

While this human recognition cannot occur in the online world, recognizing a person's "digital persona" must similarly make compromises. We must be willing to proceed to offer our online products and services on the basis that a person's identity definition is "good enough" for the purpose to which we are going to use it. We accept a level of risk that matches the application.

In an identity management system, a compromise occurs at two main points:

• In establishing an identity record, trust is placed in the validation of the source documents that verify a person's identity.

• When a person seeks access to a service, trust is placed in the authenticating mechanism (e.g., password, digital certificate).

What Are the Components of a Person's Identity?

An identity is typically defined by a combination of

• Generic attributes, such as name, address, and contact details

• One or more specific attributes that are meaningful to the organization maintaining the identity details

Generic attributes normally apply across identity domains, while specific attributes apply within an identity domain. Within an identity domain, an identity is typically unique.

For instance, a bank will store account details, a company will store payroll numbers, and a town council will store property definitions. Each of these entities represents an identity domain, and each will have one or more identity stores. The specific attributes typically will make the identity unique.

Uniqueness is an inherent requirement in an identity store. If an identity cannot be distinguished from all other identities in the store, it is of little use to systems relying on the identity store. Organizations therefore often append numbers to the end of your name when assigning you an account on their systems to distinguish you from other people in their database who have similar names. (This approach is often the most expedient one for organizations such as Hotmail, but, as you will see in Chapter 3, it is not good practice.)

The definition of some terminology is appropriate at this point. An identity (a person or business) refers to the unique entity defined by a number of attributes, such as name, age, hair color, fingerprint, and so on for a person or name, location, business number, tax number, and so on for a corporation. A person or business can have only one identity in an identity domain. A domain is typically the environment in which the person or business has an identity definition. Each domain might have one or multiple identity stores.

For instance, a teacher has an identity within a school. But the teacher might also be the parent of a son or daughter at the school. In some cases, the school might define two identity domains — one for teachers and one for parents — and maintain separate identities in each, but this practice reduces the effectiveness of the identity management system. For example, there might be computer system access that is permissible for a teacher but not for a parent. If the school is defined as a single identity domain, the policy that prohibits a parent from accessing a system can be enforced, but if the system cannot identify a teacher as being a parent, it cannot.

So Where Does Privacy Fit In?

The problem with privacy is that it is intensely personal; a wide range of perceptions exists regarding what is considered acceptable and what is clearly a violation of privacy. Some people have little concern about the information they will readily provide when applying for a product or service; others will rarely divulge anything more than is absolutely necessary.

Mistrust of organizations, including government agencies, that collect personal information fuels privacy concerns. Stories are legion about hospitals that inadvertently release sensitive patient information or banks that discard client records with banking details still visible.

It is not surprising, therefore, that as the use of online services has increased in recent years, so too has concern about privacy. In a number of areas, privacy advocates have arisen with the express mandate to safeguard the public's privacy. Indeed, civil libertarians often cite privacy concerns in seeking either to stop the deployment of an online service or to severely restrict how a service may collect and use personal data.

Partly in response to such concerns, the attention to privacy protection by online service providers has improved significantly over the past few years, with notable improvement in the protection of private details about their clientele. Most Internet sites now include a privacy statement advising why they are collecting identity information and what they might do with those details. It is unfortunate that so few users bother to read these statements and that even fewer refuse to partake of the service when they disagree with the potential use of their data.

In a recent Web site development project by a state government agency for a community of companies involved in shipping containers through a local port, an electronic directory of the community participants was deployed. Company names, addresses, telephone numbers, and email addresses were collected for the 2,000 members of the community. However, the privacy advocate ruled that no company record could be published until the company had expressly consented to its information being included. The department deemed this goal to be too much work, and the site went live with only 20 records in the directory and failed to attract sufficient use to justify its existence.

Privacy Rules

Although often decried as onerous by organizations that collect personal information, the rules associated with protection of privacy are really quite simple and understandable. Most geographies have regulations in place that are binding on government bodies and legislation that is mandatory for corporations.

Privacy regulation varies from country to country, but there are generally 10 principles to be adhered to in the collection and use of private data:

1. Collection of data — Only data that is required for the provision of the requested product or service should be collected by an organization. It is not permissible to collect data that "might be" useful at some point in the future.

2. Use and disclosure of data — An organization may use personal data only for the express purpose for which the data has been collected; no other use is permitted. It is not permissible to share the data with any other person or organization without the permission of the person who provided the information.

3. Security of collected data — All collected data must be adequately protected to ensure no other person or entity can access it. Safeguards must be in place to protect the collected data from inadvertent release.

4. Maintaining quality of data — Mechanisms must be put in place to maintain the quality of the data and to refresh it periodically. A typical time frame for personal information is three years. After this time, the data is of little use and, if not refreshed, must be destroyed.

5. Access to and transparency of data — The person whose identity data is being stored must be given the opportunity to view the collected data and correct it if need be. A mechanism to allow this access must be instituted.

6. Use of identifiers — An organization must not use another entity's identifier. Bank account numbers can be used only by the bank that issued them, a medical insurance patient number can be used only by the insurance scheme, and a driver's license number can be used only by the driver licensing board within the jurisdiction in which the license is issued.

7. Aggregation — Unless specifically required, personal information about individuals is to be aggregated to form collective data in which each individual's identity is not discernible. For instance, if birth date is requested for demographic analysis, only counts of persons within the various ranges can be maintained; the individual data records must be destroyed.

8. Anonymity — Consumers of online products or services must be given the option of maintaining anonymity unless it is expressly required that they identify themselves. (Online service providers widely abuse this principle, maintaining that they need to know the identification of users. The large number of entries for "Mickey Mouse" in service provider databases belies this contention.)

9. Sharing of data — The collector of private data is expressly forbidden from sharing that data with another person or entity.

10. Sensitive data consent — Collection of sensitive data must be accompanied by the express consent of the subject to the collection of the data.

Is This Where a "Trusted Third Party" Fits In?

One way in which an organization can protect itself from running afoul of privacy regulation is to engage the services of a trusted third party. Although this motivation is by no means the main reason to use these services, use of a trusted third party does free a company from the restrictions on collection and storage of personal data; this burden is transferred to the third party.

The main reason for using a trusted third party is to avoid the cost of collecting and verifying personal data. If a trusted organization has already validated the identities of a company's customer base, the company can "piggy-back" on that activity and avoid the cost of performing the same checks and having to maintain each person's identity record.

Using a trusted third party also lets a company answer the question "How are we going to trust that the generic attributes provided by a person are true?" Although organizations have complete control over their specific identifiers (e.g., bank account number, payroll identifier, registered plan number), they have no control over the generic attributes (e.g., name, address). Other than viewing a birth certificate to verify a person's name or looking at a property title to verify an address, a company has no way of knowing whether the data a customer provides is accurate. Trusted third parties do this work as part of their service and attest to the data's accuracy.

An inherent component of the definition of an identity is the need to anchor each identity in a trusted identifier. While most organizations that establish and maintain identity records don't want to go to the trouble of verifying source documents, they are keen to piggy-back on the processes of those that have. Driver's licenses are often used to validate a person's identity specifically because the government department that regulates motor transport sights a birth or marriage certificate before issuing a driver's license.

However, even though an organization might rely on a piece of validated data when establishing its identity record, storing such an identifier in its data repository may well be a breach of privacy legislation. For instance, a DVD rental company might well ask to see your driver's license to validate your name and address before renting you a DVD. But if it uses your license number as its record identifier, it is likely to have broken the law in many countries. Identifiers are typically owned by the organizations that generate them.

As discussed above, relying on the identification process of another organization is seminal to the management of digital identities. In the digital world, it is easy to share identity information and rely on someone else who has done the hard work. An industry has arisen around this concept.

Companies such as Thawte and VeriSign will undertake a basic verification of a person's identity and issue a digital certificate certifying that the person's identity is accurate and current. People can apply for these certificates, and once they have satisfied the requisite "evidence of identity," they are issued a certificate. This certificate can then be provided to other organizations as "proof" of identity. Provided the other organizations "trust" the issuing authority, they will rely on the certificate as attestation to the identity.

While the concept of a digital certificate is quite simple, there is more to its use in the real world. Digital certificates typically adhere to the X.509 standard, which has strict rules about the detail to be included in a certificate. For instance, a certificate must include a reference as to how it can be used. In some case, it will be used for authentication (e.g., signing documents); in other cases, it will be used for encryption (e.g., ensuring that only the intended recipient can read an email message). For more information about digital cer-tifi cates, see Chapter 10.

A trusted third party follows an evidence of identity (EoI) process to validate an identity. A trusted third party must publish its EoI process to enable relying parties to determine whether the process is sufficient for their purposes. For example, a common EoI process in Australia is the 100-point check used by many banks. Under this process, a set of "breeder" documents is defined that in combination are deemed satisfactory for the verification of an identity. Each document is assigned a number of points. For instance, a driver's license might be 40 points, and a credit card bill might be 20 points. When documents totaling 100 points have been seen, the person's identity has been verified.

It is not only in the provision of digital certificates that trusted third parties have arisen. Chapter 7 discusses the topic of federated authentication, in which identity providersgenerate "assertions" that validate a person's right to access a service. Microsoft's Infocard provides "claims" to a user's right to access a service. These are examples in which trusted third parties are providing an important component of the identity management environment.

Where Do Roles Fit Into the Concept of an Identity?

In the physical world, identities are often synonymous with roles. We talk in terms of the bank manager, the taxi driver, even our mother as identities. In fact, these are roles, with a human being as the incumbent.

When it comes to computer systems, the distinction between identities and roles is critical. Indeed, management of roles is a major and most challenging component of any identity management system. Organizations rely on roles and often see a person's role as a defining attribute to the person's identity. For instance, a person's role will determine whether the person has the authority to undertake a specific function in a business process. A role typically defines what a person can "sign for" in approving expenditure, authorizing a leave application, or granting access to a database. It is therefore a critical component of an organization's identity management function.

A person's role is only one attribute of the person's identity and is not very useful in determining uniqueness. Multiple persons in an organization may have the same role. And roles are typically transitory by nature, with people moving into and out of different roles over time. In some cases, a person will be put into a role for a short period of time, as for vacation relief. A further complication comes from the fact that many organizations let a person hold multiple roles concurrently. This circumstance further diminishes the usefulness of the role attribute as a mechanism to uniquely define a person's identity.

However, identity management environments must accommodate the inherent difficulties in working with roles because roles are such an important element when it comes to using an organization's identity repositories for access control purposes. Given that the major reason for a company to maintain identities is to grant access to computer facilities or restricted areas, access control is the focal point for most identity management installations.

Many identity management environments are poorly planned and display poor use of roles. This situation is typically due to vendors of software with identity stores that equate access rights with roles (e.g., the accounts receivable journal becomes one role, the accounts receivable reports generator becomes another, and so on). In this bottom-up approach, a user's existing accesses are used to compute a minimal set of roles. A better approach is to associate system access permissions with the "accounts receivable clerk" role. In this top-down approach, roles are defined by positions in the company, which defines the access rights the role incumbents should be granted.

(Continues...)

Excerpted from Identity Management by Graham Williamson, David Yip, Ilan Sharoni, Kent Spaulding. Copyright © 2009 MC Press Online, LP.. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Edition details

• Publisher: MC Press (US)
• Publication date: 2009
• Language: English
• ISBN 10: 158347093X
• ISBN 13: 9781583470930
• Binding: Paperback
• Number of pages: 200