Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities

Praise for Understanding Windows CardSpace “Windows CardSpace, and identity selectors like it for non-Windows platforms...

Author: Vittorio Bertocci | Garrett Serack | Caleb Baker

41 downloads 1505 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Praise for Understanding Windows CardSpace “Windows CardSpace, and identity selectors like it for non-Windows platforms, will quickly bring information cards to the forefront as the authentication mechanism of choice for end-users—at last signiﬁcantly reducing the pain and risks involved in username and password authentication. Vittorio, Garrett, and Caleb are three really super smart guys who know CardSpace and the underlying technologies and standards intimately. In this book, they provide the perfect amount of detail on the very real risks of today’s application security models, followed by an overview of relevant cryptography and WS* protocols, and then they dig right in to common scenarios for deploying CardSpace while also explaining important underlying parts of the CardSpace technology to help you understand what’s going on under the hood. If you aren’t sure if CardSpace is right for your applications, you should read this book and ﬁnd out why. If you are planning to implement a CardSpace solution, you should absolutely read every page of this book to gain insight into otherwise not well-documented information about the technology.” —Michele Leroux Bustamante, Chief Architect, IDesign and Microsoft Regional Director “Identity management is a challenging and complex subject, involving traces of cryptography and network security along with a human element. Windows CardSpace and this book both attempt—successfully—to unravel those complexities. Touching on all the major points of CardSpace and identity management in general, this book comprehensively explains the ‘what’ and the ‘how’ of this new Microsoft technology.” —Greg Shields, Resident Editor, Realtime Windows Server Community, Contributing Editor, Redmond Magazine and MCP Magazine “Learn about CardSpace from the people who built and inﬂuenced it!” —Dominick Baier, Security Consultant, thinktecture

“Chock full of useful, actionable information covering the ‘whys,’ ‘whats,’ and ‘hows’ of employing safer, easier-to-use, privacy-preserving digital identities. Insightful perspectives on topics, from cryptography and protocols to user interfaces and online threats to businesses drivers, make this an essential resource!” —Michael B. Jones, Director of Identity Partnerships, Microsoft “It’s one of the most serious problems facing anybody using the Internet. Simply put, today’s digital world expects secure and user-centric applications to protect personal information. The shift is clear in the demand to make the user the center of their digital universe. The question is, how do you build these kinds of applications? What are the key components? Unfortunately, identity is often one of the most overlooked and least understood aspects of any application design. Starting with the basics and building from there, this book helps answer these questions using comprehensive, practical explanations and examples that address these very problems. It’s a must-read for application developers building any type of Internet-based application.” —Thom Robbins, Director .NET Framework Platform Marketing, Microsoft, Author

Understanding Windows CardSpace

Independent Technology Guides David Chappell, Series Editor The Independent Technology Guides offer serious technical descriptions of important new software technologies of interest to enterprise developers and technical managers. These books focus on how that technology works and what it can be used for, taking an independent perspective rather than reflecting the position of any particular vendor. These are ideal first books for developers with a wide range of backgrounds, the perfect place to begin mastering a new area and laying a solid foundation for further study. They also go into enough depth to enable technical managers to make good decisions without delving too deeply into implementation details. The books in this series cover a broad range of topics, from networking protocols to development platforms, and are written by experts in the field. They have a fresh design created to make learning a new technology easier. All titles in the series are guided by the principle that, in order to use a technology well, you must first understand how and why that technology works.

Titles in the Series Brian Arkills, LDAP Directories Explained: An Introduction and Analysis, 0-201-78792-X David Chappell, Understanding .NET, Second Edition, 0-321-19404-7 Eric Newcomer, Greg Lomow, Understanding SOA with Web Services, 0-321-18086-0 Eric Newcomer, Understanding Web Services: XML, WSDL, SOAP, and UDDI, 0-201-75081-3

For more information check out informit.com/aw

Understanding Windows CardSpace An Introduction to the Concepts and Challenges of Digital Identities

Vittorio Bertocci Garrett Serack Caleb Baker

Upper Saddle River, NJ Boston Indianapolis San Francisco New York Toronto Montreal London Munich Paris Madrid Cape Town Sydney Tokyo Singapore Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected] Visit us on the web: www.informit.com/aw Library of Congress Cataloging-in-Publication Data Bertocci, Vittorio. Understanding Windows CardSpace : an introduction to the concepts and challenges of digital identities / Vittorio Bertocci, Garrett Serack, Caleb Baker. p. cm. Includes index. ISBN 0-321-49684-1 (pbk. : alk. paper) 1. Windows CardSpace. 2. Computer security. 3. Computer networks—Access control. 4. Identity theft—Prevention. 5. Web services. I. Serack, Garrett. II. Baker, Caleb, 1974- III. Title. QA76.9.A25B484 2008 005.8—dc22

2007044217 Copyright © 2008 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116 Fax (617) 671 3447 ISBN-13: 978-0-321-49684-3 ISBN-10: 0-321-49684-1 Text printed in the United States on recycled paper at R.R. Donnelley in Crawfordsville, Indiana First printing December 2007

Editor-in-Chief Karen Gettman Acquisitions Editor Joan Murray Senior Development Editor Chris Zahn Managing Editor Gina Kanouse Project Editor Betsy Harris Copy Editor Keith Cline Indexer Erika Millen Proofreader Language Logistics, LLC Technical Reviewers Dominick Baier Eric Ray Greg Shields Publishing Coordinator Kim Boedigheimer Cover Designer Sandra Schroeder Compositor Bronkella Publishing

To our families

This page intentionally left blank

Contents Foreword Preface

Part I

xv xviii

SETTING THE CONTEXT

1 THE PROBLEM

3

The Advent of Proﬁtable Digital Crime 4 The Dawn of Cracking 5 The Vandalism and Bravado Era: Viruses and Worms 7 The Rush to Web 2.0 and Asset Virtualization 10 Malware and Identity Theft 16 A Business on the Rise 27 Passwords: Ascent and Decline Ascent Decline

29 29 33

The Babel of Cryptography Cryptography: A Minimal Introduction HTTP and HTTPS: The King Is Naked

36 38 46

ix

x

Contents

HTTPS, Authentication, and Digital Identity The Babel

52 57

The Babel of Web User Interfaces

79

Summary

84

2 HINTS TOWARD A SOLUTION

87

A World Without a Center

89

The Seven Laws of Identity User Control and Consent Minimal Disclosure for a Constrained Use Justiﬁable Parties Directed Identity Pluralism of Operators and Technologies Human Integration Consistent Experience Across Contexts

92 94 96 98 101 104 105 107

The Identity Metasystem Some Deﬁnitions

110 112

Trust Roles in the Identity Metasystem Components of the Identity Metasystem The Dance of Identity

115 116 122 130

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem The WS-* Speciﬁcations WS-* Implementation of the Identity Metasystem

136 138 156

Presenting Windows CardSpace

161

Summary

164

Contents

Part II

THE TECHNOLOGY

3 WINDOWS CARDSPACE

169

CardSpace Walkthroughs From the User’s Perspective From the Web Developer’s Perspective

169 170 173

Is CardSpace Just for Websites?

175

System Requirements

176

What CardSpace Provides Consistent User Experience Brokering Trusted Interactions

177 177 181

A Deeper Look at Information Cards Card Types Personal Information Cards Managed Information Cards

184 187 188 196

Features of the CardSpace UI Private Desktop Disabling CardSpace Relying Party Identiﬁcation Page Managed Card Import Page

204 204 206 207 208

Common CardSpace Management Tasks Management Mode Creating and Editing a Personal Card Moving Cards Between Computers

210 211 212 214

User Experience Changes in .NET Framework 3.5 Simpliﬁed Use of Personal Cards Simplify Import of Managed Cards Better Communication to the User

218 219 220 220

Summary

221

xi

xii

Contents

4 CARDSPACE IMPLEMENTATION

223

Using CardSpace in the Browser Understanding the Information Card Browser Extension How Are the Extension Properties Used? Scripting CardSpace Processing the Token Accepting Personal Cards at a Website Accepting Managed Cards at a Website Auditing and Nonauditing IPs

224

Federation with CardSpace

248

CardSpace and Windows Communication Foundation Windows Communication Foundation Adding CardSpace to WCF Calling CardSpace from WCF Decrypting the Token Verifying the Token Processing Claims Additional Policy Options

252 252 255 256 258 260 260 261

CardSpace Without Web Services Manage CardSpace Import a CardSpace File Get a Token from CardSpace Get a Browser Token from CardSpace

262 264 264 264 267

Summary

268

224 228 232 238 243 244 246

5 GUIDANCE FOR A RELYING PARTY

269

Deciding to Be a Relying Party

270

Putting CardSpace to Work Preparation Database Changes Examining the Authentication Experience

274 275 276 277

Contents

Developing the New Authentication Experience Signing In Handling the Unknown Card Associating an Information Card with an Account Creating a New Account Recovering an Account Prompting the User to Use Information Cards Account Maintenance

278 285 286 288 288 291 294 297

Privacy and Liability

299

Summary

302

Part III

PRACTICAL CONSIDERATIONS

6 IDENTITY CONSUMERS

305

Common Misconceptions about Becoming an Identity Provider

306

Criteria for Selecting an Identity Provider Managed Cards Proﬁles Identity Provider Qualiﬁcations

309 309 312

Relying on an IP Beneﬁts of Using an IP Reaching an Agreement with the Identity Provider

315 316 318

Migration Issues

320

Summary

321

7 IDENTITY PROVIDERS

Uncovering the Rationale for Becoming an Identity Provider Managing Identities for Your Organization Managing Identities Used by Other Organizations Providing Claims-Based Services

323 324 325 327 331

xiii

xiv

Contents

Internet Commerce Providing Strong Authentication to Relying Parties

333 333

What Does an Identity Provider Have to Offer? Understanding Your Data Identity Provider Reputation

334 335 336

Walking a Mile in the User’s Shoes Roaming with Information Cards

338 340

An Organization’s Identity

341

Summary

342

Index

343

Foreword As this book explains, the Internet was built without any way of knowing who you are connecting to. This is now universally recognized as an architectural ﬂaw. It is as nonsensical as a house without a door or plumbing. Attempts to compensate for ﬂaws in architecture usually turn out to be messy, expensive, and unsatisfying. This has certainly been the case with the missing identity layer of the Internet. However, while it is fairly easy to get people to recognize the ﬂaws in the present system, getting the whole world to agree on a new Internet identity architecture is a daunting task. It means a lot of people with different backgrounds have to think hard about some pretty deep issues and breach many of the usual divides. It also means that the beneﬁts of the new architecture should be obvious and the road to progress clear. This book succeeds on all these fronts. It will be obvious to all who read it that it beneﬁts from the experience of people intimately familiar with the problem space and passionate about what they are doing.

xv

xvi

Foreword

It starts with an expansive explanation of current problems, dangers, and protective technologies. We get a tangible sense of the fragility of today’s Internet when faced with increasingly professional criminal attackers and confused users. Then the authors present the conceptual work that forms the basis of a new architecture: the laws of identity and the Identity Metasystem. The explanation includes a look at how the new architecture can be realized through web services. Next comes a detailed analysis and explanation of the part of the Metasystem that puts users in control of their identities—the “identity selector.” This includes a detailed explanation of how Information Cards work to turn digital identities into “real” visual things. All three authors were involved in building and testing out the ﬁrst identity selector—Windows CardSpace—and so have deep knowledge of the issues. The book becomes progressively more concrete, with good examples, and will be helpful to implementers, teachers, and students. But, because of its breadth, I think that the more technical policy makers will also beneﬁt from the work, getting a real sense for how digital identity atoms ﬁt together into molecules. I hope the chapter on the relying party will inspire people to build websites that take full advantage of Information Cards to deliver increased privacy and security. Vittorio has a distinguished background in security matters and put together many of the ﬁrst big Information Card pilots. Caleb was part of the CardSpace design team, responsible for ensuring that it actually did what it was designed to do. Garrett was the ﬁrst to integrate Information Cards into products like IIS and worked closely with developers to develop an understanding of best practices.

Foreword

All three are passionate and charming people and have contributed substantively to the emergence of Information Card technology and the Identity Metasystem. Have fun with their book! Kim Cameron Chief Architect of Identity, Microsoft October 29, 2007 http://www.identityblog.com

xvii

Preface In the past few years, identity has ﬁnally been receiving the attention it deservers. With rampaging phishing and widespread cybercrime as the forcing functions, the industry as a whole is reacting with a concerted effort to understand what the best practices are and is getting there fast. We had the privilege of being among the ﬁrst people concretely working on one of the key efforts of the identity renaissance: Windows CardSpace. Windows CardSpace is an expression of the new user-centered approach to identity management. The new approach is poised to solve many different problems of diverse natures: There are technological considerations, such as offering better authentication mechanisms than passwords; usability considerations, such as guaranteeing that the user has a clear understanding of what is going on; and even social-science considerations about how we can effectively leverage trust relationships and make obvious to the common user the identity of the website being visited. That is the reason why explaining Windows CardSpace in just a few words is so challenging. Depending on your background

Preface

and your role, you will be interested in a different angle of the story. We experienced this fact countless times in the past two years: with customers and partners, at conferences, with the press, with colleagues from other groups, and even with spouses, trying to explain what was that super important thing that kept us late at the ofﬁce. We believe that user-centered identity management has the potential to change for the better how everybody uses the Internet. We also believe that the best way of reaping its beneﬁts is to develop a deep understanding of the approach, complemented by hands-on knowledge of supporting technologies such as Windows CardSpace. The book you are holding in your hands has the goal of helping you to gain such insights. We live in exciting times. The entire industry is moving toward a common solution, with a true spirit of collaboration and a strong will to do the right thing. The discussion is open to anybody who wants to participate. We hope that you will join us!

Book Structure, Content, and Audiences Windows CardSpace is part of a comprehensive solution, the Identity Metasystem, which tries to provide a solution to many security-related bad practices and widespread problems. CardSpace is also a very ﬂexible technology that can be successfully leveraged to address a wide range of different scenarios and business needs. Finally, Windows CardSpace enables new scenarios and radically new ways of dealing with known problems. Given the sheer breadth of the areas it touches, it comes as no surprise that people of all positions and backgrounds are interested in knowing more about it. To address so many different aspects and such a diverse audience, we divided the book into three parts.

xix

xx

Preface

Part I: Setting the Context The ﬁrst part of this book introduces you to user-centered identity management, the model on which Windows CardSpace is based. This part lays the foundation for understanding the context in which CardSpace is meant to operate and the problems it has been designed to overcome. Architects, analysts, and even strictly nontechnical folks will get the most from this part. There are practically no assumptions of prior knowledge; the text introduces the necessary concepts and technologies as needed. Note that in the ﬁrst part CardSpace is barely mentioned because the focus is on the underlying models and considerations that are purely platform-agnostic. Chapter 1, “The Problem,” explores the problems with identity management today. It explores how authentication technologies evolved into the current practices, showing the historical reasons for current widespread problems. The chapter introduces basic concepts such as Internet protocols, types of attacks, introductory cryptography, authentication technologies, and so on. Chapter 2, “Hints Toward a Solution,” presents the current thinking about what the ideal authentication system would look like. The seven laws of identity are described in great depth. The Identity Metasystem is introduced, and its compliance with the identity laws is explained in detail. This chapter also provides a basic introduction to advanced web services and highlights how the abstract concepts in the Identity Metasystem map to concrete features in the web services set of speciﬁcations. By the end of Part I, you will have a comprehensive view of the situation: what the problems are we are wrestling with, why they are here, and how the Identity Metasystem can solve them. You will also understand the role of Windows CardSpace in the big picture.

Preface

Part II: The Technology Part II focuses on Windows CardSpace from a technological standpoint. It describes the technology, the elements and artifacts it entails, the operations and development practices, and the most common usage scenarios. This part is for the developer or whoever wants to have hands-on experience with Windows CardSpace. Chapter 3, “Windows CardSpace,” introduces the technology. This includes the user experience, Information Cards and the different card types, the private desktop, and the canonical usage scenario. Chapter 4, “CardSpace Implementation,” describes the usage of CardSpace in the most common scenarios. From the HTML integration syntax to token manipulation, going though federation, integration with web services and CardSpace invocation via native APIs, this chapter covers all the basic development tasks. Chapter 5, “Guidance for a Relying Party,” presents a detailed example of a common scenario: enabling Personal Cards on an ASP.NET website.

Part III: Practical Considerations The last part of this book is devoted to design and business considerations that come in handy when architecting a solution based on Windows CardSpace (or on user-centered identity management technologies in general). The chapters in this part will prove useful for architects and project managers. Business decision makers and IT managers will probably be interested in some of these considerations, too. Hints for developers are spread throughout the text.

xxi

xxii

Preface

Chapter 6, “Identity Consumers,” presents some thoughts about deciding to be or to use an identity provider. It also looks at things from the viewpoint of being a relying party: for example, the main effects on your business and operations of accepting identities in form of tokens and from third parties, and the opportunities you want to take advantage of and the caveats you want to avoid. Chapter 7, “Identity Providers,” lists some considerations to keep in mind when becoming an identity provider.

Conventions This book follows the conventions of the Independent Technology Guides series. Analysis sections appear in boxed sidebars and give you added perspective on the issues and technologies being discussed. Also, margin notes are included throughout the chapters summarizing or pointing out the most important points. Code-continuation characters are occasionally used in lines of code when we’ve broken lines to ﬁt the printed page. Lines broken by code-continuation arrows should be entered as one line when programming.

Acknowledgments The authors would like to thank David Chappell for believing in the project from the very beginning and for hosting our book in his prestigious series. The deep discussions we had about identity and how to explain its nuances were invaluable in helping us communicate the most complex topics. We would like to thank Kim Cameron for eliciting the dialog that led to the Laws, the Identity Metasystem, and ultimately Windows CardSpace. We could not have hoped for anybody more appropriate for writing the foreword. Many thanks to the Addison-Wesley production staff, who steered, guided, and helped us with great professionalism and inﬁnite patience: Joan Murray, Chris Zahn, Curt Johnson, Betsy Harris, and Emily Frey. This book would have never been written if we hadn’t had many enlightening conversations with our colleagues: among others, Ruchi Bhargava, Rakesh Bilaney, Donovan Follette, Vijay Gajjala, HongMei Ge, Andy Harjanto, Nicolo Isola, Mike Jones, Rajeswari Malladi, Luke Melton, Arun Nanda, Mark Oluper,

xxiii

xxiv

Acknowledgments

Govind Ramanathan, Rich Randall, Chuck Reeves, Nigel Watling, Hervey Wilson, and Steven Woodward. We would like to thank our management for endorsing and encouraging us in this endeavor: James Conard, Samuel Devasahayam, Neil Hutson, Stuart Kwan, and Anand Sivaramakichenane. Many thanks to the reviewers; without their tireless efforts this book would be much harder to understand: Chris Zahn, Dominick Baier, Eric Ray, Greg Shields, and many others. This book would have been very different without the experiences we shared with the many pioneers and the visionaries among our customers and in the community that decided to work with CardSpace in its early stages: Working side by side to make the Metasystem work for their scenarios was an incredibly insightful experience. We can’t name you all here, but when you read these lines, you will know we are talking about you. Thank you! Vittorio would like to thank his wife Iwona Bialynicka-Birula for her love, inﬁnite patience, and infallible support and for helping to break down those super long Italian sentences; his parents and siblings (Luisa Costantini, Bartolomeo Bertocci, Mauro, Franco, Marino, Cristina, Ulderico, Maria, Laura, Guido, Mira) for doing so much for him and for their unconditional love; and some of his professors at the Università di Genova, for teaching him the pride of computer science: Egidio Astesiano, Gerardo Costa, Leila DeFloriani, and Paola Magillo. Caleb would like to thank Paula Schachtel who provided encouragement, support, understanding, and an endless supply of baked beets as he hid out in the ofﬁce on the weekends to work on the book. Also he thanks his parents, sister, and brother (Tom, Linda, Vicki, and Thomas) for all they have done throughout the

Acknowledgments

years. He would also like to thank all the smart and inspiring people whom he has worked with at Microsoft. Garrett gives thanks to his wife Brandie and their two children Téa and Indyanna, for the time, encouragement, and understanding to work on the book. He would also like to thank Vittorio, Caleb, and Joan, for their endless patience.

xxv

About the Authors Vittorio Bertocci is an Architect Evangelist in the service of Windows Server Evangelism for Microsoft. He is based in Redmond, Washington. He works with Fortune 100 and major G100 enterprises worldwide, helping them to stay ahead of the curve and take advantage of the latest unreleased technologies. In the past two years, he helped many customers all around the world to design and develop solutions based on technologies such as Identity and Access Management, Windows CardSpace, Windows Communication Foundation, and Windows Workﬂow Foundation. He frequently serves as a speaker at international conferences such as IDWorld, Gartner Summit, TechEd, and the like. His blog, located at http://blogs.msdn.com/vbertocci, focuses on identity and distributed systems architecture; it is periodically translated into Chinese at www.china-ac.net.cn/zmjgsbkzxnew4.aspx. Vittorio has more than 13 years of experience in the software industry. He worked in the ﬁelds of computational geometry, scientiﬁc visualization, usability, business data, and industrial applications and has published articles in international academic industry journals. Vittorio joined Microsoft Italy in 2001 in Consulting Services. Before falling hopelessly in love

About the Authors

with identity, he worked with Web Services and Services Orientation from its very inception, becoming a reference and a trusted advisor for key industry players nationwide and at the European level. In October 2005, he answered the call of Microsoft headquarters and moved to Redmond, where he lives with his wife, Iwona. Vittorio holds a Master’s degree in Computer Science from the Universita’ di Genova, Italy. Garrett Serack worked as an independent software development consultant in Calgary, Canada, for 15 years, with clients in ﬁelds such as government, telecom, petroleum, and railways. Joining Microsoft in the fall of 2005 as the Community Program Manager of the Federated Identity team, Garrett has worked with the companies and the Open Source community to build digital identity frameworks, tools, and standards that are shaping the future of Internet commerce and strengthening the ﬁght against fraud. In the summer of 2007, he transitioned to be the Community Lead in the Open Source Software Labs at Microsoft. Garrett lives in Bothell, Washington, with his fantastic wife, Brandie, and their two amazing daughters Téa and Indyanna. Catch up on CardSpace and begin to learn more about Microsoft Open Source efforts on his blog at http://fearthecowboy.com. Caleb Baker has been at Microsoft for the past seven years and is part of the Federated Identity team. In addition to building CardSpace, the team is working on the other pieces needed to build the Identity Metasystem. Caleb has been on the CardSpace product team since 2004 (InfoCard at the time). Since the ﬁrst release of CardSpace, he has continued to work on future CardSpace products as well as various Identity Metasystem interoperability projects.

xxvii

xxviii

About the Authors

Before working on CardSpace, Caleb gained experience in the identity and security space by working on Active Directory and the Active Directory Migration Tool (ADMT). Caleb is a Seattle-area native, having graduated from the University of Washington with a degree in Physics and Political Science and has also earned a Master’s degree in Computer Science.

Part I

Setting the Context

Chapter 1

The Problem

3

Chapter 2

Hints Toward a Solution

87

1

This page intentionally left blank

1

The Problem Today’s digital identity crisis is the result of many independent factors, and their combined effects gave rise to the perfect storm that makes phishing and identity theft so lethally efﬁcient. This chapter brieﬂy revisits the evolution of online threats and reveals the complex connections by which apparently independent phenomena augment each other.

The issues surrounding digital identity management are a result of a combination of many factors

The section “The Advent of Proﬁtable Digital Crime” explores the arms race between computer systems and security threats. From software piracy to phishing, from worms to defacing, we walk you through the early traumas that shaped the industry reactions to security problems. Vulnerabilities and attacks are described in a concrete fashion, without using technical terms. To fully appreciate the solutions presented in Chapter 2, “Hints Toward a Solution,” it is important to have a solid, intuitive understanding of the issues that the industry is facing.

3

4

The Problem

The section “Passwords: Ascent and Decline” provides a historical rationale for the use of passwords. Although passwords are sometimes still an acceptable solution on single machines and local networks, we expose the most prominent reasons why that credential type is sorely inefﬁcient on the modern Internet. The section “The Babel of Cryptography” provides a gentle introduction to concepts and terminology of modern cryptography, framing the notions as answers to the problems mentioned so far. As the explanation goes deeper into the capabilities of those tools, it becomes evident that cryptography is an important instrument, but not a silver bullet that can alone solve the problem of identity propagation. A quick glimpse at the number of the standards and products in use today will give you an idea of the challenges that prevent prompt and resilient interoperability. The section “The Babel of Web User Interfaces” brings human behavior into the picture, showing how the tightest cryptographic protocol can be completely ineffective if its usage is not intuitive. The current Internet protocols, by their very nature, do not promote a user-friendly credential-gathering stage. Facts supporting this statement are presented, together with the most obvious and the more subtle effects on user conﬁdence and proﬁciency when dealing with digital identity. By the end of Chapter 1, it will be clear why the current situation is crying out for a strategic, long-term solution.

The Advent of Proﬁtable Digital Crime Today the Internet is part of our daily existence

You are sitting at the airport gate, waiting for your delayed ﬂight to start boarding. The unexpected delay, however, leaves you all but stranded. In the seasonless atmosphere of the hall, you suffer the familiar heat from the laptop on, well, your lap: A Wi-Fi card and an adequate amount of battery power are enough to pro-

The Advent of Proﬁtable Digital Crime

5

vide you access to an enormous number of resources. You can manage your mail, send your relatives instant messages (IMs), collaborate in real time with colleagues, check weather and timetables, check your bank accounts, buy goods online, translate a word you don’t know, track packages, rent cars, trade shares, write blog posts, ﬁnd out whether that duty free is really cheaper than online stores, trace routes, even access the recording of your favorite sitcom from the media center in your living room. Far from perceiving those activities as miracles, we already take them for granted. We are actually extremely disappointed when for some reason, say a lousy Wi-Fi provider, we can’t gain access to those resources. It’s difﬁcult to recall how life was before Web 2.0; nonetheless it is a useful exercise, and it will prove invaluable for putting into perspective the tools and motivations that animate today’s bad guys of the online world. The Dawn of Cracking

Twelve years ago or so, Internet access was the privilege of a few. It was the time of universities and institutions, of Usenet, and very few companies. The Internet Relay Chat (IRC) channel #Italy# had 35 concurrent users on the most crowded days. It was the personal productivity era: Ofﬁce, games, and computeraided design (CAD) programs were the main reasons for having a personal computer on the desk. Most software was distributed via physical media, initially ﬂoppy disks and later CD-ROMs.

Many practices still in use today evolved in a lessconnected era

Piracy was probably the most common cybercrime at the time. Still, it was a sluggish shadow of today’s phenomenon, forced to rely on expensive Bulletin Board Service (BBS), cracks passed by word of mouth, still-expensive CD burners, and full-ﬂedged mail orders from a few hacker groups.

It all started with piracy

6

The Problem

Although those illicit activities didn’t really have to do with identity, they are of key importance because they incubated two cornerstones of digital crime evolution: cracking and organization. Software offers opportunities for illicit gain

The main reason for cracking a program was the simplest: gaining access to a resource without having the right to do so. Breaking the license checks of a personal-productivity application in the 1990s meant disassembling and ﬁddling with a local copy running on your own computer, whereas today’s nastiest attacks have to be performed without accessing the binary of the target process. In the former case, you are in the position of performing any modiﬁcation. In the latter, you have to rely on known ﬂaws of the program or discover a new one. A ﬂaw that can be leveraged for compromising a program is known as an exploit. A good part of the gain obtained from cracking had to do with satisfying narcissistic instincts, but the chance to pocket some change was not too far away.

Cracking bands were among the ﬁrst to organize around the purpose of illicitly proﬁting from computers

The ﬁrst forms of organized actions come from that time frame, too. Although access was still not widespread, the falling prices of the hardware and the rising interest in software gathered likeminded people in cracking bands, with true “hacking auditions” for membership admittance and a good dose of romantic rivalries. Again, this was very far from today’s spamming behemoths and systematic phishing groups. With all the youth naiveties they may have had, however, those groups introduced an important idea: Software was a green ﬁeld for illicit activities, and there was deﬁnitely a good chance to make an easy proﬁt. Sellers of cracked software at a fraction of the price found an eager audience, especially because regulations (and enforcements) in that space were in their infancy. Gathering more crackers in groups noticeably improved their chances of gaining a margin. Many contributors meant a larger catalog of cracked

The Advent of Proﬁtable Digital Crime

7

products and dramatically simpliﬁed the cracker’s curse of those days: distribution. In summary, crackers learned the following during that period:

Software is a good that can be stolen.

Circumventing software protections is possible.

Coordinated action boosts proﬁts.

This last item was particularly remarkable when you consider the fact that it was still a disconnected world. The Vandalism and Bravado Era: Viruses and Worms

If piracy was the natural extension of the traditional compulsion to steal, we may think of computer virus writing as a form of vandalism. The idea of a computer virus is very old, but it gained real traction as potential hosts (programs) enjoyed widespread adoption and more distribution channels (BBCs, ﬂoppy disks, the ﬁrst shareware). The bane of early system administrators and every dad who had fans of pirated games in the household, it elicited the creation of an entirely new software class: the antivirus applications.

A virus is a malicious program that can self-replicate

If viruses weren’t bad enough for shaking user’s conﬁdence in computer systems, with worms things went out of control. A worm does not need a host program. Rather, it leverages known exploits in network-enabled software for spreading from machine to machine. Email clients, instant messaging (IM) programs, ﬁle-sharing software, even low-level network protocol implementations can be leveraged as infection vectors.

Worms brought security threats to a global scale

The worm phenomenon highlighted many of the techniques and the issues that can be found in modern security threats. The infamous worm ILOVEYOU, one of the worst global infections,

ILOVEYOU demonstrated the power of leveraging the human factor

8

The Problem

exploited social engineering to spread. It traveled in an email attachment named LOVE-LETTER-FOR-YOU.TXT.vbs, a name that was a strong motivator for launching the ﬁle and activating the worm. More reﬁned forms of this technique contribute to phishing effectiveness. Security problems on the Internet do not respect national borders

The whole ILOVEYOU affair hit the world with another key lesson, again a cornerstone in our quest for understanding today’s cybercrime; whereas an event on the Internet can ripple through the economies of the entire globe, law enforcement is still bound to the principle of the sovereignty of nations. The alleged author of ILOVEYOU has been identiﬁed as a university student in the Philippines. However, shortly after the discovery, all charges related to his involvement with the worm were dropped, because at the time that kind of crime was not contemplated by any law of the Philippines justice system. (The loophole was promptly closed, but the new law was not retroactive.)

Even untrained people can do damage with the right tools

As the idea of leveraging exploits gained traction, a second tier of bad guys appeared on the scene: script kiddies. Publishing code that illustrates how to leverage an exploit of well-known programs became a habit for many gifted crackers. That code would be taken by less-gifted individuals and included in toolkits and utilities designed for “messing up.” That would have meant, among other things, defacing websites, bringing servers to their knees via denial-of-service (DoS) attacks, attacking the machines of chat users, and even clumsy attempts at worm writing.

A Trojan is malicious software hidden in a legitimate program

Another common toy was the Trojan horse, or simply Trojan, a program that would be distributed hidden inside legitimate packages or disguised as some other kind of software (like a crack utility). A Trojan would install itself on the victim machine and listen for remote commands, to the delight of the attacker who would take control of the target computer (or, using the jargon in fashion at the time, “0wn it”).

The Advent of Proﬁtable Digital Crime

9

Conspiracy theorists may draw all sorts of illations from the computer virus/worm phenomenon; however, the reality is that no clear business model has been identiﬁed behind virus creation. The most plausible motivation is still sheer vandalism or the attempt to improve one’s own reputation. The media contributed to feeding the aura of coolness around it, providing meticulous coverage of crackers who, after major accomplishments, get a dream job in the tech industry (fueling the dreams of armies of script kiddies). In today’s world there’s little left of the narcissistic impulse that drove the ﬁrst worm writers: nonetheless, their spreading model is still one of the most effective for gaining unauthorized access to less-protected PCs. Where yesterday the prize was the satisfaction of yet another life touched by the author’s action, today it’s acquiring yet another zombie PC, adding ﬁrepower that is at the service of greedy spammers. The move toward a business mindset becomes evident, and it became more and more manifest as we got closer to the present. The same drive favors wormlike distribution patterns for an economy of scale, but script kiddy tools can also be used for targeted attacks. The importance of viruses and worms in the evolution of security threads cannot be underestimated, because it was one of the central factors in shaping today’s awareness of the dangers in using computer systems. Out there, there’s somebody who can harm you and your business and won’t hesitate to do it if you give him half a chance. This awareness is key to recognizing the need for some form of protection and the acceptance of the inevitable discomfort it brings. Installing an antivirus, remembering a password for accessing the computer, maintaining a personal ﬁrewall, not being able to attach executable ﬁles (EXEs) in email messages, are all nuisances that we would not accept if we thought there was no danger. It is a bit like allowing one extra hour for security-related lines at the airport after 9/11.

Viruses and worms inﬂuenced the way in which we think about computer security

10

The Problem

The Rush to Web 2.0 and Asset Virtualization

What we’ve seen so far aimed for the destruction of value and, in minor measure, for the improper acquisition of resources. It was a rough exploration; often the motivation for doing something was simply that you could. Today’s world is far less naïve. Also thanks to those early bad experiences, security is being tightened up at every level and almost everything is more secure by default. Yet, we are registering the highest cybercrime rates in history. Many factors contribute to this situation, but one is certainly worth mentioning: The amount of value accessible from computer systems today grew to a point that gaining improper access to even a fraction of it is a highly proﬁtable endeavor. Gaining unauthorized access to the computer has always been one of the most attempted attacks

In the personal-productivity era, the valuable resource was the computer itself and the capabilities of the software it contained. Apart from the local networks (we cover local networks in detail in “Passwords: Ascent and Decline”) initially limited to a relatively thin slice of white-collar workers, access to the computer was just a matter of knowing the BIOS password. It was not proper authentication but rather a very coarse form of authorization (again, see “Passwords: Ascent and Decline” and the deﬁnition of blind credentials). The same can be said for later uses of this security mechanism, such as password protecting Ofﬁce documents or Zip archives. Every resource was at the complete disposal of the computer owner, with the exception of licensed software; in that case, at least in the installation phase, you had to provide some form of proof of purchase (such as the stillpopular serial number, entered at installation time). There was not much to be stolen, and there was no way of doing it without sitting in front of the machine.

The advent of online services introduced a new kind of good to steal

Things started to change as computers gained access to new classes of resources that were impossible to have in local form. Among the ﬁrst examples were the mail services and the connectivity provider. For the record, this is one of the ﬁrst moments in which the consumer started to project his identity; gaining

The Advent of Proﬁtable Digital Crime

11

access to a connection involved supplying the service provider with a set of credentials, basically a trick of verifying that the incoming request came from somebody actually covered by a regular contract. The connection and the diffusion of the browser were the disruptive force that annihilated the distance between offer and demand. In the ﬁrst stages of general Internet access, practically everything was free: content, IM programs, archives, forums. Notable exceptions were the still-converging email services and porn content. The latter pioneered online payment, stumbling in a few youthful goofs, such as using regular expressions for validating credit card numbers or restricting access by veriﬁcation of a “serial number” as opposed to full-ﬂedged authentication. The latter was an approach that was already failing for software packages and that was far too brittle to be effective for an increasingly connected audience. All those activities taught people the ropes of user interface (UI) interaction. Like the ATM a few years earlier, the use of the browser (and personal objects, such as mobile phones and digital music players later) increased the proﬁciency of the end user; the ﬂashing time and date from VCRs became a less-frequent sight.

Proﬁciency with computers is a step toward the digital economy

The early near business-less phase was a great sandbox for users and technologies. As the episodic usage model gave room more and more often to the concept of the returning user, consumers learned to handle new kinds of resources. The right to exclusive use of a nickname in a chat system or being welcomed to a website by the settings assigned during the last visit are good examples of what trained users regarding the concept of projecting their identity online. That naturally included the possibilities entailed by the usage of the new media, including pretending to be of different gender, age, or nationality.

Recognizing returning users pushed the need for identiﬁcation technologies

12

The Problem

The spreading of email and connectivity was itself an incentive for accelerating adoption. For example, as the chance of reaching people by mail rose to a critical threshold, businesses abandoned en masse fax and traditional mail in favor of the more agile and cost-effective system. Yet another resource, business communication, migrated to the digital world. While that supplied the work force with a wealth of new possibilities, it also entrusted more and more individuals with precious company assets, such as customer and partner contacts. Over time, the increasing prevalence of access and collaboration technologies (virtual private networks [VPNs], extranets, corporate portals, mail-enabled devices) made the ofﬁce more ubiquitous, and even more trust had to be placed in employees’ loyalty and proﬁciency in the secure usage of the new tools. The attack surface grew considerably, preparing us for the next wave of cybercrime. More and more identity information is projected online

Technology improvement favored a growing mechanization of company processes, both in terms of internal procedures and cross-entity communications. Today in the United States, you can visit a doctor you have never seen before, yet your insurance number will be enough for him to know the last prescriptions issued and your medical history; the Social Security Number can induce even bigger miracles, and let’s not even mention the power of those 16 digits embossed on your Visa. In another Catch-22 pattern, those evolutions both enabled and were driven by the growth of online activities.

Ecommerce becomes the killer application for the Internet

We will lightheartedly ignore all details of the dotcom bubble here, fast forwarding beyond that crazy collective hallucination: Let’s just say that in the past ten years the usage of computers for online activity grew dramatically, and companies were quick (if not always effective) in jumping on the related business opportunities. The time that consumers spent online became signiﬁcant, and self-sustaining breakthroughs such as the fax-to-email evolution happened many times, in many ﬁelds. Banks offered account management and easy access to wire transfer, tradi-

The Advent of Proﬁtable Digital Crime

13

tional media companies found ways of providing their offerings as premium content, telephony and brick-and-mortar service providers opened their billing processes to online access, airlines devised more agile processes for ticketing and checking in, governments opened bureaucracy procedures, gaming companies created shared environments and charged for access. And above all, companies used the Internet for selling things. E-commerce truly took advantage of the new possibilities offered by the Internet, suddenly opening an endless cornucopia of products impossible to get by traditional means: Its sheer strength generated new models, such as the online auctions, fueled things such as online payment systems, and promoted the development of technologies for securing transactions. If we resume our effort of identifying resources accessible via a computer, we see that it became a daunting task: So much value is now available online! The most evident type is probably what is ours in the ofﬂine world but which can be managed from the online one: the money in our bank accounts; our privileges as citizens of our country; our list of friends and acquaintances; the utility services we bought, such as gas, long-distance call services, and insurances. Even our word, our reputation, our afﬁliations, our education levels, or simply our names are resources that we can leverage online. Then there are purely online resources: the mailbox itself and its content; credit with a Voice over IP (VoIP) service; the online payment system account; access to our employer’s IT system and its federnet of partners; accounts for vintage mailing lists and social network software; seller reputation on auction sites; accounts for all sorts of services, such as ﬁle replication, picture hosting—the list goes on. The most bizarre among the new resources is perhaps our eyeballs. With the advent of the online advertisement industry, the attention of users literally means money: Maintaining a website with a lot of visitors means that the real estate of the pages is worth a lot in ad contracts. Unfortunately, this is a powerful incentive for devising all sorts of schemes for luring users and

More and more value is projected and created online

14

The Problem

enticing clicks at all costs, which brings us back to considering the world from a criminal’s perspective. Spam leverages the scale of the Internet for adding up tiny margins into huge gains

The mind-boggling scale of Internet activities allows schemes based on the pure economy of scale to be proﬁtable: Spammers send their unsolicited commercial messages to literally millions of recipients, and a risible percentage of clicks is enough to bring the balance into the black. However, spamming is becoming hard work; growing awareness of the phenomenon erodes the already thin number of clicks, the arms race with antispam software is getting tougher, the evolution of international laws is shrinking the number of safe havens for spam ﬁrms, and the sheer resources implied in the process are a serious ﬁxed cost. Today’s online resources are susceptible to schemes that target a smaller scale but provide a much higher prize for every single successful scam.

When a resource is trusted to a third party, being able to recognize its owner becomes key for allowing access

Whereas a personal-productivity software package sat on your own computer, the vast majority of these new resources simply cannot be under your direct control. They may be remote, owned by others, dependent on external infrastructures, and inﬂuenced by many other factors. The natural model is then making resources available to you in term of services. You stipulate a contract, implicitly or explicitly, with the owner (or the guardian) of a resource; as a result, you gain a privilege on it. From that moment on, you can exercise your privilege just by being you. When you walk into a branch of your bank for the purpose of withdrawing some money, all you have to do is show a picture ID to the cashier and make your request. In Vittorio’s small hometown, where the director of the bank has known him since he was 6, until some years ago he may have even skipped showing the picture ID. In theory, online services are not different. You point your browser to the pages of your home-banking application, you give proof that it’s really you behind the keyboard (see later

The Advent of Proﬁtable Digital Crime

15

sections for much more on this topic), and you access the privilege of administering your money. In theory. There’s a small implementation detail that ruins this otherwise perfect metaphor. Although “I give proof that it’s really me” is a practice that enjoyed a fair degree of success in the ofﬂine world, the digital equivalent of user identiﬁcation is proving to be surprisingly brittle. There are many reasons for this situation, but for the time being we can approximate them in a single statement: We are applying to this new class of resources principles and techniques that successfully protected assets in the less-connected eras. This simple fact is at the very core of the attention that identity management is receiving, and ultimately the very raison d’être of Windows CardSpace and the book you are reading.

Recognizing users on the Internet is problematic

With all this wealth circulating on the Internet, the crime opportunities we have described in the previous sections seem like child’s play. Just compare the hassle of a supply chain, required for proﬁtable old-school software piracy, with the easy money you get by being in the business of compromising credit cards. You can literally get rich with it; and where there are opportunities, there are entrepreneurs. The motivations that drive cybercrime today are deeply different from the exploratory narcissism of the early virus writers and script kiddies. Sure, there are still defacements, DoS for political-activism reasons, and script kiddies showing off as a rite of passage, but the fastest growing class of attacks aim at getting your money, as much and as quickly as possible. Nonetheless, the experience and the technology matured in the worm and script kiddies phases is far from being out of the scene. Reﬁned and optimized for its new purpose, it is now in the hands of ruthless individuals and organizations driven by a clear aim: becoming you and harvesting all your resources before you know what happened. Yes, this is another difference with respect to the former era. Whereas in

Thanks to all the value accessible on the Internet, stealing identities makes more business sense than ever before

16

The Problem

the past criminals had to steal resources one by one, today stealing an identity means gaining, in a single move, all the privileges granted to that identity. Malware and Identity Theft Identity theft takes different forms depending on the context

The term identity theft is unfortunately very popular at the time of this writing. The term refers to a crime in which the perpetrator acquires conﬁdential information about somebody. It is usually followed by the identity crime, where somebody (not necessarily the original attacker) makes use of that information for impersonating the victim, usually for the purpose of pecuniary gain. In the context of this book, it is natural to associate identity with some software artifact, such as the credentials we use for accessing our Web banking application or our online payment account details. Nonetheless, the phenomenon is much bigger in scope, and bad things can happen even without any direct involvement of the victim with computer systems. See the “America and Identity Theft” sidebar for more details on this subject. In the remainder of this section, we show how the various considerations mentioned so far culminate in the main threats to the conﬁdentiality of our data.

There are many moments during which identity information can be under attack

Many different kinds of sensitive information transit or get stored in our computers: ﬁnancial data, addresses, identiﬁcation numbers, and above all, credentials and credit card numbers. The life cycle of the information include various phases: the moment in which it is entered, the moment in which it is transported, the moment in which it is processed, and the moment in which it gets stored. Dissimilar systems will be more or less vulnerable in different phases, and for each of those systems successful attack schemes have emerged. The bestiary of software classes speciﬁcally designed for malicious purposes has grown so much that we now use a collective name, malware, for indicating the likes of worms, Trojan horses, key loggers, spyware, and so on. The sections that follow by no means constitute a complete list but

The Advent of Proﬁtable Digital Crime

17

have the purpose of showing the extent and the nature of what we are dealing with. Attacks in the Information-Entering Phase The attacks in the information-entering phase are probably the most common, and they have a very good chance of being successful. They are carried out on the basis of two alternative principles: record the moves of the user without his knowledge or trick the user into entering sensitive data in the wrong place.

Remember our description of worms and viruses? We stated that such software can execute arbitrary code on the victim’s machine; well, it turns out that one of the most proﬁtable things one can do is record key strokes. Think about it. If somebody is able to see a recording of all the keys someone has punched in a work session, there’s really no sanctuary. All the information that went through the keyboard will be disclosed, no matter how sophisticated the transport and processing phases are. Falling victim to a keylogger is as easy as getting a virus or a worm; however, for being truly useful, this malware needs to have some Trojan traits, too. The list of recorded key strokes is still on the victim’s PC, and an attacker needs to put his fangs in it to take advantage of the information. This can be done by listening to some external command, such as a Trojan, or by sending mail to a predetermined address. Both operations are dangerous because they may allow a good forensic analyst to trace them back to the attacker. There are other ways of tracing key strokes, including concealing mini cameras at ATMs and looking at your neighbor on the plane as he types on his keyboard.

Keyloggers record all key strokes

Installing a keylogger is hard work. Antivirus products, hardening, and basic computer hygiene do a decent job in keeping those threats from inﬂationary growth. It turns out that instead of concentrating on the few feet between the keyboard and the motherboard, it pays much better to focus on what lies in the few inches between the user’s ears: his brain.

Keyloggers attack the computer; phishing websites attack the user

18

The Problem

Remember the trick used by ILOVEYOU? There was no technical reason for the user to open the attachment containing the worm payload, only the irresistible curiosity elicited by a clever name. Well, the most common forms of phishing build on that heritage. Phishing pages pretend to be legitimate websites and trick the user into entering valuable information

Some sources include in the deﬁnition of phishing all attacks aimed at the unlawful acquisition of other’s credentials, hence encompassing the keyloggers previously discussed and the manin-the-middle attacks discussed later. In the context of this book, however, we stick with a much narrower deﬁnition: Phishing is a social engineering attack that tricks the user into entering his private data in the wrong context, application, or user experience. The base schema used is deceivingly simple, yet incredibly effective: 1. The user receives a communication (an IM, more often a

mail message), which is allegedly coming from a legitimate source; a bank, a business, and a service provider are all common picks. For the sake of the example, let’s say that the mail pretends to be from a bank. The communication informs the victim of a hypothetical breach in the security of the system (or analogous excuse). Then it urges the user to follow a link (provided in the text), where he is requested to sign in and ﬁx the situation. 2. If the user happens to be an actual customer of the al-

leged source of the communication, he may believe in the validity of the communication and comply with these instructions. As soon as the victim follows the link, he’ll land on a page that mimics (with different degrees of success) the sign-in user experience that the emulated bank normally features. 3. If the user believes in the truthfulness of the communica-

tion, and the imperfections in the fake user experience are not enough to prompt the user to notice that the current website is not what it pretends to be, all is lost. The

The Advent of Proﬁtable Digital Crime

19

user will type his or her credentials in the text ﬁelds provided, literally handing to the rogue application his username and password. The user took the bait and has been phished. Sometimes, the malicious website will perform a redirect to the legitimate page it simulates, lowering the chances that the user will realize there’s something wrong. It is also possible that the fake website will refuse access a number of times, in the hope that the user will try the other passwords he frequently uses and thus end the scam with a richer booty. There are many variants to the main theme appearing on the scene—daily. The phishing mails can ride the economy of scale, like spam. Of the millions of recipients reached, only a small percentage will actually have an account with the bank used as bait; and an even smaller percentage (although it can still be an enormous number in absolute terms) will fall into the trap. However, the prize of a successful phishing session is magnitudes above the value obtained with sheer commercial spam. It is not uncommon to ﬁnd targeted spam, too; instead of broadcasting to an enormous number of random people, some phishers track customers of retail and auction sites for careless and high-volume spending behaviors. Crafting mails speciﬁcally targeted to those smaller audiences require a bigger investment, but the chances of a successful scam increase by a large factor.

There are many different phishing schemes

Phishing is truly the poster child for how the problems of our era are inextricably entangled together. (We often come back to this topic with more details in the upcoming sections.) However, it is of value to brieﬂy summarize here what makes phishing so special. It’s not difﬁcult to envision how a keylogging scheme may be applied outside of the computer world. People have overheard conversations or looked at texts over the shoulder for centuries. That said, how likely is it that phishing would happen in the ofﬂine world? The idea is almost comical. I may receive a

The strategies that work in the ofﬂine world might not apply in the online world

20

The Problem

credible fake letter from a bank, sure, but changing the road signs for leading me to a fake branch is much more challenging, as much as building a credible fake branch ofﬁce. (A few years ago in Naples there was a case in which a fake ATM was overlapped on the real one, but the scam didn’t enjoy a very long life.) If I have already gone to that branch in the past, it is borderline impossible to fool me. Naturally, some isolated cases might ﬁt the deﬁnition, if only we stretch it a little. Good examples are social-engineering attacks in which the scammer calls his victim by phone and, pretending to be a bank clerk, attempts to obtain identity data. However, such schemes never scaled up to the rank of a proper industry, given the spotty success rate and the high risks involved. Because we are considering things on a global scale, we can probably ignore those cases in our analysis. That said, why is something nearly impossible in our daily life perhaps the fastest growing crime scheme on the Internet? We take for granted some important factors in the ofﬂine world that are barely addressed in the online one. Telling a fake bank branch from a legitimate one is a snap, but telling a website from one that is an imitation is apparently much harder for users. We address this issue in more detail in the section “The Babel of Web User Interfaces,” and we mention server authentication in the section “The Babel of Cryptography.” Stealing our credentials in the ofﬂine world can be difﬁcult because it often (but not always; see the sidebar “America and Identity Theft” later in this chapter) requires acquiring a physical document in our possession, making it much harder (and much more noticeable) than just copying down the few characters that constitute a username and a password. Again, we explore that issue in much deeper detail in the section “Passwords: Ascent and Decline.”

The Advent of Proﬁtable Digital Crime

Attacks in the Information-Transfer Phase Let’s assume that our computer is malware-free and that we are entering our private data in the intended application or website, as opposed to one of the phishing fakes described in the preceding section. Unfortunately, we can’t relax yet; the bits we just typed still have to travel for a long distance before reaching the intended destination, and there are plenty of chances for attackers to compromise unprotected information in transit (see Figure 1-1).

For connecting a local computer network to the Internet, it is enough to link one node of such a network to a machine that is already part of the Net. Such a model is extremely handy because it allows growth to occur on the periphery without involving a central authority. The probability that two different computers are connected by a single direct link is negligible. In the vast majority of cases, information is routed through a number of intermediary nodes before reaching its ultimate recipient. The ﬁrst segments of the trip are generally known; when we

101101001 101001010 010101010 101010101 010101111 110011010

Figure 1-1 The journey of a packet from the user machine to its destination. At every step, somebody might be trying to intercept your data.

21

When the information leaves your computer, you have little control over it

Data packets follow a tortuous path before reaching their destination

22

The Problem

type an address in a browser on a machine at the workplace, our request will go through some networking hardware (a switch or a hub), and then it will jump from computer to computer in our intranet until it reaches our Internet service provider machines. From that moment on, our data packets zigzag through a path of intermediary machines that is very difﬁcult to predict, eventually (in most cases) reaching the machine that corresponds to the address we originally typed in the browser. It is possible to measure this phenomenon; a simple query for traceroute on any search engine will return a list of utilities that will show (even on a world map) the path followed by packets from the origin computer to any website. Reading data packets in transit is easier than most think

You might be tempted to think that once the information is transmitted on the network, it becomes unreadable gibberish (“signal”) until it reemerges from the other side of the cable; think again. The reality is that unless you take some special measures, what is sent on a network is as clear as a text ﬁle. The only difference is that while a ﬁle sits on the disk for as long as it is needed, if somebody wants to read network trafﬁc he has to do it while the transmission takes place. Many employees would be much more careful if they saw how easy it is to read what they type in their IM sessions (see Figure 1-2); the trafﬁc generated by a browser is possibly even easier to read.

In the man-in-themiddle attack, an aggressor intercepts communications between two other parties

The class of attacks that can be performed on the information in transit is known as man-in-the-middle. The literature on the subject often explains the scheme with the help of an example involving three characters: Alice wants to send a secret message

Figure 1-2

A network trace of IM trafﬁc

The Advent of Proﬁtable Digital Crime

to Bob, and Eve wants to know the content of such a message. In our context, Alice sends her message using a browser, Bob is a website (say our home-banking system), and Eve is the criminal (or criminal organization) that wants to steal Alice’s data. Literally anybody with access rights on any computer on the path between Alice and Bob can play Eve’s role. The computers of colleagues in the same room, or even on the same ﬂoor, will often be connected to the same networking devices. The same holds for the consultants and maintenance technicians who occasionally tap our networks though a laptop. The network trafﬁc will ﬂow through their network cards, too. Normally their machines would recognize which data packets are addressed to them and discard everything else. There is a kind of software utility, called a sniffer, that can visualize all the river of data ﬂowing through a network card regardless of its destinations. Whoever wants to play Eve will be able to effortlessly read all nonprotected content typed by Alice. Using a sniffer is usually against company policies, but there is always somebody who believes he or she has very little to lose (for example, an intern, an external worker such as a temp or a contract employee, a disgruntled employee, or a stalker) As we follow the data packets in their run toward the boundaries of the company, we encounter other nodes where information could be tapped; all the network administrators have tremendous powers, but they are the ones with more to lose if they get caught. When it leaves our company network, the information is in wild territory. All the situations we described for Alice’s company are even more likely for Internet providers. Today the situation is under better control, but there are still small providers that cut costs by employing students or amateurs. There’s nothing wrong in being one or the other, but the loose relationship weakens many of the deterrents that restrain regular employees. If Alice’s message makes it successfully to Bob’s website, we again encounter the same dangers with the Web host personnel and within the business organization behind the website itself. Even if all the staff of all the companies we touched in our

Eve could be anybody

23

24

The Problem

perilous trip were perfectly honest, it’s enough that one machine on the path is compromised by a Trojan, allowing an external Eve to, no pun intended, eavesdrop on Alice’s “secret” message. There are means of countering this threat; we explore some of them in the section “The Babel of Cryptography.” However, the existence of countermeasures does not always imply that they are thoroughly applied. Take the example of wireless networks. In 2005, I (Vittorio) used to commute between Pistoia and Florence, about 19 miles (30 kilometers) mainly in the Tuscany countryside; in that short segment, my pocket PC would pick up more than 40 Wi-Fi access points, the vast majority of them without any protection. Although most people might see this as a nice opportunity for stealing access to the Internet, the key consequence for criminals is that all the trafﬁc generated can be sniffed without putting a foot in the victim’s house. The address of the sites visited, the chat conversation taking place, the documents downloaded or transferred, the mail read from a Web interface, the information typed on nonprotected channels, all can be running like a river on the screen of Eve’s laptop, in her car parked not too far from the victim’s residence. There are countermeasures against the man-in-themiddle attack

Again, there are means of countering those threats. websites can protect their trafﬁc by using HyperText Transfer Protocol Secure (HTTPS), more on that in the next sections), and Wi-Fi networks can count on Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access (WPA) encryption methods for safeguarding the privacy of their users. The purpose of this section was to give you a feel for how easy and remunerative it is for Eve to be the man in the middle if Alice and Bob do not take adequate precautions. Attacks in the Information-Storing and -Processing Phases Let’s strengthen the hypothesis we assumed at the beginning of the previous section. Not only have we entered our information into the intended site from a clean machine, but we also know

The Advent of Proﬁtable Digital Crime

25

that the data made it through safely to its ultimate destination. Unfortunately, we are still not safe. If we are buying something online, the website is probably leveraging a shopping cart metaphor for handling our temporary data; it may even take advantage of some form of proﬁle so that we don’t have to type in at each visit our shipping address or our preferred credit card number. If the implementation of those functions is less than robust, an attacker may gain access to our session data. The possible maneuvers are far too many to be described here. However, just to give you a taste of the range of things that might be done, consider this: Key data may be stored in a cookie on your machine and accessed by other sites or local malware, the e-commerce website may be implemented on some engine known to have ﬂaws and exploits, the session might not be properly secured, and just knowing a temporary URL (Universal Resource Locator, an Internet address) may give clean access to data, and of course there are all the methods of stealing memory data in the case where the website machine has been compromised.

Once the information reaches a website, its safety is in the hands of the website itself

In a supreme effort of optimism, we can again assume that, in addition to all the supposition we have imposed so far, we managed to close our transaction successfully and securely. And yet, we are still not safe. Our data are normally stored somewhere, sometimes for proﬁle purposes, more often for allowing batch transactions later. When you buy something online, your card does not usually get charged immediately. The merchant must perform follow-up operations, and those require the credit card number.

The longer information stays in a place, the bigger the window of opportunity for attacking it

26

The Problem

The SQL injection attack tricks a website into treating data as code, allowing the execution of malicious logic

It could happen that another customer, visiting the merchant website after us, may try some attack for retrieving sensitive data about past transactions. One of the most commonly known attacks is called SQL injection. During a transaction, the merchant website collects customer information by prompting the user with forms. After those forms have been ﬁlled, the software behind the website connects to a database, inserts the newly acquired data, and runs comparisons with the existing records. An attacker may ﬁll such a form with cleverly crafted SQL commands rather than the data he was prompted to enter. If the software behind the website is not well designed, the commands entered by the attacker might end up being executed. As a result, the invader may trick the website into displaying page data such as the shipping address or the credit card data of all the customers in the unprotected database.

Entire databases can be stolen at once

A less-subtle attack involves compromising the entire store at once, by breaking the website itself (for example, by DoS— ﬂooding the software with too many requests and bypassing protections when the program collapses) or just gaining access to the machine hosting the DB with any of the methods described so far. As strange as it may seem, customer data can sometime make its way from those databases to the laptops of the website’s personnel. Such laptops can then be promptly stolen or forgotten on taxis, on subways, and in waiting rooms with the obvious consequences for the data they contain. As with the man-in-the-middle attack class, in this case there are countermeasures that can be set up for coping with these threats. Well-engineered queries, encrypted stores, secure sessions, and minimal attack surface on servers are all efﬁcient methods of mitigating risks. Ultimately, however, data attacks happen. The ultimate countermeasure is to not store credit card data at all. We will see later in the book that with the new identity management techniques, this is not only possible, but it is actually easier than storing sensitive information such as credit card data.

The Advent of Proﬁtable Digital Crime

A Business on the Rise

We have seen how from its very beginning the information technology market offered great chances of illicit gains. The ﬁrst phases incubated the technologies and the attack techniques that are popular still today; the advent of widespread connectivity on one side promoted exponential growth of the value accessible from a computer, while on the other it acted like steroids on the same attacks, boosting their effectiveness and proﬁtability. Although the software piracy market is far from being dead, identity and personal resources are the valuables being preyed upon today (see Figure 1-3). The enthusiasm (and the revenues) for the newly available goods and services is tempered by the consumer’s fears and insecurity. The risk of online fraud is difﬁcult to estimate for the end user, and this dampens the growth of a market that could otherwise be as explosive as other Internet-related sectors, such as social networks. We have seen which threats we face and how those came to be. In the remainder of the chapter, we explore how today’s main countermeasures fall short in providing a complete, usable, future-proof, and widely accepted solution to the protection of identity online.

Figure 1-3

Number of new phishing sites (from antiphishing.org)

27

28

The Problem

America and Identity Theft Many of the examples and documentation found in security literature make use of concepts and scenarios that are very familiar to the American reader but can be somewhat harder to understand for an international audience. This perspective box gives a very quick introduction to some of the main elements that will help the non-American reader to understand the most commonly described security-related scenarios. The Social Security Number, SSN for short, is perhaps the most common encounter in security examples and scenario descriptions. The SSN, introduced in 1937 for the purpose of tracking individual contributions to the national retirement program, is today the key for accessing services. Many national programs that needed a unique identiﬁer in the past 70 years depended on it. In 1961, the SSN became a reference ID for federal tax returns. In 1976, it became the key for registering vehicles. Today it is used for even more purposes, including health-care insurance, immigration, ﬁnancial services, and much more. Knowing the SSN of someone means gaining access to all the information that uses the SSN as a database key. Furthermore, because the SSN is supposed to be a well guarded secret, many business activities regard the knowledge of the SSN (or even just the last four numbers of it) as a valid proof of identity. That means that the SSN can be used for serious business (opening a loan, for example). Stealing the SSN is among the most complete ways of taking over a person’s identity. Another useful concept is credit history. In the United States, anybody who applies for a credit line, be it a credit card or a loan, is evaluated for eligibility on the basis of his or her past ﬁnancial history. Three main credit-reporting agencies keep track of all the ﬁnancial history of an individual, his credit history, and can supply a prompt assessment of the individual’s accountability as a buyer. One of the ways of accessing someone’s credit report is via his SSN. This mechanism partly mitigates the need for background checks that in other countries are instead the only tool available for assessing the risk of lending money to someone. As a result, many high-value transactions can be completed in a very

Passwords: Ascent and Decline

29

agile fashion. For example, credit companies sweep the credit report database, assess who would be a good customer, and send via ordinary mail preapproved credit cards. Those cards arrive with an associated credit line and can be used right away. They are the favorite prey of criminals who steal from physical mailboxes or go through the household trash (dumpster divers) in the hope of ﬁnding an offer that has been carelessly tossed out without having been shredded. If you are interested in knowing more about identity theft in the United States today, refer to The Identity Theft Protection Guide, by Amanda Welsh, a good book on the subject.

Passwords: Ascent and Decline Passwords, passwords, passwords. How many times do you have to use a password in one hour of Web surﬁng? They are a big pain, and an even bigger liability. However, their usage is so deeply rooted in information technology that they may seem inevitable. And to think that at the beginning it seemed like such a great idea!

Passwords are taken as a given. It doesn’t have to be that way

In this short section, we show how passwords make sense at a certain scale but fail spectacularly once certain thresholds are reached. By looking at the very basis of password adoption, we realize that they are not the solution to access control but rather a solution whose shortcomings are seriously affecting our way of approaching identity online. Ascent

There is a resource that looks available to a vast audience, but only a precise subset of that audience has the right to actually access it. How can usage be restricted to the rightful crowd? One of the most basic examples of this problem is the access to your own house. You want to let your spouse and offspring in

Access control can be realized in many ways

30

The Problem

even when you are not around, but you deﬁnitely want to prevent others from entering without your explicit consent. The lock-key combination is a very effective means of achieving that. The lock prevents anybody from entering, apart from the ones who own a copy of the key. The general idea of according access only to somebody who owns something is really good but not always readily applicable. Take the example of early computers. Hardware costs and lack of a widespread standard would have made the creation of a physical lock impractical, but above all, the availability of far cheaper and handier alternatives delayed that idea until recent times. The cheaper and handier alternative is relying on something that the user knows rather than owns. A physical key has to be crafted for a speciﬁc lock and distributed to the users. You have to remember to bring it along; it can break; and if for some reason the lock has to be changed, one has to go through the cycle again. On the other hand, knowing one password is one of the most agile things that can be devised. If the enemy stripped you of everything and you manage to escape from their prison, you can always reenter friendly territory by shouting the passphrase of the day. If the deal would be that for entering friendly areas you have to show a certain medallion currently in the pocket of a prison guard, you’d be in trouble. Passwords act as access gateways for computers

The ﬁrst computer access control was performed by passwords, strings of characters that can be entered via the machine input peripherals. The system was applied for preventing unauthorized access to a range of resource types, from the computer itself to single ﬁles and applications. Password-gathering screens blocked every access to the computer for those who didn’t know the machine password, documents and archives were inaccessible to those ignoring the appropriate ﬁle passwords, and software packages would refuse to install without users demonstrating knowledge of the product serial numbers. Physical keys on the parallel port, often referred to as dongles, appeared later and were an early example of the “something I

Passwords: Ascent and Decline

31

know” method. They never really became mainstream. We described what the IT world looked like in the section “The Dawn of Cracking.” For the time, those were adequate security measures, and to some extent we can still consider them valid. Can we consider them authentication? It is debatable. A deﬁnition of authentication that captures the intuitive idea could be something like “authentication is the process or the operation by which an assertion about the identity of somebody is veriﬁed.” The measures we previously described are rather an example of blind credentials: Demonstrating knowledge of the computer password or the product serial number states my right to access the resources, but it does not really say anything about who I am. In a book about identity, it ought to make a difference! When computers began being organized in local networks, the music changed. The entire point of connecting computers is communicating and sharing resources. As a consequence, the control migrates from a group of individuals with complete dominance over their machines to a central governance that establishes what is shared and who can access what. The keyword in the former sentence is who. Whereas before blind credentials were required for preventing unauthorized access to the user’s own resources, now that sharing becomes the norm as the concept of authentication arises. The blind credentials system maintained some grip here and there, like for protecting archived ﬁles, but the presence of a shared network promoted ﬁner methods of access control such as authorization. Now that all accesses were mediated by the network infrastructure, there was no need of remembering a password for every resource. The system knew the identity of users requesting the asset and could make decisions about authorizing access, denying it completely, or restricting it to a well-deﬁned set of operations. That was an important improvement over the blind credentials method, especially considering that authentication had to be performed only once at the beginning of the session, while authorization took place silently every time a resource was requested. One password to rule them all.

Passwords act as access gateways for user accounts

32

The Problem

On a small scale, passwords can be viable, but the shared secret idea has intrinsic ﬂaws

The password was conﬁrmed as the preferred authentication method, and again it proved a handy and agile system. However, it started to show some shortcomings. When your credentials grant access to shared resources, disclosing your password is no longer just personal business; it affects all the users of the network, and above all it affects the owner of the network itself. A secret is good until it is forgotten, and unfortunately passwords are prone to a number of bad practices that can very well jeopardize their usefulness as an authentication method. People need to remember passwords, and this simple fact appears to have a range of self-defeating consequences. The most classical examples are yellow sticky notes with passwords written on them decorating the monitors in cubicles and open spaces. Then there are passwords so easy to guess that they are completely useless: password, 123, a, a password that matches the username, even blank (just the Enter key) are very common choices. It gets worse: Making less-obvious choices could still be useless in the case of networked access. If I choose any English word as a password, however uncommon or hard to spell, I may think I found an easy way to remember it and make it extremely hard to an attacker to guess it. That might be true for an attacker who enters the password with a keyboard, but for a program it is a breeze to go though a dictionary and try everything until it hits the right guess. To close this intentionally incomplete list, we cannot fail to mention the most outrageous method of acquiring passwords; explicitly asking for it will have a surprising rate of success.

Password issues can be mitigated by strong governance and a good infrastructure

Those problems have reasonable solutions. Policies that strongly discourage writing down passwords (or handing them to strangers!), imposing complex passwords patterns including numbers and special characters (assigning such passwords to users does not work; they will almost certainly write them down instead of memorizing them, although nothing guarantees they’ll not do that anyway as a reaction to the complex pattern

Passwords: Ascent and Decline

33

constraint), and forcing the user to choose a new password from time to time are all good practices. The fact that the password management is buried deep in the network infrastructure, often even at the operating system level, guarantees that at least the most basic of the attacks described in the section “Malware and Identity Theft” are deﬂected. In summary, we can obtain a far from perfect but fairly secure authentication and authorization system. It is then natural to ask ourselves why we don’t often hear of local network breaks, whereas phishing regularly makes it into the news. Decline

After the local network came the Internet, and online services proliferated as described in the “The Rush to Web 2.0 and Asset Virtualization” section. At the time, the password had already gained its fame as the key (if not only) method of verifying credentials. As it was natural to extend its usage from blind credentials to local network authentication, it was natural to use it as a system for restricting access to remote resources and methods. It was at this point that the problems started; old solutions are not necessarily ﬁt for coping with new challenges.

Moving from local networks to the Internet is a complete game changer

A local network has an underlying authority, which permeates the entire environment and is the ultimate judge on resource access. When a user accesses a ﬁle share or a printer, it’s the same authority that decides whether the request will be fulﬁlled; in both cases, it is the network identity of the user that will determine the outcome.

In a local network, a single authority reigns over everything

On the Internet things are radically different. The company that offers Web-based email has no relationship with the one that produces your instant messaging application of choice. Nonetheless they both want their users to authenticate before enjoying their services. The effect is very similar to what would

On the Internet, the resources are spread across countless owners

34

The Problem

have happened to local networks if they would have stuck with blind credentials instead of moving to authentication: a pile of different passwords for every resource, with no clear distribution or maintenance model. The Internet situation is actually more complex. Every single service performs a full-ﬂedged authentication and, in the context of the resources managed by the same authority, all the good properties of authentication and authorization still hold. But crossing one boundary is enough for requiring authentication with a new resource manager. No central authority on the Internet can make informed decisions about who can access what, and there are all the reasons to believe that there will never be one. The network is simply too vast, diverse, and rapidly changing for tolerating the tight governance that would make such an authority feasible at all. Credential proliferation makes life difﬁcult for users

The result is that every user now bears the burden of a formidable number of credentials, one for each and every site and service mentioned in the “The Rush to Web 2.0 and Asset Virtualization” section. We have seen how hard is for users to remember one password for accessing the network at the workplace. Multiplying this by at least 23 can start giving an idea of the strain we are all suffering today. The literature even has a term for the subject: password fatigue.

The same password is often used with many different sites: Once stolen, access to all the sites is compromised

One ﬁrst consequence is the wild reuse of passwords. Besides all the malpractices described in the previous section, the sheer number of credentials you have to use makes the temptation of reusing the same passwords across unrelated sites hard to resist. Unfortunately, it is also a really bad idea. An attacker can gain access to multiple assets of yours all at once. This attack does not even need to set up a phishing scam to be successful. An attacker may simply run a low-value service and try to reuse the credentials saved in his user store to see whether they are suitable for accessing higher-value services. Another consequence

Passwords: Ascent and Decline

35

is the low tolerance for the act of typing in credentials. Because we have to do it so often, we welcome whatever shortcut can save us the hassle regardless of the risks it involves. Persistent cookies and automatic form ﬁllers are good examples. Although they are not necessarily a bad thing per se, they can blur the line between authenticated and unauthenticated sessions and promote careless behaviors. The list could go on and on. Perhaps the worst thing is that being far from our cozy local network exposes our data to all the tricks in the book: that is to say, all the attacks described in “Malware and Identity Theft” and more. For a start, when you land on a website, it is really hard to know with whom you are actually dealing. It could be the site of your bank, as it claims to be, or it could be a scam hosted on a Web server from a county without strong regulations against digital crime (remember the author of the worm ILOVEYOU; see the section “The Vandalism and Bravado Era: Viruses and Worms”). In other words, the server can authenticate you, but it is extremely difﬁcult for you to authenticate the server. We explore the issue of server authentication in depth in the sections “The Babel of Cryptography” and “The Babel of Web User Interfaces.” Anyway, what counts in this context is that this situation makes you a likely victim for attacks in the data-entering phase (that is to say, phishing).

Passwords are easy to give away, and phishing websites leverage that

Do you want to talk about man-in-the-middle attacks? In a local network, the authentication screens are usually well protected, and passwords (almost) never travel in readable format. On the Internet, the security level depends on the good will of who implemented the website and too often is not as safe as it could be.

Passwords are exactly the kind of data you don’t want to be intercepted by a man in the middle

Are there good, long-term solutions to those problems? This time we may be out of luck. The extension of password usage from local network to the entire Internet may simply have been a bad idea.

36

The Problem

There are many ways of protecting information in transit, but the fact that there are many of them itself makes interoperability tricky and prevents expectations from reaching a satisfactory common level. Current solutions for server authentication do not seem to work too well, and the absence of a common authority will always favor an ever-increasing proliferation of passwords, while there’s no indication that human memory will improve any time soon. The recent trend toward software as a service, or SaaS, promises to increase even further the need for accessing online resources as part of our daily workﬂow. Passwords are very much alive

You may think that the title of the section, “Decline,” is a bit preposterous given the wide usage that passwords are enjoying today. Yet, the decline is already happening. Lawmakers and regulators all over the world are already questioning the value of passwords as an authentication method, requiring additional authentication factors for high-value transactions. If it will not be CardSpace, it will be some other solution, but the days of passwords as we know them today are numbered; however, we should expect to see them around still for a signiﬁcant time.

The Babel of Cryptography Cryptography serves as the basis of modern computer security

In theory, the problem of preventing unauthorized individuals from reading private data was solved long ago. An entire branch of mathematical sciences, known as cryptography, is devoted to similar problems. The operation referred to as encryption can scramble any data to the point of making it useless to the casual reader. The opposite maneuver, the decryption, involves reversing the scrambling operation and setting the data to their original, readable form. Encryption and decryption are made possible by the use of logical equivalents of keys. As long as

The Babel of Cryptography

37

those keys are shared by two parties, they can ensure that nobody else will be able to access the content they exchange. (We go into much greater detail later in this section.) Problem solved, then? No. Drawing that conclusion would be as simplistic as saying that humankind has successfully addressed the problem of universal communication, substantiating the statement based on the fact that we discovered the concept of spoken language. Cryptography is exceedingly efﬁcient in ﬁnding mathematical algorithms that can protect the data in a fast and reliable way. Nonetheless, that entire process is wasted if Alice and Bob are not using the same algorithm. Even in the lucky case in which they both agree to use exactly the same algorithm and we solve the problem of distributing the keys, we may still not know with whom we are dealing. Alice may use a key for securing her communication with Bob, but what guarantees does she have that it is really Bob she is talking to? From whom did she get that key? If Eve can somehow smuggle her own key to Alice, pretending to be Bob, she will be able to decrypt everything that was encrypted with that key. Sure, the channel is impenetrable by everyone else, but that will not do any good for poor Alice, who will be unsuspectingly handling to Eve data such as the passwords she would have used for Bob’s website. At that point, Eve can go to Bob’s website pretending to be Alice and supporting her claim by using Alice’s password. Bob will have no reason to doubt Eve’s claim and will grant her all the privileges actually reserved for Alice. So much for having solved the problem!

Effective use of cryptography entails agreements among parties

The point here is that although cryptography is a cornerstone of a secure system, there are other factors that are at least as important. One of them is identity propagation. The fact that Bob wants to authenticate Alice before granting her privileges seems obvious and familiar. Thanks to the Eve scam we just described however, it is also clear that Alice should make sure that Bob is

Cryptography alone cannot solve all security problems

38

The Problem

really who he claims to be before trusting him with her data. This exempliﬁes the concept of server authentication. Another lesson we may draw from the scene described earlier is that the password-based authentication is very brittle; Eve should not be able to intercept it in the ﬁrst place, but in the case in which it happens, it is really not acceptable that she can so easily use it for impersonating Alice. More robust systems would prevent this; we describe some of them in the following subsections. However, they exhibit the same limitation mentioned for cryptography in general: that all parties must agree on a speciﬁed system for it to work. In the rest of this section, we develop some of the themes mentioned in this introduction: cryptography, identity propagation, and alternatives to passwords. We show how those are applied in today’s technologies and highlight how they sometimes fall short in trying to resolve key aspects of the problem of security online. Cryptography: A Minimal Introduction

In this section, we introduce a few basic concepts that are instrumental for understanding some security considerations throughout the book. If you are already familiar with X.509 certiﬁcates and public/private keys, feel free to skip this section.

Security by obscurity trusts the safety of the data in the hope that attackers will not discover what criteria was used for scrambling the information. Unfortunately, it does not work

Symmetric Key Cryptography In the introduction, we mentioned the term encryption, and we quickly dismissed the subject saying that it means “scrambling data to the point of making it useless for the casual reader.” This is substantially true, but also very simplistic. Messing with the sheer order of characters and/or substituting all a’s with @ is an incredibly naïve way of protecting data; current hackers and tooling would not be fooled by it for a second. Relying on the fact that the attacker does not know how you jumbled the data is known as security by obscurity, and it is one of the biggest delusions in this space. One of the basic principles of modern

The Babel of Cryptography

39

cryptography is that a secret should be safe even if the attacker knows in detail the algorithm that was used for performing the encryption. The mathematical functions employed in the scrambling must respond to very rigid canons of robustness and are the result of a process of sophistication that lasted hundreds of years. In its simplest form, an encryption algorithm can be seen as a black box with two entrances and one exit. In one entrance, you put the text you want to protect (the plaintext, or clear text); on the other, you enter a key, that is to say a string of characters of a certain length. Turning the “encrypt” knob will produce at the exit an unreadable fragment of text (the ciphertext), which is actually a nontrivial combination of the plaintext and the key. If an attacker acquires the ciphertext but not the key, he will need to be very lucky or very patient to access the content. Trying all the key combinations (known as a brute-force attack) against a modern algorithm can literally take amounts of time on the order of geological. If somebody owns the key, however, the decryption operation is straightforward. Entering the ciphertext and the key in the same black box would give back the plaintext. The encryption is said to safeguard the conﬁdentiality of data.

Symmetric encryption combines text with a secret key, obtaining unreadable data; only the knowledge of the key will allow you to retrieve the original text

The class of algorithms just described are said to perform symmetric encryption. That is to say, the same key is used for both encryption and decryption (see Figure 1-4). These algorithms usually perform well and have been used for a long time (Gerolamo Cardano, an Italian mathematician, introduced them in the sixteenth century.) Common symmetric algorithm names are DES, AES/Rijndael, and Blowﬁsh. Public Key Cryptography A symmetric key, however, can be a nightmare to distribute. If Alice wants to send to Bob a message, she has to know which key she should use. If Bob owns a key, he has to give it to Alice. This means that the exchange should be protected at all costs,

Key distribution is a weakness of the symmetric encryption schemas

40

The Problem

CLEAR TEXT

KEY Symmetric Encryption Algorithm

AEBFFA CBCBAE

ENCRYPTION DECRYPTION

Figure 1-4 Symmetric key encryption: the same key can scramble and reveal the clear text.

because restricting the knowledge of the key is the only factor that guarantees secrecy. If by any chance the key falls into Eve’s hands, all future messages from Bob will hold no secrets for her. World War II is full of stories where the Allies retrieved daily code booklets from German submarines and Japanese troops, using them for decrypting intercepted secret communications. In asymmetric key algorithms, you encrypt with one key but decrypt with another; hence you don’t need to distribute the decryption key

The solution to the distribution problem emerged few years ago, with the introduction of asymmetric key algorithms (or public key cryptography) in the 1970s. The new class of algorithms uses functions that cannot be reversed. In other words, the key that is used for encrypting the plaintext cannot be used for decrypting the ciphertext. As a result, a plaintext-ciphertext-plaintext full cycle needs two keys: one for encrypting and one for decrypting. The two keys are naturally related, but one cannot be derived from the other. Note that the roles of the two keys

The Babel of Cryptography

41

can be freely exchanged: If I will encrypt with A, I will have to decrypt with B, and vice versa. Popular technique names associated with this approach are Difﬁe-Helman, the popular RSA, and the more recent elliptic curves. This new feature is a game changer for our canonical example. Alice can now acquire the encryption key from Bob without fears of interception from Eve. That key is only good for encrypting messages that are intended for Bob but bears no decryption powers at all, so Eve cannot use it for accessing any private content. For this reason, we call such a key a public key. Bob does not need to hide it; in fact, he can publish it so that everybody can send him messages that won’t be readable by anybody else. Naturally, Bob owns the corresponding decryption key. It will be a well-guarded secret that nobody else will ever need to see. For this reason, we deﬁne the decryption key as a private key. Public key cryptography is one of the main enablers of the current level of security in the IT world. However, symmetric key encryption still plays a fundamental role. The algorithms implementing asymmetric encryption and decryption are much more resource-consuming than their symmetric counterparts, hence their usage is not appropriate in every situation. The current pattern involves using asymmetric encryption for bootstrapping the communication and securely sharing a symmetric session key. Once the session key is known by both parties, it can be used for protecting the communication using far fewer resources. In the example mentioned previously, Alice would generate a symmetric key and send it as the very ﬁrst message to Bob. Such a message would be secured via asymmetric encryption, and hence it would be safe from Eve’s attempt to intercept it and would allow Bob to save the value of the session key. Once both Alice and Bob know the session key, subsequent messages between Alice to Bob will be secured by the much faster symmetric session key and still be safe from Eve attacks (see Figure 1-5).

The encryption key can be known by everybody

42

The Problem

E

Bob

Alice

Bob

Bob

Bob

Eve Bob’s Public Key Bob

Bob’s Private Key Bob

E

Encryption Operation

Figure 1-5 Alice uses public key cryptography for sending a secure message to Bob. Eve can’t access the data exchanged.

Digital signatures prevent illicit modiﬁcations of the signed data and can certify the source of the signature

Digital Signatures We need to make one last effort in our attempt to understand cryptography and that is to talk about digital signatures. A digital signature is a procedure that protects a fragment of data from tampering. When something is digitally signed, it is impossible to apply any modiﬁcation without invalidating the signature. If the signature is performed using asymmetric keys, and the identity of the keys’ owner is known, it can also be used as a method of guaranteeing the identity of who performed the signature operation. Now that we understand how the public/private key algorithms work, it’s easy to see the mechanism behind signatures. Let’s assume that Alice wants from Bob a statement of some sort, like a contract; let’s also assume that Alice wants the

The Babel of Cryptography

guarantee that Bob will not deny the content of the statement at a later time (a guarantee known as nonrepudiation). Bob can reuse the same asymmetric keys infrastructure we introduced before. The statement, a fragment of data, can be reduced to a smaller string by a function known as thumbprint. The thumbprint of a data fragment is a bit like a printout of your DNA. It still uniquely identiﬁes you, but it’s much cheaper to send via mail than to actually send your entire body via courier. The thumbprint can then be encrypted with Bob’s private key. The result is the signature, and it can be attached to the statement. Now the roles are swapped. Everybody can decrypt the signature using Bob’s public key, having the proof that it was really Bob (as the sole owner for his private key) who performed the signature. Operatively, once Alice receives the data fragment, she reapplies the same thumbprint function used by Bob for signing; then she decrypts the signature, using Bob’s public key and compares the decrypted value with the thumbprint value she calculated. If the two values match, Alice has the proof that the data fragment is actually the one that Bob originally signed. Figure 1-6 summarizes the process.

Data

H

H(Data)

E

E

H(Data) Bob

Bob Signature Bob

Bob H(Data)

E Bob

E

=

?

Data

Alice

H(Data)

H

H(Data)

Figure 1-6 How a digital signature works. In the top half of the picture, Bob applies his signature to a data fragment. In the lower half, Alice veriﬁes Bob’s signature.

43

44

The Problem

If anybody modiﬁes the data fragment after it has been signed, the signature will break. Applying the thumbprint function to the modiﬁed statement will give a certain result that will differ from the result recorded inside the digital signature, hence exposing the modiﬁcation. Thanks to this property, it is said that the digital signature guarantees the integrity of the statement. As can be easily imagined, integrity and nonrepudiation are fundamental assurances, and digital signatures enjoy wide usage as the main tool of enforcing those guarantees. PKI and Certiﬁcates All the things described in this section are pure math. In real systems, however, the keys we mentioned cannot live in a vacuum. We must ﬁnd ways of reliably associating a public key with its owner, we need ways of generating and distributing keys in the volumes required by enterprise grade usage, we should make those keys available for consumption regardless of the software package used, and we must satisfy many other requirements. PKI provides a way of associating a key to someone or something

A Public Key Infrastructure, or PKI, is a collective name that indicates the various parts that constitute a solution to the aforementioned problems. In the reminder of this section, we explore some of those components. For the sake of understanding, we make some pretty dramatic simpliﬁcations.

The CA is the root source of all keys and certiﬁcates in a PKI

One of the key elements of a PKI is a certiﬁcation authority, or CA. The role of a CA is certifying that a certain key really represents the public key of someone/something. The main assumption here is that everybody involved in the system trusts the CA, meaning that they will consider the opinion of CA to be ﬁnal. Let’s get back to our Alice and Bob example. Alice wants to send a secure message to Bob, but she never had any previous interaction with him. She does not even know what he looks like. On the other hand she knows that a friend of hers, Trent, is also Bob’s friend. Alice then asks Trent for Bob’s key. Trent gives

The Babel of Cryptography

45

it to her, and she is ﬁnally able to send a secure message to Bob. How do we transfer this notion to the digital world? The most widespread solution involves the use of digital certiﬁcates. A digital certiﬁcate is a fragment of data signed by the CA. the CA’s public key is assumed to be available to everybody, so that in all cases it is possible to verify that the digital signature is valid and the content of the certiﬁcate is truly endorsed by the CA. The certiﬁcate itself contains a number of things, but for our ends it will sufﬁce to say that it is a container for the bits of a public key and the name of the individual or organization to which the certiﬁcate has been awarded.

A digital certiﬁcate associates an entity with its public key

Certiﬁcates are a very good mean of propagating key material while leveraging the existing trust relationship. Back to our scenario, Alice can now acquire the certiﬁcate that Trent emitted for Bob. Such a certiﬁcate will supply Alice with Bob’s public key and will contain an explicit reference to Bob (the subject of the certiﬁcate). Alice trusts Trent, and checking his digital signature enveloping the certiﬁcate is all she needs for considering the contained key as truly belonging to Bob. Alice is able to check Trent’s signature because she owns a copy of Trent’s public key, itself encapsulated in a special kind of certiﬁcate (a root certiﬁcate) that Trent endorses himself. This is all summarized in Figure 1-7. This creates a problem for Eve. Without Trent’s private key for endorsing her forged certiﬁcates, she won’t be able to impersonate Bob anymore.

Certiﬁcates leverage the trust relationships between parties

The most common format for certiﬁcates is known as X.509. All the minutiae of the ﬁle layout are deﬁned in this standard so that implementers can build certiﬁcate-based systems regardless of the platform. We come back to certiﬁcates often in the following pages.

The X.509 standard describes the most common format for certiﬁcates

46

The Problem

Trent

Certificate Authority

S

Trent

S

Bob

Alice Bob

Figure 1-7 Alice, Bob, Trent and their relationships. Trent, on the top, has his root certiﬁcate signed his own private key; Bob has a certiﬁcate signed by Trent, containing Bob’s public key; Alice can see both certiﬁcates and hence acquire the associated public keys.

HTTP and HTTPS: The King Is Naked

Let’s see how cryptography is applied by the most common systems in use today; again, the reader who is already familiar with HyperText Transfer Protocol (HTTP) and Secure Sockets Layer (SSL) can safely skip this section. A browser is a program on the client machine that renders content obtained from a Web server, a program running on a remote machine

The vast majority of users today access the Internet though a browser. Internet Explorer and Firefox are two common examples. Websites run on certain types of applications, called Web servers, which sit in front of the ﬁles that constitute the content of the website itself. The job of the browser is to request a speciﬁc document of the Web server and render the document itself once its bits have been received. The language in which browser and Web server talk to each other is HTTP. It is a simple, text-based protocol that was very easy to implement on

The Babel of Cryptography

47

different platforms and rapidly became the fabric that keeps together the World Wide Web. Like many other things described in these pages, HTTP was designed in the early, merrier days of the Internet. As such, it does not give too much thought to security. HTTPS provided an efﬁcient solution to that, at least from the cryptographic standpoint. HTTP Let’s see in more detail how the browser and the Web server use HTTP for making possible the navigation experience.

Alice wants to access Bob’s home page. She opens her browser and types Bob’s homepage address, say http://www.bob.com/ bob/homepage.htm, and presses the Enter key. The browser parses the line from left to right. The ﬁrst thing it discovers is that it will have to talk HTTP; the second is that the Web server it is supposed to talk with is www.bob.com. The browser tries to open a connection with the Web server sitting at that address, and then it sends the text shown in Figure 1-8. For the purpose of the discussion, we can safely ignore the details of the text. The only interesting point is that in the ﬁrst line the browser asks the Web server for the document it needs. If everything goes as planned, the Web server locates the document and serves it back to the browser. The text shown in Figure 1-9 is the reply that the Web server sends back to the browser.

Figure 1-8

An HTTP GET request

HTTP is the main protocol through which most interactions on the Internet take place

48

The Problem

Figure 1-9

An HTTP response

Again, the details of the text are not important. What is interesting to note is that the Web server, after a few lines of HTTP mumbo jumbo, writes the Hypertext Markup Language (HTML) content of the page requested by Alice in clear text. The browser reads the received HTML and renders it as the page depicted in Figure 1-10.

Figure 1-10

The browser renders the HTML.

The Babel of Cryptography

Apparently, Bob will show his real page only to authenticated users. Alice ﬁlls her credentials in the ﬁelds provided and clicks the Submit button. The browser will diligently use HTTP for sending information back to the Web server. The network trafﬁc generated will look like the text in Figure 1-11. The remarkable point here is Alice’s credentials are perfectly readable by anyone on the path between her computer and Bob’s Web server. Eve can throw a big party.

HTTP is a very insecure way of transmitting and receiving data

This is scary. Regardless of the fact that HTTPS, the solution to this problem, has been available since 1996, there is still a surprising number of naïve (or malicious) websites that will treat valuable information as described here. The average user does not run sniffers to see what browser trafﬁc really looks like, so this kind of negligence is largely unnoticed. We come back to this topic in the “Babel of Web User Interfaces” section. HTTPS As e-commerce gained momentum, it became painfully clear that HTTP didn’t provide acceptable levels of security for payments and transactions containing sensitive data. For this reason, in 1996, Netscape Communication Corporation proposed a more secure way of handling HTTP trafﬁc. The new system, known as HTTPS, encrypts the exchanges between a browser

Figure 1-11

The HTTP POST of Alice’s credentials

HTTPS leverages certiﬁcates for encrypting HTTP trafﬁc

49

50

The Problem

and a Web server so that man-in-the-middle attacks can be deﬂected. This important enhancement is made possible by the usage of certiﬁcates. An X.509 certiﬁcate must be associated with a website for it to be available via HTTPS protocol. Other keywords often mentioned in this context are SSL (Secure Sockets Layer) or TSL (Transport Layer Security). Those are the protocols that actually take care of the security aspects of the communication. Instead of deﬁning brand new security mechanisms, HTTPS uses such protocols for securing the HTTP trafﬁc. Let’s get back to our example. Bob wants to secure the trafﬁc to his website. He then purchases a certiﬁcate from Trent, who owns a well-known certiﬁcation authority. Such a certiﬁcate will declare to everybody who trusts Trent’s word that the public key contained in the certiﬁcate is really a key that was awarded to Bob, or better to www.bob.com. Bob conﬁgures his website for using HTTPS and his certiﬁcates, and then he gives the new address (https://www.bob.com/bob/homepage.htm) to Alice. Alice enters the new address in the browser and presses Enter. Eve, who is using her sniffer for capturing Alice’s messages, observes the trafﬁc on the network, as shown in Figure 1-12. The answer that Bob’s Web server sends back is even less clear (see Figure 1-13).

Figure 1-12

An HTTPS request

The Babel of Cryptography

Figure 1-13

51

An HTTPS response

To Eve’s dismay, all subsequent trafﬁc will be similarly garbled. The conﬁdentiality problem is solved. What happened? We really don’t want to go into the details here. However, in extremely simpliﬁed terms, here’s what happened. The browser and the Web server exchange information about their respective capabilities for using this or that encryption algorithm, and then the Web server sends its certiﬁcate. The browser extracts the public key from the certiﬁcate, and it uses it for encrypting a symmetric key that is then sent to the Web server. The Web server decrypts it, and then it starts using it for encryption of all the subsequent trafﬁc in a very efﬁcient way. This not 100 percent accurate (refer to Difﬁe-Helman for an exact description), but it should give you an idea of how certiﬁcates make all this possible.

HTTPS is very effective for preventing man-inthe-middle attacks between two endpoints

One important consequence of the usage of certiﬁcates for websites is that this constitutes a cryptographically sound method for declaring the identity of the website itself. If you apply the concepts introduced in the section “PKI and Certiﬁcates” to the current example, you will obtain a certiﬁcate signed by a certain CA and with a subject ﬁeld containing the value www.bob.com. In line with what was introduced in that section, this helps anyone who already knows Bob to be sure that his public key is the one declared in the certiﬁcate. However, this is also a statement from the CA that the identity of the current website corresponds to what is declared by the certiﬁcate itself. Whoever will land his browser on Bob’s website will have the word of the CA that such a website happens to belong to Bob; if the visitor trusts the CA, this will be enough for performing the already mentioned

If a website uses HTTPS, its identity is declared by a CA via the certiﬁcate necessary for implementing SSL

52

The Problem

server authentication. In the section “The Babel of Web User Interfaces” we revisit this concept, showing how this helps only to a point when the server authentication has to be performed by a human. HTTPS has been enormously successful and is the very base of e-commerce as we know it today. It is a good answer to the problem of conﬁdentiality of communications on the Internet. It is also a sound solution for the problem of server authentication, at least from the technological point of view. And yet, despite all those good properties, Internet scams thrive. HTTPS, Authentication, and Digital Identity

The previous sections, “Cryptography: A Minimal Introduction” and “HTTP and HTTPS: the King is Naked,” describe common problems and solutions that are applicable to all data communication on the Internet, and speciﬁcally the ones originated from a browser. Gaining insight into those topics is important for truly understanding the issues related to security and distributed systems, but it’s just a prerequisite for dealing with the problems related to identity management. Of all the possible browser-originated transactions, we are interested in the ones in which a user attempts to be recognized by a service; in other words, we are interested in authentication. To be consistent, given the distinction we made in the section “Passwords: Ascent and Decline” between authentication and blind credentials, we should probably relax the requirement and say that we are interested in transactions in which the user (or subject) transmits credentials to a service. HTTPS takes care of communication conﬁdentiality but does not provide a general means of sending identity information

This is a point of key importance. In what we have seen of the HTTP and HTTPS protocols so far, there is nothing that addresses directly the problem of gathering, packaging, and transmitting user credentials. To be fair, HTTPS actually features

The Babel of Cryptography

53

mutual authentication. We will see in the section “The Babel” why it is safe to ignore it for the time being. HTTP supplies the verbs for sending data from the browser to the server; HTTPS provides an opaque pipe through which packets can be sent protected from eavesdroppers. We can certainly use those tools for sending credentials in a secure way, but we have no indications whatsoever of the nature of those credentials or how they should be packaged. The result is fairly predictable. Secure credential transmission is widely implemented, but pretty much everybody does something different. Because authentication is not ofﬁcially part of the protocol, it becomes a responsibility of the application developer. When you write a website, you have to explicitly create a page with a user interface for gathering credentials; you have to write the code for securing credential transmission; ﬁnally, it is still you who has to write logic for reading the credentials just received in some structure in memory for being able to take authentication decisions. Sure, countless libraries will ease the burden by supplying you with ready-to-use controls, page frameworks, and authentication mechanisms. The problem lies exactly in the adjective countless. Everybody gives a solution tailored to a speciﬁc platform or context, and the result is that all hope of consistency and prompt interoperability is lost. There are no reasons for rating one solution superior to another. They all make sense for their speciﬁc context, so there is no selective pressure that would lead to convergence and hence little hope that a de facto standard would spontaneously emerge. This is especially true on the Internet where the requirements, technical capabilities, infrastructure, business drivers, and so on all vary widely and unpredictably. The consequences of this fact go beyond the sheer technical considerations. The way in which user interaction is negatively inﬂuenced is explained in the section “The Babel of Web User Interfaces.”

The lack of a standard makes authentication a feature at the application level

54

The Problem

All of what we’ve described would not be that bad if usernames and passwords were a viable option for Internet authentication. The absence of a standard is not the main problem with relying on passwords

Those who work in the IT industry know that many of today’s accepted practices are in fact pretty baroque hacks. Despite all the talk about enterprise application integration ﬁrst, and service-oriented architectures later, swivel chair is still the preferred integration technique in a surprising number of companies. Mitigating the lack of a standard place for username and password in today’s Internet protocols would not require anything uglier than previously described. Unfortunately username and password just won’t get the job done. The section “Passwords: Ascent and Decline” already provided some solid rationale for why passwords are not a good idea, but we are now ready to understand deeper, systemic reasons for why we need another solution.

Credentials are different from identity

In fact, the key reason is astonishingly simple: Username and passwords are not your identity. For a service or a website, a username is just a moniker for something that is already there: your registration data, the details of the service contract to which you subscribed, the settings you chose, the operations you can perform, and so on. If those facts are not directly there, they are still indirectly represented by the business rules that will be applied to you once you sign in and use the application. The password is just the shared secret that was agreed upon for demonstrating that is the person requesting access to the resources entailed by that username is actually the same person that originally signed up.

Credentials can unlock access to an identity

For the website, you are not your username and password. You are a set of facts and statements that are relevant to the services and data it offers. Usernames and passwords are just a means of locating and unlocking your digital identity.

The Babel of Cryptography

This is certainly not the place for indulging in philosophical discussion; however, it is worth pointing out that when we talk about identity in the business and technical context, we intend to use the term in the operational, as opposed to the essentialist sense. A business identiﬁes you not as the unique human being that is you, but as the set of facts and privileges that are associated with you and relevant to the scope of the services offered. If you are ﬂying in economy class and you try to check in at the business class counter, the queue attendant will ask you for credentials. If you just show your passport, strong credentials from your government for demonstrating that it is really you, the agent will gently accompany you to the huge line in front of the economy counter. On the other hand, if you extract the frequent-ﬂier card from a partner airline and you wave its golden shine, you will happily enjoy the privileges derived from having poured a stupid amount of cash into ﬂight fares last year. What happened? It was you all the time, but in the latter case it went much better. The reality is that in the business context, and maybe in all contexts except ethics and philosophy, identity is an operational concept. Identity is the set of true facts about a subject that are relevant to the given context. You might think that the preceding example is spoiled by an implementation detail. If the queue attendant would have searched your name in the database, instead of just inspecting the passport, surely he would have discovered that you are a gold member! Unfortunately, this is not the case. In our example, your frequent-ﬂyer membership is associated with a partner airline, and hence it is in the partner airline’s database. Your name does not appear in the database of the airline you are ﬂying with, or, better stated, it appears associated with the status of simple passenger (see Figure 1-14), a detail derived from the business relationships you maintain. We explore these concepts in greater detail in Chapter 2, “Hints Toward a Solution.”

55

The meaning of identity is intended here in the operational sense

56

The Problem

Ticket

Airline A

?

Airline B

Customer

Figure 1-14 The airline customer has different identities (and different privileges) on the two airlines’ computer systems

If your identity is deﬁned in the database of a website, chances are that you will be able to use that identity only with that website

The airline example is another tool for understanding what is wrong with the current authentication methods. It provides a classic example of the phenomenon that we call “hostage identity.” Every time you sign in on a website, you acquire the capability of using your digital identity with that website. However, some of the information that makes up your identity in this context is probably the same as the identity you have with many other websites; nonetheless, you are forced to feed that info over and over again because there’s no clear way of communicating that data between websites. The absence of that communication channel is a challenge if we want to replicate in the online world what we described in the frequent ﬂyer card example: using one identity across business partners. In the example, you used the privileges of your gold member status, achieved and memorized on the back end of one airline, with another airline as the service provider.

The Babel of Cryptography

Challenging does not mean impossible, of course. Business partnerships always endeavor to make internal resources accessible to partners: that is to say administering access privileges to one own network’s assets for accounts and identities managed by somebody else. In fact, many schemes and technologies beyond passwords have been developed for this purpose. In the section “The Babel,” we examine some of them. You will see how certain patterns we have seen in password adoption will repeat themselves in this case, too. Technologies that work well inside the boundaries of one company, or in the context of a welldeﬁned business partnership, are not necessarily ﬁt for a verbatim extension to the vast sea of the Internet. How we extend the beneﬁts of digital identity from the business world to wide consumer availability is the key theme of Chapter 2.

57

Sharing identities across boundaries is a common problem

The Babel

Passwords and shared secrets are not the best way of expressing and transmitting credentials. Hopefully, the discussion so far has made that point explicit. Authentication is important for everybody, but for certain processes and markets it is truly business critical. Hence it should not come as a surprise that a number of robust alternative credential-passing techniques have been developed and adopted through the entire industry. Some of those techniques mainly aim to harden the authentication process (for example, relying on asymmetric cryptography rather than shared secrets). The use of client certiﬁcates, regardless of the form factor in which they are made available, is an example of that. We discuss this in more detail in the section “Certiﬁcate-Based Client Authentication Schemes.”

Many different authentication schemes are in use today

58

The Problem

Another category of authentication techniques not only goes beyond the shortcomings of passwords, but also tries to solve the hostage identity problem described in “HTTPS, Authentication, and Digital Identity” section. Although username and password usually unlock information already residing on the service, your digital identity in that context, those new techniques try to obtain a portable version of the same information so that it can be reused elsewhere. In other words, those methods devise a new kind of credential that is actually descriptive of the identity it represents. Security Assertion Markup Language (SAML) and Kerberos are good examples of those techniques. We brieﬂy describe them in the section “Issued Token–Based Authentication Schemes.” We also take the opportunity to introduce the concept of federation. Those practices do not really present inherent ﬂaws like passwords do. Sure, some require more infrastructure than others, some are cryptographically stronger than others, and so on. But in the end, they all are very successful techniques, and used in the context in which they are meant to operate, they do an excellent job. Note the qualifying phrase “in the context in which they are meant to operate.” Non-passwordbased authentication schemas need a level of agreement that cannot be achieved in the fragmented reality of the Internet

As hinted at the beginning, those techniques were developed for dealing with cases where the defects of passwords were unacceptable. That very often means peculiar scenarios with strong IT infrastructure, such as enterprise resource access, governance of large-scale resource deployments, business partnership management, and so on. Because they all solve their own special ﬂavor of the authentication problems, those schemes are quite different from each other and can’t usually interoperate without bridges or expensive, brittle integration layers. When the global network was made up of many company islands sparsely connected, that wasn’t an issue. As those islands intensiﬁed intercommunication, it became more of a problem, but nothing that

The Babel of Cryptography

cannot be resolved (at least tactically) without throwing the right amount of money at it. That probably suggested that those techniques were suitable for being safely extended to the Internet, as it happened for passwords. Finally, the ubiquitous presence of Internet access we enjoy today reﬁned the granularity of the connected unit to the single individual. The sheer scale and complexity of this new Net makes a number of those techniques simply unfeasible, so you don’t see them in the consumer space. However, there are non-password-based authentication schemes that can operate on the individual scale. The simple fact that they can’t interoperate, however, is a deal breaker for supplying a universally valid authentication system. The simple diversity of authentication schemes, necessary for addressing the different need of the speciﬁc scenarios they are designed for, limits the user’s capability to reuse the identity itself and the proﬁciency gained in handling a certain technique across multiple services. As for many Internet-related phenomena, there are no good reasons for believing that a common system will spontaneously prevail over others. Even if it would happen, there are no guarantees that it will not be at a certain point supplanted by another future system, one better equipped for dealing with some unforeseen evolution of the IT landscape. In Chapter 2, we discuss a simple and straightforward solution to this apparently very hard problem. We devote the rest of the section to describing some notable examples of nonpassword authentication schemes. In line with the style adopted so far, we substantiate the abstract considerations made previously with concrete facts that can come only from a solid understanding of the underlying mechanisms and protocols. Besides helping to make our point about the incompatibility that afﬂicts today’s authentication Babel, the following descriptions introduce key concepts (such as security token and federation) that will be instrumental in your comprehension of Chapter 2. If you are not familiar with those notions, we suggest you to take the time to go through the next two sections.

59

60

The Problem

Certiﬁcate-Based Client Authentication Schemes In the section “PKI and Certiﬁcates,” you saw how certiﬁcates can relate one entity to its public key. In the section “HTTPS,” you saw this concept applied to websites, showing how the infrastructure can be used for supporting server authentication. Certiﬁcates can be used as a means for authenticating users

Strong governance can make certiﬁcate-based authentication viable

Because certiﬁcates and asymmetric cryptography in general work so well for handling data exchange and identity of services, it is reasonable to expect that those good properties may apply to end users, too. A CA can issue a certiﬁcate for an end user, assigning a suitable value to the subject ﬁeld. All the end user has to do is show off his knowledge of the corresponding private key, and everybody who trusts the CA will have all the evidence needed for believing in the identity of the user. Sounds straightforward, and in terms of the principle it is. The idea has been successfully applied in a number of technologies and contexts in which passwords are deemed sorely inefﬁcient, and the ﬁeld is in constant evolution. However, there are a number of attention points that must be addressed when using certiﬁcates assigned to end users. Although the majority of situations in which this technology is applied are suitable for addressing those issues, this is not necessarily the case on the scale of the Internet. In this section, we explore a few practical applications of certiﬁcates as a means of authentication for end users, highlighting why they are very successful in their intended context but not necessarily suitable as a universal solution. Corporate Smartcards and Intranet Certiﬁcates In the section “Ascent,” while describing the rise of local networks, we introduced the concept of authorization. When the user lives in a world of resources managed by a single authority, the one who set up the network infrastructure in the ﬁrst place, it is possible to regulate accesses and privileges by using the user identity as opposed to a list of blind credentials. It is interesting to point out that, in the context of a corporate network, the user is a managed resource (or, to be precise, the user’s account is). The exact meaning of the term will vary depending on

The Babel of Cryptography

the platform on which the network infrastructure is built. However, you can think of it as the logical representation of the user identity in the network. In certain systems, it may be a string representing a username, some means for verifying the corresponding password, a set of permissions codiﬁed in some way, and the home directory; in others, it may contain something more or something less, but that is the basic idea. What does it mean, in practical terms, that the account is a managed resource? It means that the network handles its creation, provisioning, maintenance, and deletion. The network governance can exercise complete control over the account itself. In such a situation, assigning a certiﬁcate to every account on the network is reasonably easy. The network can have its own CA, which can issue a certiﬁcate contextually to the provisioning of an account; the network itself can take care of distributing the certiﬁcate in the appropriate locations; again, the network can take care of eliciting a certiﬁcate renewal when the time comes, enforce certiﬁcate revocation when appropriate, and verify proper usage at every step. It is also easy to get every service and resource in the network to trust certiﬁcates emitted by the corporate CA because everything lies under the umbrella of the same authority. From the user perspective, the presence of a certiﬁcate may or may not impact the experience. The most visible case is certainly the one in which the certiﬁcate (and its private key) lives on a smartcard. In that case, the user is assigned a physical piece of gear. Typically, the smartcard has to be inserted into a reader for performing certain operations, such as logging in to the system or performing a remote access. The network software or the operating system try to use the private key on the smartcard for demonstrating to the service requested that the user has access to it, hence proving his identity. A further protection is guaranteed by locking the private key behind a PIN code. At every usage of the smartcard the user will be asked to type in an unlocking code, blind credentials that prevent scenarios in which a thief tries to use someone else’s card. This is a good

61

62

The Problem

example of a two-factor authentication technique. An employee must use something he has (the smartcard) and something he knows (the PIN) together for gaining access. Certiﬁcates impose a trade-off between security and agility

Using a smartcard is incomparably more secure than simple username and passwords. However, it is also way less agile. We have seen how being able to count on a centralized network makes its use possible; however, it is still an expensive endeavor. Smartcards have to be bought and ﬂashed; readers have to be deployed; policies have to be created and enforced for distribution; certiﬁcates have to be renewed. Good network software can help, but not everybody has a full Windows 2003 domain with autoprovisioning (or equivalent technology) in place. Even in that case, from time to time users will lose their smartcards; they will not log in on time for the renewal to take place; they will choose useless PINs; their readers will break; you can apply your favorite ﬂavor of Murphy’s law here. As previously mentioned, security has a price. In the smartcard case, only those with a good investment in IT resources can afford it. The so-called soft certiﬁcates, certiﬁcates that reside on the user’s machine rather than in an external device, do not offer the same advantages of smartcards, and they even share some of their shortcomings.

HTTPS supports the use of certiﬁcates as a means of user authentication

SSL Client Authentication In the section “HTTPS,” we mentioned how the HTTP protocol can mitigate its security shortcomings by relying on lower-level protocols such as SSL and TSL.

Another good property of SSL is that, analogous to what happens with the server, it can leverage a certiﬁcate for performing client authentication. Without really going into the gory details of the SSL handshake, the following list summarizes how SSL client authentication works:

The Babel of Cryptography

63

1. The user points the browser to a Web page that requires

SSL client authentication. The system examines the user’s local account for suitable certiﬁcates available on the client machine; depending on the results and on the settings, the user may be prompted to choose a speciﬁc certiﬁcate or give his consent for the certiﬁcate usage. 2. The certiﬁcate is sent to the server, along with a small

fragment of random data signed with the private key corresponding to the chosen certiﬁcate. The server veriﬁes a number of things, including integrity of the signature, trust relationship with the CA, certiﬁcate expiration, CA signature on the certiﬁcate, and so on. If everything is okay, the Web server will try to map the certiﬁcate to an account on the network to which the server belongs. Alternatively, it may try to map the certiﬁcate to an application account (that is, an identity that makes sense only in the context of the website application). 3. When the Web request has been mapped to an account,

the usual authorization checks will take place. Figure 1-15 summarizes the process. It is very straightforward. Furthermore, SSL is a widely implemented standard, supported by all the major browsers, Web server software, and platforms. The chance of leveraging interoperable client authentication seems like it would be fairly high given that SSL use is ubiquitous. Yet, this is not an exceptionally common scenario. SSL client authentication is great when the infrastructure is already in place. If an employee is trying to access a website that is an asset of its employer network, where he owns an account, SSL client authentication is a way of extracting further return on investment (ROI) from the certiﬁcate infrastructure investment. If

Again, HTTPS client certiﬁcate authentication can be viable in enterprises with strong governance

64

The Problem 1 HTTPS Select Certificate 2

4

S

Browser

PAGE Subject

3 Choose One Certificate

S

Random Data

Certificate Store

Figure 1-15

HTTPS client authentication steps

somebody already went through the headache of the provisioning problems, enabling SSL client authentication has very little cost compared to that. In the consumerism era we are living in today, where we often have better computer equipment at home than in the ofﬁce, remote access is an increasingly popular scenario. HTTPS client certiﬁcate authentication does not work very well with customers because of the difﬁculties of distributing and maintaining certiﬁcates on unmanaged machines

There are also businesses that chose to protect their customerfacing services with SSL client authentication. The approach exhibits clear advantages over passwords, especially for activities involving high-value transactions. For example, a homebanking application protected by a client certiﬁcate is not susceptible to phishing as we know it today. All the authentication operation is based on asymmetric cryptography; there is no shared secret between the bank and its customer, and hence there is nothing to steal that a phishing attack may acquire and reuse. Those advantages, however, come at a very high price for

The Babel of Cryptography

65

the brave bank that decides to implement such a scheme. Customers are not employees. Trying to extend governance to their IT assets is like herding cats. Everybody will have different systems, different degrees of understanding of computer usage, different habits, different expectations. The ﬁrst provisioning of the certiﬁcate can be challenging, given the number of things that can go wrong during acquisition and installation, plus renewal and maintenance is an outright nightmare and roaming access is a challenge. As we discuss in the section “The Babel of Web User Interfaces,” certiﬁcates and their management are not concepts we can hope the user is familiar with. If you want to use them in a consumer-facing application, be prepared to reinforce the headcount of your call center and train your IT staff to twist your processes for accommodating all sorts of unforeseen exceptions. These are all good reasons why, regardless of how good the system is from the cryptographic standpoint, encountering a website taking advantage of SSL client authentication remains a fairly infrequent experience. As a result, the method is largely unknown to the majority of end users. Hard Tokens The key difference between client certiﬁcate management in the corporate environment and in external customer-facing applications is in the degree of control that an authority can hope to exercise on the client machine. We explored in the preceding two sections how this difference can often be the key factor in the feasibility of the approach. However, there are situations in which, from the IT governance perspective, the line between employee and customer blurs.

Although you can choose with which bank you want to open a credit line, when you want to visit a foreign country, you have no options. There is one and only one institution that can grant you travel documents, and that is your government. If you live in a country where the health care is managed by the government, again you need to follow the procedures established by the corresponding institutions. If you are a professional in a cer-

The need for protecting high-value transactions may make the use of hard tokens feasible even with consumers

66

The Problem

tain discipline, there is likely an association that gathers other professionals like you and establishes global guidelines such as those for ethical conduct or the acceptable fares you can charge. The list could go on and on, but the concept is clear. We are all part of a number of relationships where there is a single natural authority (or very few), an obvious stakeholder and service provider that are the de facto owners of a certain aspect of our activities. Those authorities often have grave responsibilities, such as handling citizen identiﬁcation, and hence they experience great pressure to keep their system at a state-ofthe-art security level. This simple fact, coupled with the fact that the exclusive nature of their relationship grants those authorities more freedom in the matter of user acceptance, is serving as a powerful impetus for certiﬁcate-based authentication techniques. Many countries are investing signiﬁcant resources in the creation of electronic IDs for their citizens; other institutions are following suit, devising authentication schemas and electronic counterparts of their traditional service cards. It is in the interest of everybody to make such systems easy to use, and the ﬁnest professionals and resources are being dispatched on the problem. Some might have reservations based on concerns about privacy and choice. However, if in the end your country decides that from now on you must use a certain technology for obtaining your marriage certiﬁcate, you better learn how to use the system. To be fair, the technology behind the electronic IDs is experiencing a powerful boost also in other, less-constrained contexts; as the failures of the password-based systems become more evident, the need for exploring alternatives becomes more pressing. We will stick with the electronic ID example because it exempliﬁes the phenomenon well. We are currently experiencing a Cambrian explosion of electronic IDs (eID for brevity): different form factors, different tech-

The Babel of Cryptography

67

nologies, different intended usages, different requirements, and different security guarantees. There are USB thumb drives with ﬁngerprint readers, plain smartcards, small number generators, simple external storages, and so on. What’s relevant in our context is the usage of certiﬁcates on eID. Again, there are many different ﬂavors in this category alone. For the sake of our discussion, we consider only those functionally equivalent to smartcards (including smartcard themselves). We already described the technicalities of smartcard usage, and hence we can concentrate on the special features of applying this technology to the case in point. Here we have all the same problems we had with smartcards outside of a corporate environment. Those are not unsolvable problems, just very expensive ones. Actually, we also have some new challenges induced by the intended usage of eIDs. Our discussion of client certiﬁcates so far has worked on the implicit assumption that the certiﬁcate is just the active part of the user credentials, while the account (hence the identity) would live on the machine offering the requested service. In other words, the requested service would be under the control of the same authority that emitted the credentials. This does correspond to what happens in the ofﬂine world when we make a request of a certain business, such as withdrawing money from an ATM. The machine will verify our bank card and our PIN. Unfortunately, it is a less-accurate model for scenarios in which our credentials are more general purpose. You can show your ID to the police ofﬁcer who is going to ﬁne you for exceeding the speed limits, and you can show the same ID to that bartender in Minnesota who needs to know if you’re over 21. Although the former scenario may involve use of a service that would be considered a government asset, the latter scenario certainly does not. To bring the paradigm back to the online world, a website representing the ofﬁcer may have just checked the signature on your ID and checked back on the government backend as to whether you are entitled to drive, whereas the bartender website would only be able to check that your credentials are actually yours and

Despite the different form factor, hard tokens have the same certiﬁcate lifecycle problems as smartcards

68

The Problem

emitted by a certain state. Not having access to your identity, stored in the inaccessible government backend, the bartender website would have no way of establishing whether you are 21. This is another form of “hostage identity” we mentioned in the section “HTTPS, Authentication, and Digital Identity”: Substituting passwords with certiﬁcates gave us a much safer kind of credentials, but the same distinctions between credentials and identity still apply. Using hard tokens as electronic IDs entails interesting challenges

The usage required by some kind of eID simply cannot follow the state of things as exempliﬁed in the previous paragraph. The eID must enable its bearer to communicate facts about him as statements endorsed by the issuing authority. That is the sheer raison d’être of documents in the ofﬂine world, and the electronic counterparts are no exception. As a result, such statements must be somehow embedded in the eID. Because there’s not always room for them directly in the certiﬁcate, a common solution consists of storing on the eID a data fragment, signed by the CA associated to the eID issuer, containing the desired information. Such a data fragment must be signed by the authority for enjoying the same trust as the certiﬁcate itself. However, it cannot be encrypted speciﬁcally for any service. At the issuance time of the eID, the target services are not known, exactly like you didn’t know which countries you would have visited the day in which you got your passport. What works for ofﬂine documents does not necessarily hold for electronic ones. In the online world it is much easier to copy data just by seeing them once, while at the same time it is much harder for the user to understand what is going on in terms of information ﬂow. As a result, the system is prone to abuses, and the privacy of users can be at risk.

Even if a system standardizes on the use of certiﬁcates, certain aspects may still prevent interoperability

There is another problem associated with data: Just as there’s no clear way of storing assertions on a certiﬁcate, there’s not a place for the data in protocols either. The SSL speciﬁcation mandates where to put the certiﬁcate in the communication streams described by the various phases of the protocol. Everybody who

The Babel of Cryptography

implements this function in his product will be reasonably sure that he will interoperate with everybody else. Things change when country A decides to issue eIDs that contain ﬁrst name, last name, home address, and blood type packaged in a certain way and communicated using a custom HTTP message. The eID from country A will work only with adequate software on the client machine that is able to read the data from the eID and inject it in the right stages of the message ﬂow. The targeted service will also need to be aware of the differences of the approach; otherwise, it will not be able to make use of the incoming data. There are no guarantees at all that country B will adopt the same system or will even be willing to create services that are A-eID aware. There is really no judgment implied about whether the eID from A is better than the one from B. They can both have exceptional technical merits and solve beautifully the problems they were designed to address. Unfortunately, the sheer fact that they are so different is a problem when considered from a global-scale perspective. This, added to the wide variations in form factors and requirements, is a sure recipe for complete incompatibility. Should the hard token idea, as described so far, be truly successful, you would witness rather bizarre scenarios. You would have to bring with you many different devices (the so-called necklace effect) for the numerous services you are a customer of, all requiring slightly or signiﬁcantly different usage and all with different software (drivers and protocols) and hardware (readers, ports) dependencies. Unless a dominant model emerges or a further standardization takes place, the preceding scenario sounds a bit too taxing on users and resources to be likely. Issued Token–Based Authentication Schemes Passwords stand up to certiﬁcate-based authentication schemes like a bicycle stands up to a heavily armored tank. The latter is much more secure, and you can certainly imagine situations in which you would not want to go around with anything less, but it requires such an expensive infrastructure that driving everywhere with it is not really an option.

69

70

The Problem

Certiﬁcates are static

Certiﬁcates are great for handling the identity of resources such as services and websites. Those are fairly static entities accessed by many users; they typically stay online for periods that can be measured in months or years; they have somebody behind them who is motivated to pour money into their maintenance. This kind of usage pattern is well suited to the static nature of certiﬁcates: The information a certiﬁcate conveys, the name of the website, and the cryptography necessary for secure communication are usually enough for a customer to decide whether he wants to do business with it. What are the shortcomings we observed when we applied the same technology to end users? Provisioning and maintenance are difﬁcult, to begin with; then, there’s the matter of the expressive power (credentials versus identity). On the other hand, we were really happy about the use of cryptography; it would be a real pity to forsake it.

Issued tokens can have the same cryptographic strengths of certiﬁcates, yet at the same time be more expressive and much faster to obtain

The preceding considerations, and others not discussed here, led to the great success of the concept of an issued token. A token is in many ways similar to a certiﬁcate. It is a data structure that contains cryptographic material (keys), and it can be associated to known entities. It is, however, usually much more agile. It does not require a ﬁle format or complex stores on disk, it can be issued and used in a matter of milliseconds, it can have an extremely short expiration time, and, perhaps more important, it can contain statements about the entity it has been issued for. It is truly a piece of user identity, packaged in a way that can travel together with service requests; it is also a way of transmitting user credentials, or at least a means of performing authentication operations. The presence of the statements part allows nearly immediate authorization operations, too. A token is not issued by a CA, but by a functional equivalent. The details of the authority that issue tokens will vary depending on the technology used for implementing the scheme.

The Babel of Cryptography

Many network infrastructure software products make use of token-based schemas. After users log in to the network, they are typically assigned by an authority a token that represents their identity in term of their access rights (or information useful to deduce access rights). Every time an account attempts to gain access to a resource, the information contained in the token is combined with the policy associated with the resource itself (often codiﬁed in form of an access control list, or ACL), and an authorization decision is made. This is much more efﬁcient than maintaining a huge list of users and resources in a central location and having to go though it every time an access is made. All of this happens under the constant protection of cryptography, applied consistently at every step. In the section “Kerberos,” we discuss how a technology based on that model works. Those are great advantages. Unfortunately they are improving a scenario, the intranet, that was already in a pretty good shape. In fact, we just explicitly explained what happens when somebody uses a local network after he successfully logged in: The access method, the way in which the user logs on, is not really changed by the fact that the network software is token-based. Understanding the mechanism behind token usage is, however, of paramount importance because it is the ﬁrst evolutionary step toward cross entity authentication. Without tokens, our identity would be doomed to never leave the boundary of the network it has been created for. As you will see in the next two sections and in Chapter 2, tokens are the way of breaking free of the hostage identity problem. We ﬁrst examine Kerberos, a protocol that uses tokens mainly in the context of a local network; then we take a quick look at the Liberty protocol, which builds on the idea of tokens for extending the reach of user identities beyond the boundaries of their home network. We enumerate the merits of those technologies, and we try to pinpoint the reasons why they are still not the ideal universal system for handling identities on the Internet.

71

Tokens are very popular in network software

72

The Problem

Kerberos is a widely adopted technology

Kerberos Kerberos is the name of an authentication protocol, originally developed by the Massachusetts Institute of Technology (MIT) in the 1980s and today widely adopted by many products and operating systems. Windows has used it since Windows 2000, Apache uses it, Mac OS X uses it, Cisco uses it, and so on. Its three decades of success are a proof of its efﬁcacy.

After all the cryptography legwork we have done so far, understanding how Kerberos works will not be a problem. We need, however, to establish some terminology before proceeding. Principal, realms, KDC, and tickets are the basic entities and concepts behind Kerberos

In Kerberos terms, a principal is just everything that can be authenticated or that requires authentication before being used. This is a blanket deﬁnition that covers users, resources such as applications and services, practically everything that can participate at either end of an authentication transaction. Principals are grouped in realms. (Those familiar with Windows terminology can think of those as domains.) Every principal in a realm is assigned a symmetric key. Such a key is known only by the key owner itself and by a central service known as the Key Distribution Center (KDC). The KDC knows the key of every principal. In a nutshell, the KDC is the authority that is involved every time a principal needs to authenticate for using another principal; the currency used in the operation is a security token, which in Kerberos terms is called a ticket. We can use once more the help of our friend Alice for understanding, at least in general terms, how the Kerberos protocol works. Alice owns an account in our Kerberos realm; she wants to access service B, also a principal in the same realm. 1. Before everything else, Alice needs to log into the sys-

tem. She accomplishes that by sending her credentials to the authentication service (AS), a component of the KDC. “Sending her credentials” is not actually accurate, but it should be enough for the purpose of the discussion.

The Babel of Cryptography 2. If the AS recognizes Alice as a principal in the realm, it

sends back to her two pieces of data:

A symmetric key that will work as a session key for all future communications between Alice and the KDC. Such a key is encrypted with Alice’s own key, so man-in-the-middle attacks would be ineffective. Actually, all subsequent communications from Alice will target a component of the KDC, the ticket granting service (TGS). You can think of the TGS as the authority that can issue security tokens (that is, tickets in Kerberos terms).

The same symmetric session key, this time encrypted with the key of the TGS. This speciﬁc data fragment is a ticket, a token that can be used for talking with a service. Because the service for which this ticket is intended is the TGS itself, we call this special token a ticket granting ticket (TGT). Because the TGT is encrypted for the TGS, Alice (or anybody else) will not be able to see its content; she will have just to keep it somewhere and attach it in future conversations.

Understanding the role of the TGT is easy. Imagine that Alice is entering a theme park. As she enters the facility, she pays for an all-day ticket that allows her to take many rides through the day without paying more. This is her TGT. Every time she wants to go on a certain ride, she will go to the line to the local ride ticket counter. When she reaches the cashier, she will have just to wave the TGT to get the ticket for the ride she is about to embark on. 3. Alice now has a session key for talking with the TGS and

a TGT. She then uses the former for requesting a new ticket for accessing B; she includes the TGT in the request.

73

74

The Problem 4. The TGS veriﬁes the content of the TGT using its own

key and then applies authorization logic on Alice’s account. If it turns out that Alice has the right to access B, it sends back the following data fragments:

A new symmetric session key intended for communications between Alice and B. Such a key will be encrypted with the Alice-TGS session key.

The same new symmetric key, this time encrypted with the secret key of B. This is the client/server ticket that Alice will attach to communications with B.

5. Finally, Alice is in the position of authenticating herself

with B. She will send a communication to B using the symmetric session key acquired in the former step, and she will attach the ticket she just obtained for B. 6. B will verify the content of the ticket presented by Alice,

and if it can provide the requested service, it will start its session with Alice. The process is summarized in Figure 1-16. The preceding sequence purposefully ignores many details, including the clever usage of timestamps for keeping the protocol safe from reply attacks and other abuses. The purpose of the preceding description was to show how the idea of ticket, or token, coupled with the availability of an authority (the KDC) can truly secure interactions and support identity-based decisions directly at the resource, by propagating information otherwise available only at a central location. Tickets can contain arbitrary data and are encrypted onthe-ﬂy so that only the intended recipient can consume them

Remember when we tried to use certiﬁcates for client authentication? The few data we were able to embed in the certiﬁcate was the data available at the moment of issuance. In the Kerberos model, in which a ticket is generated anew all the time, we can guarantee that information is always as fresh as it can get. Furthermore, we can embed arbitrary information or

The Babel of Cryptography

KDC 1

E E 3

E E

AUTH

AS

2

TGS

TGS B

Ticket for Bob?

E E

4

B

E

Want to Talk?

E Figure 1-16 Service B.

Kerberos authentication schema: Alice attempts to use the

even reﬂect authentication and authorization decisions just by emitting or not emitting a ticket upon request. The best part of all this is that we didn’t have to give up security for obtaining such agile features. Every leg of the schema previously described is properly secured. We can even overcome some of the security weaknesses we encountered in the section “Hard Tokens.” When we discussed the eIDs and the need of supplying declarative information about the bearer of the hard token, we encountered the problem of not knowing in advance which services the eID will be used for. That lack of knowledge prevented a proper encryption strategy of the declarative data. With

75

76

The Problem

the ticket model, the session keys are dynamically negotiated every time; furthermore, the data about the user is handled directly by the KDC. This means not only that we have a means of circulating identity information on demand, but that we can also make sure that every time the data will be encrypted to the exclusive advantage of the intended recipient! We are really getting close to solving many of the problems we encountered so far. Kerberos works very well in a local network but does not model well the pluralism of authorities on the Internet

Unfortunately, Kerberos is not the universal solution we are looking for. Its omniscient KDC, the key pillar of the entire architecture, is not a concept that scales to the Internet. Furthermore, Kerberos is a fairly low-level protocol. Although all implementations of it share the common ideas and architecture described previously, many small differences and added-value services make ready interoperability rather difﬁcult. Even if the wire interoperability were easier than it is, the granularity suggested by the concept of principal is too ﬁne to be practical across loosely coupled business partners. Despite the limited extensibility beyond corporate and business-to-business scenarios, the threeheaded architecture (user, KDC, service) introduced by Kerberos is an important step in the process that will eventually bring us to truly portable identity. Fins are looking more and more similar to legs at this point. SAML The Security Assertion Markup Language, or SAML, made its appearance as the OASIS standard in 2002 but gained the most momentum in 2003, with the ratiﬁcation of version 1.1 of the speciﬁcation. The current version of the speciﬁcation, SAML 2.0, represents convergence with other technologies and extends its original scope. For the sake of this section, we focus mainly on SAML 1.1.

The Babel of Cryptography

77

One of the main reasons for the emergence of SAML in the ﬁrst place was the pressing need of addressing cross-domain Web single sign on. Single sign on, or SSO, can be deﬁned as the capability of accessing multiple resources that require authentication while requiring the user to go through the authentication experience only once. One common trick used to achieve SSO with browser-based applications consists of saving a special cookie upon successful authentication. All subsequent applications will just verify the presence of such a cookie and avoid prompting the user for credentials if they ﬁnd it. Unfortunately, the trick doesn’t work across domains. An application belonging to a certain domain cannot read cookies written by applications running on another domain. This simple fact prevented companies from using the cookie method for achieving SSO with business partner websites. As a result, many different (and incompatible) technologies were devised for addressing the issue.

SAML was designed for resolving the cross-domain single sign-on problem

The SAML solution to the problem entails the creation of an authority, called the SAML authority or asserting party (AP), which can state security assertions regarding a principal. An example of such an assertion may be “Alice is a principal in my realm, and she just successfully logged in using username/password as credentials.” Such an assertion can be presented by Alice while she tries to gain access to a service offered by another realm. The target service, known in the SAML schema as the relying party (RP), can use the assertion for acquiring information about Alice and, depending on whether it trusts the AP and on the local authorization policies, can make an informed decision about granting or denying access to Alice.

SAML introduces the concepts of asserting party and relying party

In SAML the term assertion has a very speciﬁc meaning. It is a special Extensible Markup Language (XML)–based format, precisely described by the SAML speciﬁcation, which is designed for transporting security information. It can contain authentication statements (Alice signed in using authentication method x), attribute statements (Alice belongs to the Managers group in the

78

The Problem

AP realm), and other kinds of assertions. The result is an extremely ﬂexible and powerful tool for describing a digital identity or parts of it. The choice of using XML pays off in terms of interoperability and avoids the pitfalls we observed in Kerberos. The SAML speciﬁcation deﬁnes the format for assertions and a protocol for sending them around

The rest of the SAML speciﬁcation (protocol, bindings, and proﬁles) deals with the details of how to request an assertion, how to embed assertions in existing protocols and transports, and how to address speciﬁc scenarios such as how to solve the browser SSO by passing an assertion by value or by reference. The details of the SAML speciﬁcation, such as all the different browser redirects that may occur while issuing and propagating an assertion, can be fairly complex and are beyond this scope of this discussion. If you want to learn more about SAML, see the excellent ofﬁcial documentation provided by OASIS. You can ﬁnd it at www.oasis-open.org. Did we ﬁnd the ultimate way of handling identity on the Internet? Unfortunately, we’re not there yet. SAML is certainly a better Internet citizen than Kerberos ever was. However, it still contains a number of characteristics that prevented its wide adoption at the end-user level. The AP looks much more agile than the KDC, but it also performs fewer functions. The AP can state assertions about Alice that can be understood outside its realm, but there’s no direct management of the cryptography aspect. In the browser scenarios, SAML relies on transport security. That is, it assumes that every communication will be protected by HTTPS. We have seen how this does not necessarily guarantee that the user will be comfortable with it.

The Babel of Web User Interfaces

79

Furthermore, SAML came out as something intended for addressing business-to-business transactions. This is reﬂected by the fact that many sequences imply direct communication between the AP and the RP. Many of those communications will be possible only if the two parties are already tied by a business relationship that goes beyond just sharing the same semantic for the same attribute statements. Such a situation is unfeasible on the Internet, where dynamic aggregation centered on user decisions is a common pattern. A tightly coupled relationship is costly to initiate and maintain, and therefore it is used when it makes solid business sense. A user can’t possibly hope that all the services he will ever have to authenticate with are in tightly coupled relationships with each other or with a single AP.

SAML tends to leverage business relationships that usually do not apply to single users

The last point we want to make is something that applies to every authentication technology mentioned so far. Regardless of all its merits, SAML is just one technology among many. It has enjoyed very good adoption, but even in the business-to-business space it is far from being the de facto standard. It shares this space with many other SSO technologies, and it’s not certain at all that one solution will ever emerge over all the others.

Convincing everybody to standardize on a single technology is very difﬁcult

The Babel of Web User Interfaces The communication protocols on which the Internet is based do not address the problem of transporting credentials. While exploring this issue in the section “HTTPS, Authentication, and Digital Identity,” we highlighted the fact that the most notable consequence of such a shortcoming is that credentials handling is currently a responsibility of the application developer. We have seen how this simple fact promotes strong differentiation in the feature sets of libraries and components; in this section, we discuss the impact it has on the interactions with the end user. We also consider user perception in general and how

80

The Problem

the feeling of not being in control of the situation affects people’s trust in online systems in general. How can the user make sure that the page he is looking for is the one he intended to visit?

In the section “HTTP and HTTPS: The King Is Naked” we have seen in extreme synthesis how the Internet works: You type an address, and the browser takes care of requesting the corresponding page and rendering it. URLs are one of the few indications of “where” the user is (that is, where the page currently rendered in the browser comes from). Actually, there’s often no need to type addresses. Search engines, links, and bookmarks can point the browser in the right direction without forcing you to type extra long and largely meaningless URLs. As a result, the average user might not pay a lot of attention to addresses or get a lot of meaningful information from them. What is the most obvious visual clue users leverage to determine where they are? The rendered page itself! Unfortunately, it is very easy to replicate the look and feel of a legitimate page on a fraudulent server. There’s more: The replica does not even need to be that accurate, as we explain next.

A familiar environment offers certain “landmarks” that the user can leverage for understanding what is going on

When you enter your credentials in Windows, both for accessing the machine or for performing privileged operations such as accessing a network share, you expect the username and password dialog to have a certain look and feel. If you are prompted by a dialog that is even slightly different from what you expect, there is a very high chance that you will notice that something is not right. This knowledge will help you to assess the risk and make decisions such as not entering your credentials and seeking the attention of the system administrator/computer savvy spouse/teenager of the household. Such a good property is by no means inherent to Windows itself, but it’s quite the result of the consistency derived from the fact that authentication is managed at the common infrastructure level (in this case, the operating system) rather than left to every application. In the case of a Web browser, both the UI and the application functions are generated on the basis of the code of the Web page itself. This

The Babel of Web User Interfaces

81

means that the rendered UI can be wired to literally any logic; it’s like a world where the application creates its own laws of physics. If the authentication functions are part of that world, with no inﬂuence from elements living outside the rendering area of the browser, there’s no way for the user to know what will really happen to the data he will type in. As stressed at the beginning of the section, credential gathering on the Internet is something that has to be dealt with at the application level. If it has to be a feature of your application, of course you want to be free to adapt the look and feel of the credential-gathering controls to the overall style of your application! So if all your controls have a border 7 pixels wide and left-justiﬁed, your username and password ﬁelds will follow suit. Apply the same reasoning for the entire Internet, and you’ll have countless different user experiences just for typing in a username and password. There is some common pattern almost universally adopted, such as the presence of two text boxes for username and password, but that is pretty much it. The result is that if there’s no regular pattern, the user is trained not to search for one. The user loses his capability of being surprised. There are no visual clues in the credential-gathering experience warning the user that a certain page “has something wrong.” This is one of the key loopholes in today’s e-commerce practice that makes phishing so successful.

The Internet experience is just too diverse for offering clues that are consistent across websites

We have seen how certiﬁcates and token-based technologies do a better job at handling identity than shared secret techniques such as passwords. From the interaction point of view, however, they may end up being more challenging to use for humans. There is not a common visual entry point for handling nonpassword credentials; here it actually is a solutions tower of Babel. Very often, hard tokens and smartcard have their own drivers, which must be installed explicitly. This is due to the nature of the devices themselves and is an issue that can be mitigated but probably not completely banished. Imagine a world in which such devices are widespread, and the user has to juggle tens of

The use of hard tokens does not entail, as of today, a uniform user experience across models and vendors

82

The Problem

them for managing many different accounts (we discussed the possibility toward the end of the section “Hard Tokens”). The many different user experiences would compete for the user’s proﬁciency and recognition abilities, without common grounds through the different interaction patterns. Just as for the Web UI for usernames and passwords, there would be no selective pressure forcing the device vendors to converge on a common experience. It is again a problem in which it does not really matter how good individual solutions are because the issue lies in the sheer number of solutions rather than in their speciﬁc merits. So, users cannot make trust decisions just on the basis of what a UI looks like. So what? you may say; in the ofﬂine world, you don’t make decisions about what your bank clerk looks like. The metaphor is not entirely accurate, but let’s assume for the sake of argument that it makes a good point. What is the key difference between operating a home-banking Web application and asking a clerk to deposit a check in your account? It is the reputation of the place where the action happens. You trust the bank as an institution because of its reputation, and you assume that those who work there are trustworthy, too (at least to the extent of the business you want to conduct there). Being physically in the bank allows you to assess risks in a satisfactory fashion, whereas the average user is nearly clueless about the actual location and true identity of a website. It is this conscious cluelessness that poisons the conﬁdence of users, sometimes to the point of inducing them to cease all online transactions. A system can be cryptographically strong, but it will not be effective if the end users don’t understand it

To be fair, there is a mechanism in place that is actually intended to assess the identity of a website. In the section “HTTP and HTTPS: The King Is Naked,” we introduced HTTPS, and you have seen how associating a certiﬁcate to a website takes care of publishing the public key of the website itself. The certiﬁcate is securely tied to the website because it contains a reference to its URL in the subject ﬁeld. We can consider the certiﬁcate itself a trustworthy source for assessing the identity of the website. The subject ﬁeld usually contains other info that

The Babel of Web User Interfaces

83

could be useful for identiﬁcation, such as the geographic location of the company it was awarded to. There is also information about the certiﬁcate-issuing authority, again useful for assessing the level of trust that a certain website deserves. Unfortunately, the last three or four sentences are all gibberish for the vast majority of users. Try to explain this to somebody who does not work in the IT industry, and be prepared to be rewarded by a blank stare. Certiﬁcates as they are used today require an understanding of the Internet, both in term of technology and in terms of reputation of the main certiﬁcation authorities, an understanding users not belonging to the technorati elite simply don’t possess. This state of being is not an accident or a temporary condition. Although it is legitimate to hope for heightened sensibility toward security in the general public in the future, making the Internet difﬁcult to use needlessly limits access to one of the most formidable resources available to mankind. There are isolated attempts to solve in alternative ways the server authentication problem. For example, one proposed solution lets the user choose at registration time a speciﬁc image; during subsequent logons, that image is shown after the user types in his username but before typing the password. In this way, the user will know that the website is actually the one with which he performed the original registration because any impostor would not know which image was selected at signup time. This is a very clever solution, but it is one among the many possible. There are no guarantees that others will adopt it, too, and in fact businesses in which trust has to be established from the very ﬁrst contact would not ﬁnd the scheme advantageous because it works on the assumption that the registration phase is safe. Such businesses will come out with their own clever solution, and the user proﬁciency will be strained beyond its limits in the attempt to master all those clever but diverse systems. For the third time in the current section, we encounter a problem

Countermeasures can be locally effective, but ultimately they have to compete for the proﬁciency of the user among a sea of equivalent offers that impose different procedures

84

The Problem

that cries for a global answer instead of being solvable by the emergence of an approach over the set of all individual initiatives.

Summary It has been a long chapter. We started by observing how the value of the things we can do with computers steadily rose through the last decades, culminating in today’s Web economy. We have studied attacks and motivations behind the simpler, early crimes against property and resources; we analyzed in some depth how vulnerable our data is on the Internet, and came to understand the basic principles of the arms race between cybercrime and countermeasures. We have seen why protecting your identity online is important, and we gave some measure of how brittle and broken today’s practices are. We devoted an entire section to analyzing the merits and shortcomings of passwords, understanding why they are the most used authentication method today and why they are also perhaps the worst kind of credentials we can ever use on the Internet. We started searching for viable alternatives among the credential technologies currently available. Equipped with a solid understanding of the cornerstones of cryptography, we learned the difference between securing a communication and propagating an identity. We took a look under the hood of HTTP, the protocol that accounts for the vast majority of communications on the Internet and discovered that it does not feature any speciﬁc place for plugging in authentication technologies. We learned about certiﬁcates and issued security tokens, understanding why they are so effective for addressing the scenarios they are meant

Summary

for and why they fall short as a means to address the requirements of a truly universal authentication protocol. Finally, we focused on the needs of the end user. By observing how today’s anarchy in the credential-gathering user experiences neglected to properly take into account usability and trust establishment, you saw further proof that a truly global solution is unlikely to come from an individual initiative rising above all others. The problem of digital identity management is a complex one. Its roots go deep in the history of information technology, and seemingly unrelated aspects reinforce each other in ways not immediately evident. The growth patterns of the Internet itself and the interests of the various parties involved prevents spontaneous solutions from appearing. Now that we have a deep understanding of the many faces of the problem, we are also well equipped to recognize whether something is a valid solution. It the next chapter, we consider the issues here in constructive and creative ways, cleaning the slate and rebuilding from the ground up. We describe a robust, sustainable, widely accepted, user-friendly, future-proof solution to the problem of digital identity management.

85

This page intentionally left blank

2

Hints Toward a Solution Now that we understand how today’s security schemas work and how they evolved to their current state, we realize the reasons why they fall short in providing a common identity layer for the entire Internet. It is time to put into practice the lessons learned and devise a long-term solution, ﬁnally immune from the errors and shortcomings that afﬂict today’s patchwork of partial solutions. The section “A World Without a Center” stresses the reasons why a universal identity layer didn’t spontaneously emerge to date and highlights that a truly sustainable solution must address the needs of all the disparate parties that have an interest in the Internet. The section “The Seven Laws of Identity” describes the choral effort that the industry poured into determining the mandatory requirements that must be met by any acceptable solution to the online identity problem. The seven laws of identities are a compact formulation of those ﬁndings.

87

88

Hints Toward a Solution

The section “The Identity Metasystem” presents a model for describing roles, transactions, and relationships of systems in which identity information is exchanged. The section explores the expressive power of the Identity Metasystem and its soundness, describing how its various parts can be composed for handling different example scenarios in ways that are fully respectful of the identity laws. The section “WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem” provides a brief overview of the advanced web services speciﬁcations, positioning the trend in the industry landscape and delving into the details of some especially relevant speciﬁcations. After all the pertinent details have been spelled out, the text shows how the abstract constructs in the Identity Metasystem ﬁnd a concrete counterpart in the web services world. A sustainable solution for the online identiﬁcation system has ﬁnally been found, and the technological means to put it into practice are already mainstream. The section “Presenting Windows CardSpace” positions Windows CardSpace in the Identity Metasystem, explaining its role and its relationship to the other components of the solution. By the end of this chapter, you will understand the Identity Metasystem, how it works, why it is the way it is, why it can aspire to be a global solution, and why former attempts fell short. The Identity Metasystem is the ecology in which Windows CardSpace is designed to thrive. Gaining a solid understanding of the model is the best way to learn how to take advantage of this new technology.

A World Without a Center

89

A World Without a Center The fabric that keeps the Internet together is fairly simple from a technical standpoint. You saw in the preceding chapter how the content-publishing infrastructure (browser plus web server plus HyperText Transfer Protocol [HTTP]) proved ﬂexible enough to be twisted in the wide gamut of online applications we see today. You have also seen that security concerns, speciﬁcally about identity, are a serious seatback for the activities involving high-value transactions. The technology for addressing those concerns, or at least signiﬁcantly mitigating them, already exists. We took the time to understand strengths and inadequacies of the main authentication schemes, and it’s clear that cryptography and token-based schemas have the potential to provide a technical solution to the problem. In fact, for the most part, the problem is not technical at all.

HTTP is the collagen of the Internet

The reality is that the Internet is just an enabling infrastructure. It is the stage to an incredible number of different dramas, all involving different actors with their own agendas. Every service provider runs his or her interests on the Internet for his or her own reasons, according to his or her own business model and practices; and unpredictable new business models thrive and decline at stunning pace without central supervision or governance of sort. (At the time of this writing, the huge success of twitter.com is bafﬂing old-school analysts.) The concept of identity plays a key role in every service or activity that provides or manipulates value. It should not come as a surprise that every business wants to exercise control over the way in which identity is managed for their assets so that they can ensure that it is inline with their business goals. Different businesses will have different expectations from identity management. An enterprise giving remote access to its employees will want to make sure that access levels are enforced, striking the delicate balance between ease of access and security. The same enterprises, when offering online services to customers, will have a different

The Internet is a means to many ends

90

Hints Toward a Solution

agenda. Customers will need to be authenticated with the right security assurances, sure, but the highest-order bit will be how to capitalize on relationships, retain customers, achieve loyalty and prevent departures, leverage customer proﬁles for improving sales or selling info to marketing ﬁrms, handle privacy and regulation concerns, keep user-proﬁle data fresh, and many other considerations. Those are all business goals that can deeply affect how customer identity is handled from the technical standpoint; furthermore, any operator will give different weights according to the kind of service they provide. Just think of the use that Amazon.com would make of its user proﬁles, as opposed to matchmaker businesses such as eHarmony.com. That’s not all. As the usage of new technologies rises in government functions and practices (the so-called eGovernment), institutions expose more and more of their operations to online consumption. Their view of identity is inﬂuenced by the existing relationship they have with citizens, and the assurances they have to provide must be inline with the ofﬁcial function they are called on to accomplish. Controlling how identity is managed is appealing to many

The different ways in which identity is deﬁned, exchanged, and manipulated in a certain transaction deﬁnes a context. As mentioned previously, everybody has a strong interest in controlling the identity context in his or her transactions. For that reason, the absence of a constraining standard is exactly what allows businesses to adopt their own solutions. Chapter 1, “The Problem,” is full of examples of those identity one-offs. The Internet does not have an identity layer, and this is one of the key reasons behind all the problems we have with authentication today. But if the Internet did have a native identity layer, and it was not expressive enough for allowing businesses to enforce their requirements, it would be reasonable to expect the rise of proprietary alternatives. Back to square one. The different views on what identity is or what an identity layer should do are the reason why a common solution didn’t spontaneously arise, and it is not plausible to expect this to happen

A World Without a Center

91

anytime soon. Perhaps more important, that is also an indication of what a universal identity layer should look like. It will need to have enough expressive power so that present and future businesses will be able to use it according to their needs; otherwise, it will face the same fate of existing schemes. Although services providers are a very important part of the equation, they are not the entire story. User acceptance makes for the success or the failure of many online services. Systems have to walk a thin line between ease of use and security assurances offered; context information considerations, such as how private is the data being exchanged at the moment, are powerful inﬂuencing factors for pulling opinions on one side or the other of that line. We have seen in Chapter 1, in the sections “Passwords: Ascent and Decline” and “The Babel of Web User Interfaces,” how users have trained to cope with inefﬁcient and insecure systems. The consequences of those shortcomings are often felt at moments apparently unrelated to the authentication experience, such as when you spot an unauthorized purchase days after the last home-banking transaction. Hence, the user is not always able to recognize the causal link between aspects of a bad authentication system and the issues it causes. Add this to the difﬁculty the user has when trying to ﬁgure out what is going on during a transaction (such as whether the website rendered in the browser is truly the intended one). This is another facet of the problem that a common identity layer has to solve. It has to offer a user experience that is acceptable, and at the same time it has to protect the user interests without getting in the way.

At the end of the day, it is user acceptance that makes or breaks the system

The Internet does not have a center. This claim can be supported from many points of view: no common governance, many service providers with different agendas, and a mindboggling number of users who often defy attempts to partition and classify them. All of those entities want a say about how identities are managed, and rightfully so. Any truly sustainable solution must address their concerns. That is the minimum bar for entertaining any hope of a strategic solution to the problem.

The Internet does not have a center

92

Hints Toward a Solution

The Seven Laws of Identity As we have seen consistently in Chapter 1, a common mistake in the evolution of the IT industry has been trying to extend the use of existing technologies “as is” to deal with problems that are only apparently similar to the ones the original technology was meant to solve. A strategic solution often requires restarting with a blank slate

Breaking this impasse requires distancing ourselves from the tools we (maybe erroneously) believe we may use for solving the problem and trying to consider just the problem itself. By doing so, we might not get an instant solution, but we can certainly obtain precious and unbiased insights into what an acceptable solution may look like. At least as important, we can also learn to recognize nonsolutions. By understanding what the properties are we can’t do without, we gain a valuable compass for navigating the problem space toward a solution.

Cameron ignited the debate about identities with a public blog

Kim Cameron, an architect at Microsoft, tried to do exactly that. In 2004, he created a blog, www.identityblog.com, from which he elicited discussions on identity management. The focus was on understanding what worked and what didn’t in current and past identity management efforts, with an accent on understanding the deep reasons for why things went one way or the other. Issues were examined from multiple angles: technology, social considerations, usability, and privacy. Vendor differences were suspended in the name of understanding the problem from a broad industry perspective. No topic was off limits; in fact, one of the most studied topics was the shortcomings of the most ambitious universal authentication scheme attempt at the time, Microsoft Passport. Cameron successfully involved key industry players and thought leaders from the entire community in the dialogue, gaining consensus even from the least expected sources, such as prominent ﬁgures in the open source world.

The Seven Laws of Identity

In 2005, Cameron distilled the results of the discussions in a single white paper, “The Laws of Identity,” where the main ﬁndings are summarized in concise format. The white paper lists seven “laws.” They are principles to which, according to the previously mentioned investigations, an identity management system must comply to be viable. Since the white paper’s publication, the identity laws have become immensely popular and are considered by many the manifest of the new user-centered identity management movement. The seven laws, listed in their concise form, are as follows:

93

The “Laws of Identity” white paper summarizes the ﬁndings of an open, industrywide conversation

1. User Control and Consent 2. Minimal Disclosure for a Constrained Use 3. Justiﬁable Parties 4. Directed Identity 5. Pluralism of Operators and Technologies 6. Human Integration 7. Consistent Experience Across Contexts

The identity laws are not dogmatic by any measure, nor are they blindly prescriptive. Ultimately, they are a set of sound and pragmatic principles, derived from real-world experience, that anybody can verify at any given moment. Their goal is to give rise to a system that can enjoy true acceptance while serving the intended purpose of an identity system to the full satisfaction of all the parties involved. The seven identity laws deﬁne how to successfully extend the Internet with an identity management layer. In the remainder of this section, we examine the laws one by one. In the following section, “The Identity Metasystem,” we describe a solution that abides by such laws. The Identity Metasystem is the model of reference for which Windows CardSpace has been designed.

The laws of identity are not dogmas. They derive from very practical considerations

94

Hints Toward a Solution

The Seven Laws of Identity and the Four Tenets of Service Orientation If you are familiar with service orientation, here is an analogy for you. To some extent, the seven identity laws are similar to the four tenets of service orientation. The tenet “Share schema, not object” is not an absolute dogma, and no service-orientation police will come to arrest you if you don’t respect it. The consequence, however, is that you will not be able to serve loosely coupled clients that don’t understand your object technology. It is observing exactly this shortcoming that brought on the formulation of the tenet in the ﬁrst place. Similarly, if you develop an authentication schema that mandates one speciﬁc technology, you are breaking law 5 (see “Pluralism of Operators and Technologies”). Nobody among the authors of this book will come to haunt you for that, but you should be aware of the fact that your authentication schema may have shortcomings in certain areas and is probably not ﬁt to become the universal identity management system.

User Control and Consent

Technical identity systems must only reveal information identifying a user with the user’s consent. —The Laws of Identity, Cameron, 2005

This is truly the most fundamental principle of an identity management system. The user must always understand what is going on

The user must be able to decide to whom he discloses information, which speciﬁc data is being shared, when exchanges take place, what the purpose is for which the information is gathered in the ﬁrst place, and what the trail is that a speciﬁc transaction may leave behind. To make that degree of control even possible, the user must understand what is going on. Always.

The Seven Laws of Identity

95

In today’s practices, we witness gross violations of the ﬁrst law everywhere. Remember the concept of server authentication, discussed in the sections “The Babel of Cryptography” and “The Babel of Web User Interfaces” in Chapter 1? The lousy job we do today of making users able to understand to whom they are disclosing information is one of the root causes of phishing, which is by itself one of the main causes in the decline of the use of the Internet for high-value transactions. A violation of the ﬁrst law of this magnitude promptly leads to diminished acceptance.

Today the user is often not in control. The consequences are serious

There are other somewhat subtler violations to consider. We are used to the idea that what we transfer in an authentication transaction is just the credentials so that we can unlock our identity on the service provider. In fact, there are many occasions in which our identity can ﬂow from one service to the other. In Chapter 1, in the section “HTTPS, Authentication, and Digital Identity,” we have a real-world example in which frequent-ﬂyer privileges of a customer are shared between two commercial partners. In the sections “Hard Tokens” and “Issued Token–Based Authentication Schemes” you saw technologies that give to identities a vessel for traveling across different entities, such as the Security Assertion Markup Language (SAML) token representing the assertion, “Alice is a principal in my realm, and she just successfully logged in using username/password as credentials,” mentioned in the section “SAML.” This covers the feasibility of the operation from the technical standpoint but says nothing about the way in which what is happening surfaces to the user’s attention. Let’s say that you are working for an important technology company that has a close partnership with a hardware provider. By virtue of that partnership, purchasers at the hardware vendor site enjoy automatic deals applied speciﬁcally for your company. The experience is seamless. While you are browsing your corporate intranet, you click a link to the hardware vendor, and the web store automatically recognizes you as an employee of a partner company; you get a welcome banner with your name, and the deals on the

Even single sign-on systems may hide violations of the user in control principle

96

Hints Toward a Solution

page are adjusted accordingly. That’s the magic of single sign-on (SSO; see the section “SAML” in Chapter 1). Sometimes the transition may be so seamless (thanks to layout customizations) that you might not even realize that you are now in a different place and that an authentication step has been performed at all. That might be very convenient from the usability standpoint, but you can’t say you had much control over the information about you that ﬂew from your company to the hardware vendor website. From what you can see, the partner website was able to determine your name and your status of employee. But what if much more information was transmitted without your knowledge or consent? If the hardware vendor acquires information about your salary or your home address, something that typically you would not want to disclose, consequences vary from targeting according to the advertisement on the web store to selling that information to marketers, junk mailers, or worse, burglars. Wouldn’t it be much better to be warned that your identity is about to be disclosed and to whom and what information is speciﬁcally being requested? Wouldn’t you require, after you realize what is going on, a mechanism for opting out if you feel it is risky? That’s the essence of the ﬁrst law. Knowledge is power. Awareness of the situation brings the ability to take action responsibility, which in turn brings conﬁdence and the feeling of being in control. Minimal Disclosure for a Constrained Use

The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution. —The Laws of Identity, Cameron, 2005

Let’s focus once more on the partnership example we introduced in last section “User Control and Consent.”

The Seven Laws of Identity

Your company negotiated access to the hardware vendor website to fulﬁll a business need, empowering employees to purchase devices for the company with a process as agile as possible. The purchase process needs to gather some speciﬁc data from every shopping session. The fact that you are an employee of a certain partner, your name, the business address to which items will have to be shipped, coordinates for emitting an invoice, the spending limit that has been assigned to you or to your role. Omit any of those data, and the transaction cannot take place. Do they need to know your salary? Your home address? Your blood type? You religious beliefs? Your hair length? They would probably be happy to have some of that information, but the answer to all these questions is a resounding no. The reason for which you are shopping at their website is performing purchases for your employer. The fact that you are a geek and that later that night you will buy an oscilloscope for your personal enjoyment is not relevant now, and therefore your home address should not be part of the current transaction.

97

The “need-to-know basis” principle applies to identity

Even if the hardware partner is acting in good faith and does not sell your personal data to junk mailers, disclosing more data than necessary is still a very bad idea. A rich archive of personal details is a treasure trove for identity rogues and makes the company a very palatable target of attacks. The liability is also higher in case of accidents. A laptop forgotten on a train with a list of names plus company addresses is much less likely to unleash a class action lawsuit than the same list of names with home addresses, birth dates, and so on. The principle of minimal disclosure can and should also be applied at a ﬁner level of granularity. A business selling wine, in a country where alcohol consumption is allowed only after a certain age, may be tempted to store the birth date of recurrent customers. That is a point of liability that could be easily avoided because it is possible to store only the aspect relevant to the business (that is, a Boolean expressing if the customer is above or below the threshold age).

Incorrect disclosure of data can have negative effects even a long time after the event occurred

98

Hints Toward a Solution

A negative example: How the Social Security Number is handled in the United States

Unfortunately, today’s identity silos often invite practices in open violation of the second law. Many business operations in the United States require disclosure of the Social Security Number or SSN (see the sidebar “America and Identity Theft” in Chapter 1). It often happens that the SSN will end up being memorized in the user proﬁle, even if there’s no need to know it beyond the current transaction. It is kept just in case because it is information difﬁcult to obtain. In the most appalling cases, it is even misused as record key because it is a unique identiﬁer. The latter are the worst cases. Not only is the SSN very valuable information per se, it also provides a key for aggregating and interpreting identity data stolen elsewhere! That means spreading the damage across different identity contexts, annihilating one of the only advantages of today’s identity silos. Because it is so difﬁcult for information to ﬂow between silos, the scope of damage is often contained too. The principle of minimal disclosure for constrained use is very pragmatic, and the strategic value of the practice is clear. It is clearly proven architectural wisdom applied to the context of identity. Justiﬁable Parties

Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justiﬁable place in a given identity relationship. —The Laws of Identity, Cameron, 2005

One of the ﬁrst adopters of Microsoft Passport was Victoria’s Secret. At the time, it was not a well-known brand in Italy. When one of the authors found out that it was a lingerie brand, he was puzzled. He spent a good deal of time trying to understand the business reasons for which Microsoft needed to be informed of the details of his Valentine’s day purchases.

The Seven Laws of Identity

Understanding the circumstances requires recalling what the Internet was in the few years after Y2K. Today it is almost unthinkable for any company not to have substantial web presence. In 2001, there were still many important companies without a website, and the bursting of the dotcom bubble had scared the industry enough that they backed off any mainstream strategy related to the Web. Brick-and-mortar companies often didn’t have investments in or know how to invest in web properties: Website creation and maintenance were massively outsourced, almost as experiments and PR bangs, every move clearly giving away that the energies were still on the traditional channels. The Web was not as ubiquitous as today. The demographics of habitual customers, the main target, were not expected to overlap much, from the very beginning, with those of the audience of the website. Web-based campaigns were far from today’s maturity in term of tools, demand, structured offerings, and raw material (read, eyeballs).

99

Internet presence wasn’t always considered a strategic asset

In that atmosphere, it should not come as a surprise that somebody saw authentication just as another “feature” of the website, and as such suitable to be handled by third parties, too. The Passport offering was very convenient because it relieved sites from the hassle of managing their own authentication infrastructure, a very delicate aspect of the website architecture. That was the intended role of Passport in the purchase of a Valentine’s day present; Microsoft was just an infrastructure provider.

Passport was designed as a turnkey system

As the Internet became what it is today, many of the conditions that made authentication outsourcing appealing started to fade. It became unmistakably clear that the web presence is a strategic asset, while at the same time online activities became more complex and feature-rich. The attention and resources devoted to it by companies increased. As the number of Internet surfers

Companies realized that a turnkey system was not always suitable for their interests

100

Hints Toward a Solution

grew an order of magnitude, the importance of the Web as a medium for reaching customers grew, too. Any information about the user became precious for maintaining loyalty, predicting behavior, and targeting offerings. Online advertising exploded. It was like the ofﬂine world, but the eyeball economy made everything faster and global reaching. In these new conditions, in which somebody can earn revenue just by having you look at one page, outsourcing identity management just does not make business sense. That’s why nowadays we are so surprised at the attempt to extend the Passport authentication scheme beyond Microsoft assets, but at the time there was some reasoning behind it. In fact, other big Internet players are betting on similar systems still today while Microsoft endorses the Identity Metasystem (see the section with the same name). While online business went through all those transformations, maturity and awareness in the usage of the Internet increased. Once past the convenience of remembering just a single set of credentials, users and operators began to realize that the web farm of one single operator was in the position of keeping track of all their movements and didn’t like the idea. When the technical reasons for outsourcing authentication disappeared, or were greatly reduced, there was no justiﬁcation for that situation. If you add that some websites tried to make it as unobvious as possible that they were in fact relying on Passport, you can see how users didn’t feel much in control. The presence of a party in a transaction must be justiﬁable to the eyes of the user

In fact, “Justiﬁable Parties” is another ﬂavor of the “User Control and Consent” law. Every time the user discloses his identity information, he needs to be able to assess not only to whom he is sending data, but also understand its role in the current transaction and the implications of its involvement. Let’s get back to the wine seller example we introduced in the previous section. The merchant needs to know whether you are of age before serving you alcohol, and he may not take your word for it. In the ofﬂine world, the natural solution entails extracting your governmentissued ID document and exhibiting it. As we have seen in Chapter 1, in the section “Hard Tokens,” this is an action that

The Seven Laws of Identity

more and more often we can metaphorically perform in the digital world, too. Here the reasons why the government is involved in the transaction are obvious. The merchant needs to know whether I am of age and won’t take my word for it. However, he is willing to believe what the government says about me. Short of ﬁnding another entity that the merchant trusts, if I want to go on with the transaction I have no choice but to accept government involvement. (Notice that I still must be given the choice of opting out, when I learn the merchant’s policy). Again, there are ﬁner points to be made. The user is the ultimate judge of the justiﬁability of the participation of somebody in a transaction, and all information for making that call must be made available. Consider this. What if every time you use your electronic ID, your government keeps track of with whom you are conducting business? Would you still say that government involvement is justiﬁed? It probably depends. Somebody will recognize that this is a necessary security measure if the transaction is applying for a visa with a foreign government, but it is plain abuse to keep record of how many times you buy wine in a month; somebody else will be okay with both; and so on. This is just one among many examples. When was the last time that a marketing company asked for your permission for monitoring your buying habits? The point is that it is the user who should be the one who justiﬁes the terms of the participation of one entity in the transaction, and a good identity schema should do everything for facilitating that judgment call. That means explicitly and clearly communicating policies about information usage. Directed Identity

A universal identity system must support both “omnidirectional” identiﬁers for use by public entities and “unidirectional” identiﬁers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. —The Laws of Identity, Cameron, 2005

101

102

Hints Toward a Solution

The fourth law further reﬁnes the concept we have of digital identity. The intended audience is what deﬁnes the “direction” of an identity

In Chapter 1, we debated the problem of server authentication, and we hinted how Public Key Infrastructure (PKI), certiﬁcates and Secure HyperText Transfer Protocol (HTTPS) can help in pinpointing the identity of websites. Who is the beneﬁciary of that help? In the case of a public website, it will be the “public” itself. Everybody that is not the website itself or, as Kim solipsistically put it in the white paper, “all the other identities.”

An omnidirectional identity deﬁnes the public identity of an entity

We call that kind of identity omnidirectional. It is an identity meant to be understood by everybody. This identity will contain the info necessary for the public to decide if they want to do business with it. X.509 certiﬁcates and associated URLs are the most natural example in this context, but the instances in the ofﬂine world abound. You may have seen at some conferences those badges that display the attendee name, the company he or she is afﬁliated with, his or her role in the conference (attendee, speaker, staff), and the languages he or she can speak. That information is beamed to everybody coming within visual range of the badge and helps everyone else to recognize the bearer and the methods of interaction. The Web 2.0 breeze that blows on the Internet these days brings many means of doing the same thing online. For example, at the time of writing, Opinity (www.opinity.com) offers to its users a unique URL that provides the function of omnidirectional identiﬁer. (The Opinity URL for Vittorio is http://vibro.opinity.com.)

A unidirectional identity deﬁnes the identity of an entity in the limited scope of a transaction

When an individual enters a transaction, however, the identity he uses is unidirectional. That is, the identity transmitted is meant only to identify the user with the service provider currently engaged. If you are buying an airplane ticket on one website and booking a hotel room on another, the authentication scheme should not help the two websites to join their data and understand that you are the same person (and afterward send

The Seven Laws of Identity

103

you advertisements about shuttle services between your destination airport and your hotel). This is a very subtle point. A typical objection at this point is this: What if both sites require name and birth date? What can an authentication system do to prevent the two businesses from joining data together? The answer to that is, not much. If the two businesses require name and birth date to perform their function, there’s nothing that can be done. You might require that data be encrypted with the public key associated with each site so that the data is not mutually visible, but that covers just the transmission. As soon as the information arrives at its intended destination, two dishonest service providers can still share proﬁles and search for a match. That’s one of the reasons why using something unique and personal such as the SSN is really, really bad practice. The point of the Directed Identity law is that such a possibility should not be offered by the identity management schema in itself. In other words, an authentication schema should not rely on mechanisms that could give rise to correlation handles. Imagine a situation in which the services you are using require you to sign in, but they do not require any further information about you besides the credentials you use for authenticating. One example of such a service could be a photoretouching website. After having signed in, you can upload one picture, and somebody will ﬁx red eyes on-the-ﬂy and send it back to you in the context of the same session. Another such a service could be a trafﬁc information service or weather reports. When you sign in, you can get information about one area of choice. For both services, you are just sending the credentials required to verify that you subscribed to the service. In that case, an authentication schema respectful of the directional identity law will not allow the trafﬁc service to realize that the person who asked about the situation on Highway 90 is actually the same person who sent those “oh so weird” pictures to be retouched. That separation will typically be obtained by the identity management scheme by ensuring that no two websites share

An identity management schema should not provide means for correlating identities across different contexts

104

Hints Toward a Solution

the same identiﬁer for the same user. But that’s just an implementation detail. What counts is that the scheme does not enable the kind of abuses previously described; how it accomplishes that does not really matter. Pluralism of Operators and Technologies

A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers —The Laws of Identity, Cameron, 2005

We devoted a good part of Chapter 1 to describing different ways of handling authentication: certiﬁcates, SAML, and even passwords. Proposing a single authentication scheme for the Internet has been attempted, but it has failed. As the next lines will hopefully clarify, such an effort is doomed from the very start. Diversity and variety are inherent in the problem of Internet authentication

We have seen how the features of different systems are the result of the diverse requirements imposed by the contexts in which they are meant to operate. We should not expect those differences to go away, in much the same way as we should not expect that hammers and screwdrivers will eventually converge into one single tool. Furthermore, we have seen how today’s scenarios and associated requirements greatly differ from yesterday’s. By induction, we can safely assume that the future will pose challenges that we are unable to predict, and hence the solutions will also take forms we cannot foresee today. People and businesses will have their own preferences and inclinations, and those will be reﬂected in their technology choices. As the value of the transaction rises, the level of security required will follow suit; different businesses will deal with risk in different ways, formulating their policies accordingly. Different users will have different degrees of tolerance for information disclosure; the concept of what is or is not acceptable in

The Seven Laws of Identity

105

terms of safeguarding one’s own privacy will vary widely by communities, cultures, or who knows what other factors. Just think of the example we made in the section “Justiﬁable Parties” concerning government tracking of electronic ID usage. Some will accept this unconditionally, and some will push back so hard that merchants will have to adopt different technologies for meeting user’s privacy demands to remain in business. Handling such a diverse mix of tendencies requires pluralism of operator offerings and technologies available. An identity management scheme that aspires to be the universal authentication system cannot fail to take the situation into consideration. Embracing and accommodating existing and future technologies is the only way to achieve the goal. In the section “The Identity Metasystem” we describe a natural solution to the dilemma. Human Integration

The universal Identity Metasystem must deﬁne the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. —The Laws of Identity, Cameron, 2005

Chapter 1, and speciﬁcally the section “The Babel of Web User Interfaces,” described the inadequacies of current practices in making the user understand what is going on during the authentication process. We have seen how the certiﬁcates, although perfectly sound from the purely cryptographic standpoint, are not really helping the user to deal with the server authentication problem. We have also seen how the wide gamut of different user experiences, despite the fact that in the vast majority of cases they all

Inclusiveness and tolerance are key factors for the success of a global solution

106

Hints Toward a Solution

account for the task of entering username and password, confuses the user to the point of making him vulnerable to the simplest phishing attacks. What works for machines may not work for humans

If we analyze from the pure engineering standpoint the communication sequence when authenticating to a website, we discover an almost universal pattern. Until the communication happens between machines or software entities, the protocols are predetermined and rigidly followed. Every phase mandates message formats and sequences, and the semantic of every step is unambiguously determined. A good example of this point is given in Chapter 1, in the section “SSL Client Authentication.” As soon as human intervention is required, however, things change. Even if the task is almost invariably to enter password credentials, every website will implement the functionality in different ways. There is the diffuse idea that the user will “ﬁgure it out,” so a reasonable set of controls and a sound process behind it will do. The ﬂaw in that reasoning lies in the fact that reasonable and sound are ill-deﬁned. Apart from the fact that often those systems are designed by computer scientists, who abide by a very different deﬁnition of reasonable than end users, the entire idea of relying on the user’s ability to “ﬁgure it out” is extremely dangerous. When the user is expected to recognize to whom he is disclosing his personal data or which kind of information will be sent, the margin for interpretation should be reduced to an absolute minimum. The way of achieving this is planning for human integration, devising interaction mechanisms that properly account for the user capabilities, eliminating ambiguity, and reducing the room for misinterpretations. In other words, when the user deals with identity management matters, he should be constrained by a protocol, too.

Humans can follow protocols, too

Following a protocol is not exclusive to machines. Humans can do it, too, and have done so since forever, every time it is important to have predictable results. We follow a protocol on election day when we go to vote, when we clear a security checkpoint at the airport, when we sign a contract, when the

The Seven Laws of Identity

107

ﬁre alarm goes off in our ofﬁce building, when we operate a nuclear plant, when we document a process in the context of ISO9000, when we apply for an immigrant visa. The list can go on and on. In those cases, we follow a protocol because there’s a lot at stake in terms of risk or resources and, as painful and uninspiring as it may sometimes be, we accept that as a fact of life. The way in which a universal identity system (please ignore for the time being the term metasystem in the law enunciate) should integrate humans is by maximizing comprehension while minimizing ambiguity. That is, a universal identity system should make everything as understandable and incontrovertible as it can be. That implies representing facts and entities in ways that the modern science of human computer interaction deems appropriate and deﬁning rigorously the actions that users can perform and their exact semantics. Clarity claims its price on freedom. A system easy to understand and with ﬁxed semantics will limit the room for creativity. However, when operating a nuclear plant, creativity should not be the higher-order bit. The same goes for making all the users understand whether the information they are being requested to send will travel in the clear through an untrusted network or whether it will be encrypted. Note that this by no means implies limitations on speciﬁc authentication technologies. It just states that a universal identity management system should properly accommodate human integration but gives no indications of the architectural layer at which such integration should take place. Consistent Experience Across Contexts

The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies. —The Laws of Identity, Cameron, 2005

A universal identity system should make everything as understandable and incontrovertible as it can be

108

Hints Toward a Solution

While using the Internet, we project our identities all the time; we just don’t always realize when we do it. In fact, many users do not actually have a clear picture of what identities they have and how they are used across the various services they make use of. The current user experience in that space is so broken that talking about consistency is difﬁcult. Users do not even have a clear perception of what a security context is by now. The user might not even have a mental symbol for “digital identity”

Think about it for a moment. The typical user will have a handful of password credentials he uses and reuses (see the section “Decline” in Chapter 1). The actual identities of the user are the sets of relevant facts that are kept on the service provider stores and are unlocked by transmitting the correct set of credentials (see the concept of hostage identity in the section “HTTPS, Authentication, and Digital Identity,” in Chapter 1). If a username-password couple is reused across two different services, it will likely correspond to two different identities; this is supremely confusing for the user, who manipulated directly just the credentials and is only vaguely conscious (if at all) of the existence of the associated identities unlocked on the serviceprovider side. Password manager utilities do not really help, and sometimes they make things worse. By showing that the same username is used across different websites, they may induce the user to believe that he is using the same identity across the group even though the user proﬁles kept on different service providers may be dramatically different. That is certainly a setback in the attempt to instill context awareness in the user.

Shifting the perspective of the user toward thinking about identity would simplify many operations that are today prone to errors

This last thought experiment describes just what happens at authentication time. However, there are countless other times at which online applications ask you to disclose fragments of our identities. This typically happens when you engage in a highvalue transaction, when the service provider needs to reach beyond the online world and gather data from your ofﬂine identity. If you are having something shipped, you need to provide your address; if you are handling some administrative practices with your government, you may have to provide your ID

The Seven Laws of Identity

109

number; if you are verifying the status of your immigrant petition, you have to provide your application number; if you are buying something online, you may have to disclose details of the relationship you have with your credit card provider (that is, enter your credit card number). All those things happen in completely different contexts, following different processes, requiring different interaction patterns. The concept of identity, which would be so useful and the natural tool for modeling those transactions, is implicit at best and is more often than not just an emergent property of the system. No wonder that the user has a hard time handling his or her identities effectively! It is like trying to understand the paths that planets follow in the night sky without knowing that the Earth itself spins and everything revolves around the Sun. Without the latter information, those paths are extremely difﬁcult to understand and predict. Adopting the new perspective, however, makes everything crystal clear. If we want to solve the problem of identity management for good, we need to be like Galileo and rebuild the system on the basis of the fundamental identity mechanics we have discovered so far. That will lead to a more natural and effective way for users to think about identity. Proﬁciency in managing it will follow suit. The ﬁrst thing we can do is make the concept of identity explicit for users. A user should be able to think about his or her identities as clearly as he or she thinks about his or her ﬁles, documents and any other abstract entity that has a visual representation in a user experience. Once the identities are explicitly represented, we have made an enormous step forward. Users can now create identities for all the contexts and the hats they wear: identities for web mail and low-value services, identities as employees of a certain company, identities as citizens of a certain country, identities as members of a dating service, identities as alumni of a certain

Again, control is key. The user must be aware of the concept of identity

110

Hints Toward a Solution

university, and identities as just about any kind of digital persona they expect to use in their activities. Information will naturally fall into the right place. How much you paid for taxes last year will be in the citizen identity and not in the alumni identity, whereas for your grade point average it will be vice versa. Consistency across contexts can provide the user with the landmarks necessary for understanding how the identity ﬂows

Once the information is packaged in explicit representations of identities, it is ﬁnally possible to reach a level of consistency in all the transactions involving disclosure of identity data. Users can choose which identities are most suitable in every given context, while services can help users to understand the context by explicitly limiting the set of identities they are willing to accept. A service asking for our email and a service requiring knowing our yearly net income can now do so using the same user experience, relying on the new awareness that the user has about his identities. The system must be secure, and the differences between the two requests must be completely clear (see the section “User Control and Consent” and discussion about unambiguous operations in the section “Human Integration”), but the semantic of the two operations is the same. Disclose some part of one of your identities. It makes sense that the user experience is the same, too, just as the procedure for copying a ﬁle between two folders doesn’t change regardless of whether the ﬁle content is the script of the movie Borat or the true recipe of the philosopher’s stone.

The Identity Metasystem We can now count on the laws of identity as guidance and as a powerful tool for evaluating whether a solution is truly ﬁt for the task. The time has ﬁnally come to unveil a comprehensive, long-term solution to the problems we have described so far. Of all the seven laws, many are actually just good architectural common sense. The fact that there was the need for a law to be formulated reﬂects the fact that the Internet grew like a coral

The Identity Metasystem

111

reef, without an architect, and things just happened on their own. The tools for solving many of those problems are available and are successfully used in other areas; it’s just a matter of engineering them in the identity space. One law, however, is problematic: the “Pluralism of Operators and Technologies.” We have made clear throughout the entire book that diversity is an important and a noneliminable component of the Internet ecology. How can we convince that all entities in operation, today and tomorrow, would abandon their current systems and adopt a new one? Would we even want to do such a thing? Fortunately, we don’t need to. We can create a system of systems, or Metasystem, that will embrace existing technologies and facilitate the dialog among them. Managing identity entails manipulating common abstract principles, performing speciﬁc actions and covering canonical roles. Those are concepts that exist in complete independence of the speciﬁc features of the existing and imaginable authentication schemes. Just think of the descriptions we gave of SAML, Kerberos, Secure Sockets Layer (SSL) client authentication and others in the section “The Babel” in Chapter 1. There are important differences in the way they operate, but you can see that there are analogous concepts (such as the idea of token) and messages with the same semantic (such as obtaining a token from an authority). We can conceive an Identity Metasystem that deﬁnes concepts and operations universally valid in the identity space, without bothering about the implementation details; we can devise an integration layer through which the peculiarities of speciﬁc identity systems are abstracted out and mapped to and from those generic constructs. Not having an implementation on its own, the Identity Metasystem does not aim to substitute for existing systems. It actually needs them because they provide the implementation fabric it lacks.

We solve the pluralism dilemma by adding a level of abstraction. A system of systems can embrace new and existing systems The Metasystem abstracts away concepts that are common to all identity systems but which are often implemented differently

112

Hints Toward a Solution

A system of systems protects the investment already committed to in existing technologies

This solution enables applying what we have learned about correct identity management without compromises because we don’t have to worry about legacy features we need to maintain for the sake of technology. At the same time, the solution invites present and future technologies to participate. By concentrating on the fundamental principles of identity management and leaving the details to single solutions, it is impervious to technological dependencies that would limit its scope and its expected life. This simple idea has beautiful implications and deﬁnes the very physical laws of the universe in which Windows CardSpace is meant to operate. The remainder of the current section describes in depth the Identity Metasystem, introducing many concepts and ideas that are key to understanding the technology. The section “Some Deﬁnitions” formalizes some of the terms used in the context of the Identity Metasystem. The section “Roles in the Identity Metasystem” describes the essence of the solution by introducing the entities and the relationships that keep together the ecology deﬁned by the Identity Metasystem. The discussion will still be at the model level, without strong references to the actual reiﬁcation of the solution in today’s technology landscape. The section “Components of the Identity Metasystem” digs deeper into the requirements that must be satisﬁed for making one Metasystem possible. It will also lay the foundation for the section “WS-* Implementation of the Identity Metasystem” later in the chapter. Some Deﬁnitions

The content of this section is long overdue. Through the book, we introduce numerous concepts that are peculiar to the identity management space. However, we have tried to avoid as

The Identity Metasystem

113

Decoupling: A Winning Pattern The Identity Metasystem aims to decouple identity-related operations from their actual implementations. Solving a problem by adding a level of abstraction is a very common technique in computer science, and the examples of spectacular successes abound. The ease of use that we enjoy with computer networks today is perhaps the most visible instance of successful decoupling. In the late 1990s, every software developer who wanted to use any network capability was forced to target a speciﬁc protocol. A program written for working with Token Ring was different from one performing the same functions but designed to work on Ethernet. Software vendors needed to know which protocols were available on the customer LAN. Customers needed to know which protocols were supported by the products they bought. Any change had to be addressed by modifying the source code, with signiﬁcant time and effort investments; and the contrasting requirements of different software packages drove network administrators crazy. Then something magical happened. The TCP/IP protocol started to enjoy widespread adoption on a growing number of platforms. TCP/IP made immaterial to developers the question of whether the target system supported Ethernet or Token Ring. You could program directly against TCP, and the actual protocol availability became a deployment problem. Today you don’t have different browser executables for every conceivable protocol, and the same can be said for every network-enabled application. The ultimate proof of the soundness of the approach is the grace with which Wi-Fi, a protocol that was not even invented at the time of the creation of TCP/IP, was integrated into software systems. Again, the code that makes your browser tick is exactly the same whether your laptop is connected to an Ethernet cable or your trafﬁc rides radio waves. This is the promise of agility and future-proof robustness that the Identity Metasystem brings to the world of authentication schemas.

much as possible the usage of many of the loaded terms that you ﬁnd in the literature. It was not easy, but we hope that this model favors the unbiased understanding of the new ideas we are discussing.

114

Hints Toward a Solution

It is now time to deﬁne more rigorously some of the terms we have been using loosely and substitute some of the words we used with speciﬁc identity-related terminology. We will not give all the deﬁnitions here, but we will keep introducing new concepts as appropriate throughout the rest of the book. For example, the deﬁnition of subject is delayed until the section “Roles in the Identity Metasystem,” where the context is ideal to understand its function and importance. Claim A claim represents a fact about something or somebody. Better. A claim is a statement that a certain fact applies to something or somebody. As such, it is subject to veriﬁcation. In other words, you can accept or reject the claim based on your beliefs, knowledge of the situation, and so on. Classical examples of claims about people are “Bob was born in 1956,” “Bob is a Belgian citizen,” “Bob belongs to the ‘Managers’ user group at Contoso.com,” “Bob has green eyes,” “Bob can buy $5000 worth of merchandise,” “Bob is really the one who received this ticket from the TGS.” Claims about things are no different: “Contoso’s public key is Fx0Ex0…,” “Contoso has its main ofﬁce in Las Vegas,” and so on.

Those claims may or may not actually apply to Bob or Contoso. The way in which you get to decide one way or the other accounts for a good part of the entire identity management process. (Digital) Identity As central as this concept may be to the topic of this book, the deﬁnition of (digital) identity is largely unimpressive: A (digital) identity is a set of claims made by a subject about itself or another subject.

In the section “Roles in the Identity Metasystem” we will see what we mean exactly by subject, abbreviated S. For the time

Trust

115

being, you can just substitute the occurrences of the word in the deﬁnition with the same “somebody or something” we used in the section “Claim.” Remember the discussion about the difference between credentials and digital identity in section “HTTPS, Authentication, and Digital Identity” from Chapter 1? The airline example should have provided an intuitive idea of what we mean by identity in this context. Now that we have a deﬁnition, we can reﬁne the concept a bit further. One thing you might notice from the deﬁnition is that an identity is made up of claims all coming from the same source; given the fact that claims may or may not actually apply, what you know about that source may inﬂuence what you believe to be true for the entire identity as opposed to considering claims one by one. There will be more (much more) about this later in the section.

It is who asserts the digital identity that determines whether you will believe the claims in it

Another interesting thing you may notice from that deﬁnition is that an identity can be self-asserted. It is perfectly legitimate for somebody to make claims about himself. This actually happens all the time on today’s Internet. When you sign up for an Internet service and you are asked to ﬁll in a proﬁle, you are making claims about yourself. Again, this is an important consideration and will be explored at length later in the book.

Identities can be self-asserted

Trust The concept of trust is pivotal in the IT security literature, and it can certainly elicit interesting philosophical digressions. In this context we will be much more prosaic, and we will simply deﬁne trust as the willingness of a subject to believe the claims asserted by a certain other subject. If Alice trusts Bob, any claim Bob will make will be considered true by Alice. There’s that

116

Hints Toward a Solution

little matter of making sure that Bob is really who he says he is and verifying that the claims are actually coming from Bob; but after that is taken care of, Alice will believe just about anything. Technically, that is not strictly true because Alice’s trust for Bob may be bounded only to certain areas. However, for the purpose of the explanations in this text, we can safely think in terms of unbounded trust. Verisign says, via a certiﬁcate, that this website is “contoso.com”? Your browser is happy. Your government says, via a difﬁcult to fake ID card, that you are over 21. Your bartender smiles and pours Chianti in your high-stem glass. That’s trust. Roles in the Identity Metasystem

The Identity Metasystem abstracts the entities and processes involved in identiﬁcation operations. The various actors participating in the transaction are perhaps the ﬁrst things that need to be modeled, the basic blocks from which we can start to build our Metasystem. Understanding the invariant characteristics of relationships and mutual expectations is a key step toward successfully capturing the essence of the process. Observing the recurrence of such features across many different identity-related transactions leads to the deﬁnition of some archetypes, or roles, which successfully describe the behavior and the properties of all the actors involved. Substantially, if an entity participates in an identity-related process, you can always represent such an entity in the Identity Metasystem with one or more of those roles. The Identity Metasystem distinguishes three possible roles: subject (S), relying party (RP), and identity provider (IP). As the following descriptions will clarify, those roles describe perfectly natural behaviors, in full agreement with the intuition; in fact, they are perfectly suitable for describing identity-related

Trust

117

processes happening in the ofﬂine world, too. That should not surprise too much. We are rebuilding a system from the ground up, explicitly to get things right, free from the artifacts and aberrations derived from implementation details and historical burdens. The next three sections introduce the three roles. In the section “The Dance of Identity” later in this chapter, we examine how those three roles contribute to propagate identity information. Relying Parties A relying party, often abbreviated RP, is an entity that consumes identities. An RP is typically something or somebody who provides a service that is intended to be enjoyed by a restricted audience. To make sure that the access is granted only to the rightful crowd, the RP requires receiving an identity from the requestor.

Relying parties consume identities

The wine seller in the example from the section “Minimal Disclosure for a Constrained Use” is an RP; so is any website that requires you to authenticate yourself before accessing its services. If you examine the section “The Babel,” from Chapter 1, you will see that every authentication scheme described includes an entity that plays the role of the RP: intranet services requesting a certiﬁcate form a smartcard, HTTPS endpoints asking for a certiﬁcate via SSL authentication, the “service B” described in the “Kerberos” subsection. In SAML, the service requesting the caller identity is even called relying party! The RP is a powerful invariant of identity-related systems. Its requirements are among the main reasons for which we need an identity system in the ﬁrst place. Subjects We have already used the term subject a number of times throughout the book, relying on its common meaning. From a deﬁnition standpoint, a subject is just something or somebody

Subjects have identities

118

Hints Toward a Solution

who owns a digital identity. From the role deﬁnition point of view, however, it is worth considering the deﬁnition in more detail. Anybody can be a subject

Identity providers assert identities of the ones they know about

In the section “Directed Identity,” we introduced the differentiation between omnidirectional and unidirectional identities. The former type of identity can often be assigned to every actor in a transaction, or at least to all the ones that exhibit one-to-many relationships. That basically means that the label “subject” can be applied to many entities in an identity system, and therefore its usefulness as a role-differentiating factor seems pretty unlikely. In the context of the Identity Metasystem roles, however, we usually intend the subject as one entity whose unidirectional identity comes into play. That does not mean that the entity cannot also own omnidirectional identities. Instead, it means that for purposes of modeling the behavior of an entity in the subject role in an identity transaction, we will consider only the unidirectional aspect. Translating the example in the section “Directed Identity” into Identity Metasystem terms would result in something like this: If the RP is the actor who consumes identities, the subject is the entity whom the consumed identity is about. If the wine seller plays the role of the RP, the buyer is the subject; it is the buyer’s identity, in the sense of the claim deﬁning his age, that the wine seller will want to verify (“consume”). Identity Providers The concept of IP is extremely natural. It models a role that is practically omnipresent in real-life situations in which people handle identities. Unfortunately, in traditional online authentication schemes, the IP is implicit or is an emergent property of the system, making it difﬁcult to weave into the system the requirements associated with the role.

An identity provider, abbreviated IP, is an entity that issues digital identities. An IP is the entity that asserts the claims constituting a digital identity, typically in virtue of the relationship that associates it to the subject owning that identity. The list of exam-

Trust

119

ples from the ofﬂine world is endless. Governments can emit claims about their citizens; employers can issue claims about their employees; a department of motor vehicles can claim that a certain individual can lawfully drive particular vehicles; an airline can declare that a given individual is a passenger of a certain ﬂight; a doctor can declare that a speciﬁed patient is ﬁt for physical activity; a department store can award a customer with loyalty privileges. A very important example is the one in which an individual makes claims about himself, such as declaring his home address on a feedback form in a restaurant. Note that in all the previous examples the IP was actually competent in terms of the kind of identity information mentioned. A government is a natural IP for its citizens because it actually owns the information involved (such as the passport number), and it has the appropriate means for managing it (such as demographic archives). Every entity aware of preceding facts will consider the government an authority in the matter of its citizens. In other words, it will trust the government (as trust was deﬁned previously). This simple consideration gives us the last piece for fully translating the wine seller example in Identity Metasystem terms. The wine seller is the RP, the buyer is the subject and the government is the IP that provides the buyer with an identity (for example, in the form of a picture ID document). The RP trusts the IP and therefore accepts the claims on the document as true and acts accordingly, granting or denying the buyer request according to the rules.

Identities issued by identity providers are effective to the extent that the IP is considered an authority in the current context

Explicitly acknowledging the existence of the IP role is a powerful shift in perspective and helps to reconsider many aspects of identity-related transaction.

IPs have always been there. The big shift is modeling them explicitly

One of the concepts that surfaces more clearly thanks to the idea of IP is the identity context. Different RPs will grant their trust to diverse IPs, according to the service they offer or the relationship they themselves have with the IPs. In the ofﬂine world, you would never try to board a plane just by showing

120

Hints Toward a Solution

your driver license, nor would you attempt to get a discount at the local department store by waving your passport. Yet, as mentioned in the section “Consistent Experience Across Contexts,” with today’s online-authentication system, errors of that magnitude are not uncommon. Expressing identities as collections of claims was the ﬁrst step toward clarifying the information ﬂow: Explicitly stating the issuer of those claims, and its trust relationship with the RP requesting them, is the step that ﬁnally deﬁnes the transaction details and helps the subject to make informed decisions. The concept of IP provides a useful model for describing scenarios in which the identity is self-asserted

Another important effect of introducing the concept of IP lies in the reinterpretation of transactions in which the identity information is claimed by the subject itself. In today’s online world, many of the low-value services (typically the ones for which you are not charged) do not require the user to be endorsed by any speciﬁc IP. The authentication operation will just verify that the current requestor owns the credentials associated with a certain signup proﬁle. That signup proﬁle, created at registration time, is the subject identity. Some portion of the proﬁle will have been entered by the subject itself, and hence it would be considered self-asserted. Name, surname, and email are typical examples of self-asserted claims. Some other portions of the proﬁle (such as the last pages visited on that website in the former session) may contain information that belongs to the RP itself. The Identity Metasystem model allows the self-asserted portion of the user proﬁle to be described as a full-ﬂedged identity, issued by the subject to itself. In other words, the requestor simultaneously plays the role of the subject and the IP. Such an arrangement gives back control and awareness to the user, who can now maintain and disclose information at a ﬁner level of granularity. Above all, however, the use of an IP in the case of self-issued claims provides a level of consistency that can ﬁnally satisfy the seventh law, “Consistent Experience Across Contexts.” Windows CardSpace expresses self-issued claims via an artifact named Personal Card, which concretely realizes the advantages of the

Trust

121

last scenario described here. Parts II and III of this book delve into the details. The implications of the introduction of an explicit IP role in the system are profound and cannot all be covered here, but you will see more and more of them as the Identity Metasystem is described in further detail throughout this chapter. In summary, an IP is the ﬁrst occurrence of the word subject in the deﬁnition of digital identity (see the section “(Digital) Identity”). It is the entity that asserts claims about another subject, typically with regard to the relationship between the two. The digital identity is a currency that a subject can spend with a certain RP if the latter trusts the IP that minted it.

Freeing the “Hostage Identity” In Chapter 1, in the section “HTTPS, Authentication, and Digital Identity,” we encountered the concept of hostage identity. The identity of the user, intended as collection of claims, lives on the website itself, and it is “unlocked” by a successful user authentication. When this happens, the content of the claims can inﬂuence the behavior of that website but no others—if you disregard the few cases of business partnerships grouping together multiple entities (see the example in “User Control and Consent” and “Minimal Disclosure for a Constrained Use”). With the new model, all this can change. The Subject can obtain its identity from an IP, and the website (which clearly plays the role of an RP) does not need to keep those claims buffered anymore. The Subject can use the same collection of claims with any other RP that trusts the IP. The hostage is free. This is a true game changer, and it’s natural to wonder how it can impact current practices. As this chapter unfolds, things will get clearer. Furthermore, Chapter 6, “Identity Consumers,” is entirely devoted to IPs and explores those issues in depth. In this sidebar, we address an apparent contradiction induced by the introduction of the three roles. Now that an RP relies on an IP for releasing identities, aren’t we

122

Hints Toward a Solution

outsourcing authentication? Didn’t we say in “Justiﬁable Parties” that outsourcing authentication is bad? The point is subtle but important. When an RP requires the S to present an identity obtained from an IP, it is asking S to present itself as a “customer” of the IP as opposed to a customer of the RP. If you are using an automatic kiosk for checking in for a ﬂight, you can swipe the credit card that you used to buy the ticket. First and foremost, your ownership of the credit card proves that you are a customer of the credit card company; then, it is also a moniker for your record in the airline company back end. The airline didn’t outsource its authentication operations to the credit card company. If you swipe your spouse’s credit card, the system will not let you in. Furthermore, the data about the seats and whether the ticket allows access to the lounge is still on the airline’s database, as opposed to the credit card company’s. With IPs and RPs, it is almost the same. The RP trusts the fact that the S is recognized by the IP because it is able to present an identity from the IP. But that does not imply that RP will not perform any additional controls, nor that all the data relevant to the transaction must come from the IP. In fact, some data is pertinent only to the relationship between the S and the RP, and therefore they are not supposed to be “freed.” Using terminology that we introduce later in this chapter (see the section “Identity Metasystem Components as WS-* Features”), you can say that the data should be kept in a user proﬁle rather than a token. We revisit this topic at length in Chapter 6. In summary, the model based on the idea of an IP is dramatically different from the outsourced authentication that the ﬁrst Passport proposed. Although an RP relies on an IP to assert claims about which it is competent, in the previous example Passport would do the equivalent of storing the seat position and the luggage allowance on the credit card back end.

Components of the Identity Metasystem

The preceding section introduced the roles that an entity can possibly play in an identity-related transaction. You can verify identities (RP), you can have your identity veriﬁed (Subject), and you can provide an identity to somebody (IP). This is a beautiful

Trust

model that also applies nicely to the ofﬂine world. However, we need to lower the abstraction level if we want to give a practical answer to the problem we decided to solve: adding an identity layer to the Internet. Let’s take one step back and gather our thoughts. What do we know so far? We want to solve the problem of propagating identities through the Internet. We said that we want a system of systems that would accommodate existing and future technologies in a single Metasystem (as opposed to yet another technology that would compete with the current and future offering). We have the laws, which warn us that the only constants on the Internet are diversity and change. The “Microsoft Vision for an Identity Metasystem” white paper, the manifesto of the Identity Metasystem, coalesces the preceding consideration into a need for ﬁve key components, as follows:

A way to represent identities using claims

A means for IPs, RPs, and subjects to negotiate

An encapsulating protocol to obtain claims and requirements

A means to bridge technology and organizational boundaries using claims transformation

A consistent user experience across multiple contexts, technologies, and operators

The list of components could be rearranged in different ways, but we chose to maintain the original criteria for the sake of coherence with the rest of the literature on the S. The following sections explain the components one by one, tying the deﬁnitions to the concepts introduced so far.

123

124

Hints Toward a Solution

Identities are made of claims

Claim-Based Identities At this point in the text, the reader is familiar with the concept of digital identity. In Chapter 1, we observed the shift from blind credentials to authentication in the section “Ascent”; in the section “HTTPS, Authentication, and Digital Identity,” we gained an intuitive understanding of the concept of digital identity, where the frequent-ﬂyer example showed a ﬁrst instance of claims usage; in the section “The Babel,” we observed how some technologies incorporate the idea of claim. In this chapter, we gave a formal deﬁnition of claims and digital identity in the section “Some Deﬁnitions.” The reasons why an identity is well modeled by a set of claims have been given throughout the entire text. Now that we have deﬁned the key roles and the relationships among them, it is natural to adopt claim-based identities as the currency exchanged in the Identity Metasystem. Negotiation The various participants in the Identity Metasystem support many different identiﬁcation technologies. How can we achieve interoperability? One important component of the solution lies in the need for a negotiation protocol.

If two systems are capable of communicating in many different ways, they have to negotiate to discover which ones will work for both

Let’s introduce what we mean by negotiation with an example. An Italian person and a Chinese person, perfect strangers, go to an international conference. They meet in the elevator. The Chinese person says to the Italian person “ ” and the Italian person answers “Non capisco!” As soon as it’s clear that they can’t understand each other, they shrug and part ways. Imagine the same scene, but this time the two are wearing the conference badges mentioned in the section “Directed Identity” that identify the languages they speak. The badge of the Italian person says “Italiano, English”; the one of the Chinese person says “ , English.” This time the Chinese person will know that if he wants to be understood he can speak English. A glance at the two badges is enough to understand each other’s capabilities and negotiate a common ground.

Trust

125

The same principle can be applied to accommodating the diverse technological capabilities of the entities involved in an identity-related process. The Identity Metasystem should provide a means through which the various parties can negotiate which technologies among the ones supported will be used for that speciﬁc transaction. If a subject can express his identity with SAML or Extensible rights Markup Language (XrML), and the RP he’s invoking can accept Kerberos or SAML tokens, the Identity Metasystem will provide a way for the two to agree on using SAML. One frequent question that arises at this point is what happens when there is no match. If the subject supports only X.509, and the RP supports only Kerberos, there’s no way for the two to engage in a transaction, at least until one of the two acquires a capability compatible with one of the other party. The negotiation protocol cannot perform miracles and instantly make Italians speak Chinese; however, it is still useful for gaining knowledge of the requisites. It is important that the negotiation phase be embedded in the Metasystem, instead of being left as an explicit integration task to the parties, so that the format in which requirements are expressed is as formal as possible and the stage is completed without imposing burdens on the parties’ implementers. In the section “WS-* Implementation of the Identity Metasystem,” we describe WS-MetadataExchange, a concrete example of a negotiation protocol that enables querying web services for dynamically discovered policies.

The Identity Metasystem provides a frame of reference through which entities can negotiate which underlying technology to use

Because the Metasystem does not deﬁne an authentication technology of its own, reaching an agreement on that requirement is a necessary condition for any transaction to take place. It is also important, however, to make sure that all parties understand other kinds of requirements less bonded to implementation details. In the wine seller example, the merchant needs to know the age of the subject. This is a requirement that the buyer needs to be aware of and understand if he is to decide whether he wants to disclose the requested information. The fact that the merchant will accept only claims from a government-issued ID is again information that needs to make its way from the RP to

Negotiation is a necessary step in a system of systems

126

Hints Toward a Solution

the subject. The set of requirements of an RP is said to be its policy. The IP has policies, too, as discussed later in the chapter. Encapsulating Protocol As the negotiation takes place, the information must actually ﬂow according to the roles and the rules of the transaction. The subject needs some way to retrieve his identity from the IP, and the RP needs some way to receive it. Every technology transmits data in its own way; a Metasystem needs to provide a generic encapsulation protocol

The existing technologies already have their own ways of representing identity and moving it from node to node. However, those methods will not interoperate, and therefore they need to be abstracted away. The Identity Metasystem needs to deﬁne a protocol that presents a common model to every participant so that no speciﬁc technology needs to be understood for establishing a connection; such a protocol, however, should also enable effective transfer of information according to the rules of the particular technologies. The latter is possible in a sustainable and future-proof fashion only if the Identity Metasystem is not required to understand the technicalities of every technology. It should be able to transfer that data without depending on features and peculiarities of the formats. In the previous section “Negotiation,” we saw an example in which two parties agreed to use SAML for their transaction. An encapsulating protocol allows the Identity Metasystem to put in practice that decision by transporting SAML information as it would have done for Kerberos or any other technologies (that is, without really knowing anything about how to interpret the SAML format). Claim Transformers In the examples provided so far, we have been pretty loose in our usage of claims. The wine merchant mentioned previously wanted to know the age of the buyer, but we didn’t bother to provide more detail about the format in which that information should have been codiﬁed. We took for granted that the mer-

Trust

127

chant could, with little effort, extract that information from a driver’s license or from a foreign passport without much premeditation. Well, we have reached one of the limits of the metaphor. Computer systems are much pickier than bartenders (or wine sellers), and the reasons and business models that require online identiﬁcation are much more complex than our canonical example. Consider for a moment every home-banking application up and running on the Internet today. Nearly every one of those applications, and the corresponding back end, has a construct that represents the concept of an account number. The semantic of an account number is fairly unambiguous, even if some local shades of meaning are possible. Yet the representations will greatly vary from bank to bank. If you were to make those home-banking applications participate in the Identity Metasystem, their natural role would be an RP. The policy of those RPs may state that the subject’s identity should contain an account number; however, because we are talking about computer systems, the way in each bank indicates an account number will make a difference. For the bartender, the DOB (Date of Birth) ﬁeld on the driver’s license is happily equivalent to the “Birth Date” ﬁeld on the passport; for a computer system, AccountNumber is very different from Account_Number. This is a very easy example because banks and ﬁnancial institutions already participate in standard deﬁnition bodies, and therefore they can come out with canonical claims representing the concepts inherent to their speciﬁc domain of knowledge. The point here is that an apparently minor difference can make or break the feasibility of a project when we talk in Internet scale, and the Identity Metasystem must be able to plan for and accommodate those differences. Those are just principles of good serviceoriented architecture. Reducing the coupling between parties reduces unnecessary dependencies and leads to a more robust system. Before talking about how the Identity Metasystem copes

There will always be some differences in how entities use claims for modeling scenarios

128

Hints Toward a Solution

with the incompatible claims problem, let’s examine a slightly more complex example. Crossing company boundaries is a scenario that often requires claim transformation

In the sections “User Control and Consent” and “Minimal Disclosure for a Constrained Use,” we introduced an example in which a company is in partnership with a supplier, a hardware vendor. We mentioned that one of the claims that the subject should present to the hardware vendor RP is “spending limit.” Who is the IP in that scenario? The natural choice is the employer. After all, purchases within that application happen in the context of the company-supplier partnership, and it is only natural that the latter will restrict the service to employees only. Hence, the employee’s identity must be issued by the employer. The employer, however, might not actually know what the spending limit of the employee is. What if the value ﬂuctuates following some business rules speciﬁc to that vendor? The agreements between the two parties may state that there’s a monthly buffer, and beyond a certain threshold only managers are allowed to make expensive purchases. Sure, the employer may incorporate those business rules in its IT system; however, that would not scale at all because it would have to do so for every partnership it entertains and differentiate all expenses as they are made as opposed to keeping a single bucket sorted out at invoicing time. It is much easier, and far more natural, to leave that function to the supplier. The hardware vendor knows how much the employer spent so far because it has a good business reason for knowing it. It has yet to invoice it. It also knows the rule. A manager can spend even if the preordained buffer has been depleted, whereas nonmanagers will have variable allowance. In summary, the employer’s IP can issue to the subject claims it is competent to emit, such as whether the subject belongs to the category Managers; the supplier’s RP needs to know the spending limit of the subject, and the supplier knows how to derive that value just by knowing whether the subject is a manager. The solution is straightforward: We need a construct that performs claim transformations applying the business rule previously described.

Trust

Claim transformers are the ultimate decoupling devices. They can help reduce the technical and business differences between identity representations. They can handle naming issues, translating incoming claims corresponding to the same concept in a format understood by the RP; they can apply business rules by examining incoming claims and expressing the implications in terms relevant to the RP business; and they can resolve format incompatibilities, repackaging and transforming claims from one technology to another. Claim transformers are also the element that makes complex trust-chaining scenarios possible. A company that sells houses may only consider candidates who have been certiﬁed as eligible by a consulting ﬁrm. The consulting ﬁrm may trust the statements from a pool of banks for issuing eligibility certiﬁcates. The bank where you keep your main account may be part of that pool of banks. A claim transformer is the means through which the trust chain can percolate from you to the house seller. Your identity of bank customer can be sent to the consultancy ﬁrm, which in turn will issue an identity that satisﬁes the house seller. Claim transformers are one vital component of the Identity Metasystem. There will be quite a few scenarios in which claim transformers will not be necessary. If all parties in a transaction understand the semantic of the claims required, they can all ﬁnd a common technological ground, and there are only single-hop trust relationships, so the claims can be consumed without further processing. However, those scenarios cover only the simplest and cleanest situations. Even if in the future the semantic Web or a similar movement leads to a very large base of commonly accepted claims, there will always be scenarios in which the trust must be brokered, in which new technologies must be integrated, and in which some organizational gulf must be bridged. Consistent User Experience The importance of a consistent user experience cannot be stressed enough. In Chapter 1, in the section “The Babel,” we

129

Claim transformers can insulate architectures from changes and incompatibilities

130

Hints Toward a Solution

invested some time to understand in depth how cryptography and current authentication protocols address the safety of identity information transfer; however, we also saw that the transfer is only one of the phases in which data is at risk. The section “Malware and Identity Theft” describes attacks in the information-entering phase, which are ignored by all the protocol schemes described so far. Now that we have had a chance to understand how HTTPS works, we can see how nothing in the common practices based on it addresses attacks such as phishing. The analysis that brought about the formulation of the identity laws had many occasions to uncover problems derived from poor user experience, widespread inconsistencies, and nonexistent planning for integration of the human component. That’s the reason why at least two laws, “User Control and Consent” and “Consistence Experience across Contexts,” address the issue explicitly. A successful universal identiﬁcation mechanism cannot address just the needs of machines, regardless of how clever its metaprotocols may be. Because the Subject role will almost always be played by humans, the peculiarities and modus operandi of human beings deserve at least the same amount of attention we devoted to integrating the software components of the system. The lessons learned, as summarized by the laws, must make their way into any implementation of the Identity Metasystem. The Dance of Identity

In this section, we describe in Identity Metasystem terms a couple of classical authentication scenarios. By seeing the various components and roles in action, you will gain a deeper understanding of functions and relationships. Note that the two examples are just the most basic templates. With the three roles and the ﬁve components of the Identity

Trust

131

What About the Attacks in the Information-Storing Phase? The section “Consistent User Experience” deals with two of the three kinds of attacks we covered in Chapter 1, in the section “Malware and Identity Theft.” What about the third kind, the attacks in the information-storing and -processing phases? The Identity Metasystem model can help in this case, too, but it cannot give guarantees. If the RP requires the subject to supply certain information, the subject can decide whether he or she wants to disclose that data or withhold it. Ultimately, however, if that data is required for performing the service offered by the RP, the choice is between using the RP or giving up. Organizing the transaction according to the Identity Metasystem is the best way to conduct the process in the best possible way; but after the information is in the hands of the RP, its destiny is bound to what the RP will do with it. The law of directional identity will prevent certain kinds of abuses, but it cannot prevent the RP from storing data in an insecure location. Fortunately, the concept of claim-based identity enables new scenarios in which the problem is eliminated altogether. Because subjects can now move their identities in the form of claim collections (see the box “Freeing the ‘Hostage Identity’”), RPs are not forced to store much information about its users. RPs may choose to store the absolute minimum for authenticating a returning user, relying on the subject to provide all the information in the form of claims every time it starts a session with the RP. Simply put, what is not there cannot be stolen. Not every RP will be willing to follow such an extreme route, and some businesses will need to store information about their users in the form of proﬁles (again, see the box “Freeing the ‘Hostage Identity’” for an example). In any case, the approach does not need to be pushed to its limits to be effective: RPs can choose to avoid storing certain classes of personally identiﬁable information to reduce their liability in the case of security breaches in their stores. In summary, the Identity Metasystem model offers powerful tools for mitigating the effect of attacks in the information-storing phase, too; however, use of those tools cannot be enforced, and effective countermeasures are ultimately left to the competency of the RP.

132

Hints Toward a Solution

Metasystem, we now have at our disposal the intellectual tools for modeling any identity transaction of arbitrary complexity. The Canonical Scenario In the most classic scenario, we have one instance of every role represented. We have one subject, S, one relying party, RP, and an identity provider, IP. The situation is completely straightforward: S wants to use RP, which in turn requires its callers to present an identity issued from the IP to authorize access. This is, once again, a generalization of our wine seller example: S is the buyer, RP is the seller, and IP is whatever government institution issued an identiﬁcation document to the buyer, and Claim1 or Claim2 (see Figure 2-1) is the age claim. In the rest of this section, we explain Figure 2-1, pointing out what part of the Identity Metasystem is involved as the transaction unfolds. Note that because we are still technology-agnostic at this point, we simplify the sequence a bit (especially in Steps 3 and 4). 1. S engages RP in a negotiation to acquire RP’s policy and

requirements. RP states that it will consider for authentication only the users presenting an identity issued by IP, in SAML1.1 format and containing Claim1 and Claim2. 2. S goes through the experience of mapping RP require-

ments with S’s capabilities. Namely, S checks whether it has a relationship with IP that would allow it to ask for a token of the right format and with the requested claims in it. 3. Assuming that S does have a suitable relationship with

IP, S negotiates with IP the details about how the IP wants to be called (for example, with which technology). 4. S uses the information acquired in the preceding step to

request an identity from the IP. The encapsulation protocol tunnels the speciﬁc technology that the IP requires to be invoked.

Trust

IP

5

?

?

SAML Claim 1 Claim 2

SAML Claim 1 Claim 2

3 4

SAML Claim 1 Claim 2

S

6

1

?

RP

IPi IP

2

IP SAML Claim 1 Claim 2

IP SAML Claim 1 Claim 2

Figure 2-1 The diagram depicts the interaction among the three roles of the Identity Metasystem in the canonical scenario.

5. S receives the required identity from the IP. S examines

the details of the identity, such as the content of Claim1 and Claim2, and decides whether it consents to the disclosure of that information to the RP. 6. If S decides to disclose, it uses the encapsulation proto-

col for transmitting the identity to the RP in accordance with the policy received in Step 1.

133

134

Hints Toward a Solution

No technology prerequisites are imposed by the preceding sequence. All parties need to understand the Identity Metasystem; beyond that, however, everybody is free to use the technology of choice. Negotiation and encapsulation protocols provide the mechanism necessary to dynamically conﬁgure the system for automatic policy exchange and interoperability. Brokered Trust The brokered trust scenario generalizes the business partnership example developed in the section “Claim Transformers.” The situation depicted in Figure 2-2 includes four actors. A subject, S, a relying party, RP, and two identity providers, IP1 and IP2. Referring to the business relationship example mentioned previously, those elements map as follows: S is the employee that will make the purchase, RP is the web store of the hardware vendor, IP1 is the employer’s identity provider, and IP2 is the claim transformer, implemented in the form of an IP. A step-by-step description of the sequence follows. 1. S engages RP in a negotiation to acquire RP’s policy and

requirements. RP states that it will consider for authentication only the users presenting an identity issued by IP2, in SAML1.1 format and containing the claim SpendingLimit.

Actually, My Driving License Is Still Valid Steps 4 and 5 correspond to the request and issuance of a government ID document, respectively, in the ofﬂine-world example. In a real-life situation, you would likely already have a valid ID with you, and if it had expired, you would not be able to request and get a renewed one in the context of the wine purchase. However, in the online world, distance and bureaucracy mean nothing (or very little), so requesting that the IP issue a document on-the-ﬂy is actually viable and guarantees freshness of the information. For more information about this misalignment between the example and the transaction please, see the section “WS-Trust” later in the chapter.

Trust IP1 IP2

IP1 SAML Role

?

7 SAML Role

?

IP1 SAML Role

SAML Role

?

SAML Spending Limit

3

?

6

SAML Role

SAML Spending

5

SAML Spending Limit

8 9

RP

4 1

IPi

?

IP1 IP2 SAML Spending Limit

IP2 SAML Spending Limit

2

Figure 2-2 The schema shows the ﬂow followed by a transaction in which trust is brokered through multiple IP. 2. S goes through the experience of mapping RP require-

ments with S capabilities. Namely, S checks whether it has a relationship with IP2 that would allow it to ask for a token of the right format and with the requested claims in it. 3. S does not have an existing relationship with IP2; hence,

S engages IP2 in a negotiation, to acquire IP2’s policy and requirements. IP2 states that it will consider for authentication only the users presenting an identity issued by IP1, in SAML1.0 format and containing the claim Role. 4. S goes through the experience of mapping IP2 require-

ments with S capabilities. Namely, S checks whether it has a relationship with IP1 that would allow it to ask for a token of the right format and with the requested claims in it.

135

136

Hints Toward a Solution 5. S does have a suitable relationship with IP1. S negotiates

with IP1 the details about how IP wants to be called (for example, with which technology). 6. S uses the information acquired in Step 5 to request an

identity from IP1. The encapsulation protocol tunnels the speciﬁc technology with which IP1 must be invoked. 7. S receives the required identity from IP1. S examines the

details of the identity, such as the content of Role, and decides whether it consents to the disclosure of that information to the RP and its trust chain. 8. If S decided to disclose, it uses the encapsulation proto-

col for transmitting to IP2 the identity it obtained from IP1. IP2 then issues to S an identity complying with the requirements of the RP. 9. S uses the encapsulation protocol for transmitting to the

RP the identity obtained in Step 8. It seems a long sequence, but it is really easier to do than to describe. The presence of the decoupling level provided by the Identity Metasystem enables the existing trust relationships to be leveraged automatically. A traditional identiﬁcation technology would have required explicit out-of-band coordination, whereas the policy-based negotiation and the dynamic encapsulation protocol can self-organize a system that just works.

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem How do we create a real system that satisﬁes the requirements of the Identity Metasystem?

The Identity Metasystem looks very much like the solution we were searching for. However, what we have deﬁned so far is still far from an implementation. We could devise systems in which negotiations and exchanges are made by throwing paper airplanes or swapping carrier pigeons and design those systems in a way that (given adequate bridging technology) satisﬁes the requirements we have described so far. From a more pragmatic

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

137

point of view, giving the Internet an identity layer requires supplying a concrete, interoperable implementation of the components we encountered in the preceding section: a claim-based identity representation, a negotiation protocol, an encapsulation protocol, and so on. Those components must guarantee state-ofthe-art security at every stage, but they must be technology- and platform-agnostic; they must enjoy as wide a consensus as possible from the key players in the IT space and be accessible from the widest variety of platforms, contexts, and connectivity types. Sounds like a very challenging endeavor, borderline impossible. Didn’t you hear this story before? Another technology in recent years exhibited a similar value proposition, trying to break free from platform or transport dependencies. That technology is loosely referred to by the name web services.

Web services can get the job done

Web services constituted a new way of exposing software to a distributed environment. The key idea behind web services is that, if the entire industry can agree on a set of common standards deﬁning the key aspects of messaging, direct cross-platform interoperability is achievable. That vision gathered an unprecedented number of leaders in the IT industry. In an impressive collaborative effort, historical competitors set aside their differences and began a process of speciﬁcation deﬁnition and standardization that is going on still today.

The pluralism dilemma was already dealt with by web services

Web services solved many of the challenges related to the attempt to put into practice the principles behind the Identity Metasystem. They are platform-agnostic by design, they pay special attention to security, and they are a technology widely available in the product offerings of the main IT vendors and in the Open Source world. For this reason, the portion of the Identity Metasystem already in place today is largely based on web services.

138

Hints Toward a Solution

In this section, we take a short break from identity and dedicate some time to understanding web services as a phenomenon and as a technology. We position them in the IT landscape and revisit basic principles, terminology, and the aspects more relevant to identity. After we cover the essentials, you will see how the various components of the Identity Metasystem are concretely implemented via advanced web services. The WS-* Speciﬁcations

Developing distributed systems has always been one of the difﬁcult problems of the IT industry. A piece of software that tries to communicate with another software entity across networks or other boundaries needs to address a number of problems. How do we route information to the destination? Which technique should be used for pumping data across the network? Which data format should be used? How do we ensure that the communication is secure and reliable? How do we guarantee that the communication happens in transactional fashion? Before web services, interoperability had to be planned all the way down to painstakingly ﬁne details

The standard way of dealing with those problems was represented by imposing on the designers the need to have complete knowledge of every node of the architecture. That meant knowing in detail which technology was used for developing all the software entities; which technology was used for exposing those entities on the network; and ﬁnally, all the painstaking details about the speciﬁc functions performed, the exact parameters exchanged, and their expected formats. The task was usually eased by using one single platform because doing so greatly reduced the number of variables coming into play. Component hosting systems such as COM+ and Java EJB emerged, and network middleware such as CORBA and again COM+ offered services for handling software communications. However, the results were often brittle. The tight coupling between software components (i.e., between who provided a function and who consumed it) made the systems extremely susceptible to changes and difﬁcult to maintain. Cross-platform communica-

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

139

tion was also challenging and painstakingly achieved by ad hoc integration components and expensive bridges. As the IT world grew in importance and ubiquity, it became clear that those systems could not cope with the strain of increasingly diverse software environments coming from mergers and acquisitions, the need for integrating different software packages, and the dissolution of the boundaries between company information silos. Enterprise application integration knew a short period of popularity, but it was soon clear that there was the need for a strategic, long-term solution that would embrace different technologies. Again, you might have heard this story before!

Software integration needs exposed the shortcomings of proprietary standards

While all those forces were building up pressure, part of the industry was trying to exploit the emerging ubiquity of the markup languages, such as HTML and XML, to devise a way to easily communicate across platform boundaries. Studying the universal success of HTML as the language of the Web, people realized that a large part of that success was due to its minimal requirements and resilience to errors and interpretations. As a result, in 1998 the ﬁrst version of the Simple Object Access Protocol (SOAP) speciﬁcation emerged. It was a very rough cut of what we know today; however, it deﬁned the core of many key concepts still valid in the current vision. The speciﬁcation deﬁned how to project in-memory data types to XML format, a platform-neutral representation that can be understood without knowing anything about the technology that originated the data. It also deﬁned a rough protocol for message exchange, again abstracting away the need to rely on a speciﬁc network transport protocol.

The lesson provided by HTML was that of minimal requirements and resilience

The initiative gained wide consensus among the main industry players and the analyst ﬁrms, with more and more important vendors joining the ranks of the speciﬁcation proponents and backers as subsequent versions were released.

140

Hints Toward a Solution

Interoperating is not enough in the enterprise world. You want security, transactions, reliability…

With the problem of sheer data transfer interoperability on its way to being solved, the market moved to consider the next stage: advanced communication capabilities. SOAP and its associated speciﬁcations (see the section “Basics” later in the chapter) didn’t provide any way to secure messages from tampering in transit, nor was there a mechanism to provide conﬁdentiality to communications; there were no means for a message sender to know whether a message actually reached its destination (and so on). Because the main purpose of web services was to connect loosely associated parties, shortcomings such as the absence of security were especially painful. There was still the chance of leveraging features of the actual transport—for example, sending SOAP messages through HTTPS would have guaranteed conﬁdentiality; relying on that, however, would have partially eliminated the beneﬁts of SOAP’s platform-emancipation efforts. Extending the SOAP speciﬁcation with security features was a risky path. After having observed the issues with comprehensive but bloated solutions such as CORBA, SOAP was intentionally kept simple so as to keep its size and scope to a manageable level.

Modularity was the stratagem for keeping the web services speciﬁcations in a manageable format

The industry broke the impasse by creating additional web services speciﬁcations, each designed to solve a single aspect of the advanced communication problem. All those speciﬁcations built their new functionalities on top of SOAP and sometimes on top of other web services speciﬁcations. The idea was that implementers were not forced to deal with the full range of possible capabilities, but they could have chosen which speciﬁcations to implement according to the requirements of their systems. The speciﬁcations were all designed to work with each other gracefully, without imposing any unnecessary dependency. The speciﬁcations were named according to a consistent pattern: WS-Security describes how to add security capabilities to

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

141

SOAP messages, WS-ReliableMessaging establishes a protocol for adding reliability assurances to web services communications, and so on. That earned them the collective name of the WS-* speciﬁcations. Today the WS-* speciﬁcations cover most of the key aspects of cross-platform software communication. Many of them already enjoy the status of industry standards ratiﬁed by entities such as OASIS or the W3C. Many products on the market, from the most diverse vendors or Open Source projects, leverage those standards for interoperating out of the box across different platforms. Such ubiquity, coupled with advanced security capabilities, constitutes the ideal foundation for implementing a truly inclusive Identity Metasystem. In the next several sections, we familiarize you with some of the most important WS-* speciﬁcations, to the extent to which we can later understand what their roles are in the Identity Metasystem architecture. Basics The main idea behind web services is simple: Use a universally understandable format for describing your data and deﬁne a way to describe how you want to communicate with your software. That is achieved through a number of speciﬁcations that build on one another. XML The Extensible Markup Language (XML) is an immensely popular markup language, which has the advantage of being readable cross-platform and, when the complexity and size permits it, by humans as well.

To trivialize things a bit, XML is like a generic-purpose HTML. Where in HTML markups represent hints to the browser about

The WS-* speciﬁcations are almost ﬁnished

142

Hints Toward a Solution

how to render a page, in XML, markups just represent data. Figure 2-3 shows an example of an XML document. XML is at the center of many important satellite speciﬁcations, such as XML schemas and XML namespaces, which we do not cover here.

SOAP deﬁnes the message envelope format used for communicating with a web service

SOAP is extensible by design

SOAP The SOAP speciﬁcation, currently at version 1.2, deﬁnes what a web service message should look like and how it can be sent between two endpoints. SOAP represents everything using XML.

Imagine having a piece of software that performs the sum of two integer numbers A and B. A SOAP message requesting your software to perform the sum may look like that shown in Figure 2-4. It is an XML document that has a root element called envelope. The area between and is called the body of the message, and it contains the data for your software. The area between and is called the SOAP header element, and it’s the key to SOAP extensibility. That is one area of the message where the infrastructure can weave additional information, enriching the communication with further capabilities. All the nonbasic WS-* speciﬁcations leverage this mechanism.

Figure 2-3

A simple XML document

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

143

Header Body

Figure 2-4

A simple SOAP message

Simple Object Access Protocol? Not Anymore At the time of its ﬁrst formulation, SOAP was intended as a mean of accessing remote objects across platforms. In this, it was following the footprints of its predecessor, the XML-RPC speciﬁcation. (RPC stands for Remote Procedure Call.) Hence, the original SOAP term was an acronym of the expression Simple Object Access Protocol. As the idea of web service got further reﬁned, it became clear that thinking of software in a remote location in terms of objects was not the best way of dealing with distributed systems. The idea of an object implies a certain degree of control from the caller, whereas in practice remote software is often entirely beyond the sphere of inﬂuence of its clients. Without going into too much detail here, web services moved away from the idea of exchanging objects as parameters and return values. Everything started to revolve around the concept of the message, intended as pure data without any logic associated with it. At the time of this writing, the latest SOAP version is 1.2. The current speciﬁcation document explicitly drops the acronym. SOAP is about exchanging messages, not objects.

144

Hints Toward a Solution

WSDL describes the kind of messages that a web service accepts and produces

WS-Addressing provides a rich way of referring to a web service

WS-Policy advertises what is necessary for calling a web service while satisfying its requirement

WSDL Once a caller knows that it can use SOAP for communicating, it needs to know which kind of data the software can handle. The Web Services Description Language (WSDL) absolves that function. Documents written in WSDL describe the operations exposed by a web service and the message format required (and returned) for every function provided. The idea of an explicit contract is very important in software development and in web services and service orientation is possibly even more important. However, further discussion of such is beyond the scope of this book. For a comprehensive coverage of the topic, consult Understanding Web Services (Newcomer, 2002). WS-Addressing In Chapter 1, in the section “HTTP,” we saw how web page addresses work. The address http://www.bob.com/bob/ homepage.htm tells the browser to use the HTTP protocol for retrieving the HTML document homepage.htm residing at the path /bob/ on the web server www.bob.com. The address is both a unique identiﬁer and a way to retrieve the page. The same mechanism could be used for web services, and in fact this is common practice in many applications. However, this does not play very well with web services’ attempts to be independent from the underlying technology. HTTP mandates the use of one speciﬁc protocol, whereas the web service should be able to be moved on some other transport without dependencies. WS-Addressing provides a richer way of referring to web services, helping to overcome the previously mentioned limitations and supplying the more expressive model that is required by the other advanced WS-* speciﬁcations. WS-Policy WSDL describes the operations offered and the message formats required by a web service, but it does not give further details about any other requirements associated with the web service invocation. For example, a web service implementing a wire transfer may be invoked with the correct message format, but

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

145

the software will not execute the operation unless the caller identiﬁes itself using a certain authentication technique. WSPolicy provides a generic purpose for describing such requirements, which are said to be the policy of the web service. WS-Policy (and its sister speciﬁcation, WS-PolicyAttachment) does not deﬁne any domain-speciﬁc policy assertion such as the one about authentication in the preceding sample. It is a generic mechanism for associating requirements (“policy assertions”) to a web service, and as such it does not mandate any particular format. Other speciﬁcations, such as WS-SecurityPolicy described later, leverage this general-purpose mechanism for codifying requirements of a speciﬁc domain. WS-Security WS-Security was the ﬁrst speciﬁcation building on the extensibility capabilities of SOAP. Although the speciﬁcation itself and its derivatives are fairly complex, the purpose of WS-Security is straightforward. It deﬁnes ways of protecting SOAP message exchanges and provides a means of transporting security-related information.

Given the enormous success of XML, the industry soon felt the need to provide some security mechanism that could guarantee conﬁdentiality and integrity to the new format, without giving up its cross-platform reach. As a result, the W3C devised two standards, XML Signature and XML Encryption, which describe ways of applying cryptography to XML documents (see the section “Cryptography: A Minimal Introduction” in Chapter 1). Such standards described extremely ﬂexible operations, in which different parts of the document could be encrypted or signed using different algorithms or even different keys. WSSecurity describes how to apply XML Signature and XML Encryption to a special kind of XML document, the SOAP message. Without going into the ﬁne details, the peculiar structure of a SOAP message offers a natural way to apply the model. The message can be modiﬁed according to the intended operation— for example, by substituting the body with encrypted data—

Security was the ﬁrst advanced capability added on top of SOAP, and it leveraged the work already done for XML

146

Hints Toward a Solution

while the SOAP header can carry a description of the cryptographic transformation that took place. The receiving end of such a message analyzes the content of a special WS-Security SOAP header, discovering that the body was encrypted using a certain algorithm and a certain key; if the receiver owns the corresponding key, he can now reverse the process and decrypt the body. The signature case is analogous. Figure 2-5 illustrates such a SOAP message.

Token

Signature Security Header S

Figure 2-5 A SOAP message whose body has been signed via WSSecurity. The header section contains the WS-Security header, which in turn contains a security token and the signature element itself. The solid line and arrowheads highlight the reference to the part of the envelope that has been signed (in this case, the entire body); the dotted line and arrowheads show the parts that associate the signature with the token containing the associated key. The section S, indicated by the curly bracket, shows the portion of the message that has been signed.

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

147

WS-Security does not introduce any new cryptographic algorithm, nor does it deﬁne any new source of keys. SOAP is a trade language, designed for bridging different platforms and technologies. To effectively support the SOAP mission, WSSecurity needs to be able to accommodate existing security technologies and promote interoperability among those. If it sounds quite similar to what we have seen for the Identity Metasystem and existing authentication technologies, that’s because it is.

WS-Security provides existing cryptographic technologies with a framework for securing elements of SOAP messages

WS-Security needs to be able to encrypt and sign SOAP messages by using the technologies available to its users: X.509, Kerberos, SAML, username and passwords, plus every present and future source of cryptographic material are candidates. However, there cannot be any explicit dependency in the speciﬁcation; otherwise, the good cross-technology properties would be lost. The WS-Security authors devised a clever trick for solving the impasse. The speciﬁcation assumes that the cryptographic material travels in a WS-Security security token, a generic data construct, and refers to it for deﬁning the various encryption and signing operations on the message. Then they separately provided satellite speciﬁcations, named token proﬁles. Each token proﬁle describes how to derive a WS-Security token from an existing security technology, mapping the peculiarities of the particular system to generic WS-Security features. For example, a web service may mandate that the body of the message be signed without specifying the kind of key used. A certain caller may sign using a security token derived from an X.509 certiﬁcate, whereas another may use a security token derived from a Kerberos ticket. As long as the receiving end can verify the validity of the signature—for example, by choosing by a pool of well-known certiﬁcates or by being part of the same Kerberos domain—everything goes as expected. If at some point in the future a new authentication technology is released, and a suitable token proﬁle is deﬁned, the new technology can be seamlessly integrated into the system without requiring any major change. This arrangement effectively decouples the security

The strength of WSSecurity is in the generality of the idea of a security token

148

Hints Toward a Solution

capabilities of the protocol from the technologies actually available, allowing users of different technologies to speak a common tongue while still having a return on their investment on the platform of choice. Those are exactly the good properties we indicated as key requirements for the Identity Metasystem, at a lower abstraction level. As discussed in the following sections, the WS-Security token occupies a pivotal role in realizing an architecture coherent with the vision of the Identity Metasystem described thus far.

WS-Security Tokens and Token Proﬁles At the time of this writing, the current version of WS-Security is 1.1. It is a standard ratiﬁed by OASIS. OASIS lists the following standard ﬁve different token proﬁles:

Username token proﬁle

SAML token proﬁle

X.509 token proﬁle

Kerberos token proﬁle

Rights Expression Language token proﬁle

Being part of the WS-Security standard, those token types can be safely used in scenarios requiring out-of-the-box interoperability; the proﬁles take care of describing the expected behavior in ﬁne detail, such as using AssertionID or ID for referencing SAML assertions crafted using different versions of the SAML standard. Nothing prevents vendors and customers from creating their own token proﬁles, to leverage existing investments in technologies not covered by the ﬁve proﬁles in the speciﬁcation. As long as every actor who needs to use the new kind of token understands it, everything will work as expected.

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

WS-Trust The section “The Babel” in Chapter 1 subdivided the authentication schemes into two big families: the ones based on certiﬁcates and the ones based on issued tokens. WS-Security can handle security tokens derived from both schemes, as long as the requirements expressed by the relevant token proﬁle are applied. Every authentication technology based on issued tokens describes in its own way how a client can obtain a token. The two examples we have seen, Kerberos and SAML, perform that operation in very different ways. WS-Trust generalizes the token-issuance operation to WS-Security tokens. In other words, WS-Trust extends WS-Security with methods for issuing, renewing, and validating security tokens in a platform-agnostic manner. The advantage is evident. Whereas WS-Security assumes that you managed to create your token outside of your web service architecture, using some unspeciﬁed security technology, WS-Trust allows you to also model, in technology-agnostic fashion, the operations necessary to obtain tokens. Thanks to WS-Trust, web services–based systems can now enjoy the ﬂexibility of issued token–based technologies with the added bonus of not being tied to any speciﬁc stack.

149

WS-Trust extends WS-Security with methods for issuing, renewing, and validating security tokens in a platform-agnostic manner

How does that all work? With its 75 pages of dense security considerations, the WS-Trust 1.3 OASIS Standard speciﬁcation is a fairly complex document. A comprehensive description of the standard is beyond the scope of this book. However, it is of paramount importance to understand very well the main scenario and the associated terminology because it is the cornerstone of today’s Identity Metasystem implementation. WS-Trust introduces a special kind of web service, called Security Token Service (STS). To put it simply, the job of an STS is “transforming” WS-Security tokens. One token enters; another token exits. Let’s assume that a certain client C wants to invoke a certain web service S. Let’s also assume that S speciﬁes in its policies

An STS is a special web service that can issue security tokens

150

Hints Toward a Solution

that for security reasons it will accept requests only if secured by a certain WS-Security token, say a SAML-based WS-Security token containing a certain claim about C. C can ask an STS to issue the SAML token it needs for calling S. The request is performed by sending a special kind of message, whose format is described in WS-Trust, called a Request for Security Token (RST). The RST contains, among other things, the description of the kind of token that C is asking the STS to issue. The STS, however, will not issue tokens to just anybody. Because the SAML token required must contain a claim about C, the STS must make sure that is actually C who is requesting the issuance (read, the RST message is actually coming from C). Hence, C must secure the RST message in a way that will convince STS of the correct provenance of the message. In WS-Security terms, this means that C must secure the RST using some security token. For example, C may secure its request to the STS using a Kerberos-derived security token. When the STS receives the RST, it examines the incoming token and checks that it was properly secured. If everything is as expected, the STS considers C’s identity as veriﬁed and proceeds to generate the requested SAML token. The newly generated token is sent back to C inside another WS-Trust-deﬁned message called a Request for Security Token Response (RSTR). When C receives the RSTR, it can extract the requested SAML token and use it for invoking S. Upon receipt of the invocation, S can extract the SAML token and verify whether the claim about C satisﬁes its requirements. Figure 2-6 shows the exchange just described. The end result is straightforward. The STS received a Kerberos token and issued a SAML token in return. At this point, you might be asking yourself where the “trust” aspect in all of this is. The answer to that is simple: The scenario just described was just a fairly elaborate dance for allowing C to beneﬁt from the trust relationship between S and STS.

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem STS RST Kerb

?

SAML

RSTR SAML

C

SAML

S

Figure 2-6 WS-Trust in action. To invoke S, C obtains a SAML token from an STS.

In the generic case, the reason for which C has to go to the STS goes beyond the sheer need of changing token format. Usually S does not trust C, so C needs to be endorsed by somebody who S trusts. Remember our ever-present wine seller example. In this case, the web service S is the wine seller, and the client C is the buyer. The claim requested by S is the age, and the picture ID that the buyer shows to the wine seller is the security token. Just as the wine seller trusts the age written on the picture ID because it is government issued, S trusts the content of the claim in the SAML token because the latter is coming from the STS. The analogy is not a perfect match. If it were, in the ofﬂine world it would mean that your driver’s license (or any other ID document) would always be expired, and you’d have to get one freshly issued every time you need to show it to somebody. In that case, you would need to contact your department of motor vehicles on-the-ﬂy, and they would want to verify your identity (maybe checking your passport) before issuing you a new license. As you probably have already discerned, the department of motor vehicles plays the role of the STS, and your passport

151

152

Hints Toward a Solution

has the same function as the Kerberos token in our diagram. It is okay that the analogy is not 100 percent accurate. Tokens and picture IDs have many similarities, but the former can be used in many more ways and enables scenarios that do not have a counterpart in the ofﬂine world. Besides, we dare the bureaucracy of any administration to issue IDs as fast as an STS can issue tokens! That said, there are still some instructional aspects of the analogy that would be useful to spell out. The wine seller knows that the picture ID shown by the client is true because it recognizes the government manufacturing (e.g., holographic serigraphy or special paper) and implicitly assumes that it is extremely difﬁcult to forge. How can S be sure that the SAML token presented by C was actually issued by the STS that S trusts? The system is much more secure than the ofﬂine counterpart. The STS signs with its private key all the tokens it issues, so anybody knowing the STS public key can verify their source. Furthermore, the wine merchant compares the facial features of the client in front of him with the picture in the ID document, thus verifying that the document was actually issued to the buyer. In the web service world, C demonstrates that the SAML token was actually issued to it by being able to use the token for securing its request to S. In doing to, C is showing off that it knows a certain key that could have been acquired only from the RSTR that contained the token. There is no need to understand the details of that exchange. The bottom line is that S has cryptographic proof that C is the legitimate holder of the token, so the token cannot be fraudulently repurposed by others. In summary, WS-Trust deﬁnes entities and messages for issuing WS-Security tokens via web services. The preceding example explored the scenario in which a client requests that an STS issue a token. However, the speciﬁcation covers many other cases, such as issuance requests coming from services and token management beyond pure issuance (token renewal and validation being two examples). We concentrated on that scenario because, as we observed, it exhibits striking similarities with

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

153

identity-related transactions we encountered elsewhere in the text. In the section “WS-* Implementation of the Identity Metasystem,” we further clarify the parallel. The capability of WS-Trust of expressing trust relationships between parties will play a key role in the realization of an identity layer for the Internet.

SAML: Token or Protocol? You might have noticed that throughout the text the term SAML appears very, very often. As you read in the section “SAML” in Chapter 1, the SAML speciﬁcation deﬁnes a protocol on its own. It has its own ways of dealing with token issuance, for example; and it tries to solve problems such as the single sign-on, which live at a different level of abstraction than the sheer WS-Security speciﬁcation. How does that play with all the “technology-agnostic” rhetoric we used in the sections “WS-Security” and “WS-Trust”? The answer to that question is very simple. Apart from the section “SAML” in Chapter 1, every time we mention SAML throughout this book, we are not referring to the SAML speciﬁcation in itself, but to the SAML token proﬁle mentioned in the sidebar “WS-Security Tokens and Token Proﬁles.” The SAML token format is extremely ﬂexible and proved to be an ideal vessel for security-related information in many scenarios. Used in conjunction with the WS-Security token mechanism and the rest of the WS-* family of speciﬁcations, it lends its expressive power without introducing dependencies on any particular technology. Therefore, for the purpose of understanding the concepts presented in this book, you can safely ignore the protocol portion of SAML. Also note that WS-Federation, brieﬂy described in the section with the same name later in this chapter, presents a certain degree of overlap with the functionalities offered by the SAML speciﬁcation; however WS-Federation is fully integrated in WS-* and works well with any part of it.

154

Hints Toward a Solution

Use WSMetadataExchange for asking a web service about its metadata

WS-SecurityPolicy is a dialect of WSPolicy that deals with security concepts

WS-Federation builds on top of WS-Trust and WSSecurity for modeling message exchanges in federated scenarios

WS-MetadataExchange WSDL and WS-Policy provide means to describe the web service to the world, or better, they help deﬁne the ways in which external callers are supposed to interact with the service itself. In the ﬁrst years of web service existence, those documents were acquired by potential callers out of band or leveraging features of the speciﬁc web service stack implementation. For example, the Microsoft stack made the WSDL of a service available at one special address, obtained by attaching the string “?WSDL” to the address of the service itself. As the web service–based transactions grew in complexity, it became clear that there was the need to deﬁne how to acquire service metadata in a standard and programmatic fashion. WSMetadataExchange is a protocol that fulﬁlls exactly that purpose. It allows one caller to query one web service and obtain its metadata information, typically WSDL/policies. WS-SecurityPolicy WS-SecurityPolicy deﬁnes an assertion framework (that is, a collection of assertions and assertion operators) aimed at expressing security requirements for the invocation of web services. It builds upon the more generic WS-Policy, standardizing how to express requirements such as how to mandate in a message the presence of a security token of a certain shape, which parts of a message should be signed or encrypted and with which keys, and so on. Although WS-Policy is generic enough to express any policy, it is good to have, for security, a set of standard assertions with a well-known semantic to which every platform and product can refer without further negotiations. WS-Federation We already encountered the concept of federation. However, it is worth revisiting the concept. A federation is a set of two or more entities, where resources of one entity can be accessed by identities belonging to another entity. If that sounds confusing, just think of the example offered in the sections “User Control and Consent,” “Minimal Disclosure for a Constrained Use,” and

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

“Claim Transformers.” In that instance, the two entities were a company and its hardware supplier. The hardware supplier was offering access to its web store (the “resource”) to the employees of the ﬁrst company. The two formed a federation. WS-Federation builds on top of WS-Trust and WS-Security, organizing the primitives offered by those speciﬁcations in a higher-level language suitable for modeling systems such as the example just mentioned. In practical terms, given a certain topology of clients, services, and STSs, WS-Federation establishes the sequences of messages that must be exchanged among the various parties for obtaining a certain result. In our simple example, the result is an employee of the ﬁrst company accessing the web store offered by the hardware vendor, but WS-Federation is expressive enough to solve much more complex scenarios such as multicompany single sign-on. WSFederation describes how to deal with those scenarios in synergy with other WS-* speciﬁcations. The case in which the actors are web services is described as the active requestor case. A requestor is active because, being web service capable, you can expect it to be able to use cryptography on the messages emitted and show off the ownership of keys. A comprehensive solution, however, cannot ignore that many transactions are driven through the use of a web browser. A web browser cannot apply cryptography to messages in the same way as a web service can. Hence, this situation must be accommodated by opportunely devising message exchanges protected by transport security. WS-Federation devotes a comprehensive portion of its text for addressing the web browser case, which is referred to as the passive requestor case. WS-Federation is a speciﬁcation of key importance. The explanation we gave here does not even begin to scratch its surface. It is advisable to everybody interested in enterprise identity management to become intimately familiar with this speciﬁcation.

155

156

Hints Toward a Solution

The Identity Metasystem and the practices it enables are often deﬁned as “user-centered federation.” Whereas WS-Federation relies on automatic sequences driven by metadata and by intercompany partnerships, the Identity Metasystem can leverage the newfound user control for driving decisions with much looser relationships between entities. The two models are complementary, and they have ample areas of collaboration and synergy. Chapter 4, “CardSpace Implementation,” discusses how Windows CardSpace handles federation in more detail. WS-* Implementation of the Identity Metasystem

In the previous section “The WS-* Speciﬁcations,” we devoted some time to better understanding the phenomenon of web services. Web services emerged in independence from the identity-related considerations we presented in this chapter, but they are the best tool at the industry’s disposal for putting into practice the requirements discovered while formulating the seven laws and envisioning the Identity Metasystem. Identity Metasystem Components as WS-* Features Let’s put the idea to test. Imagine that the three roles deﬁned by the Identity Metasystem (subject, relying party, and identity provider) are implemented as web services. To be exact, we should say that every role will communicate with the other entities via web services. Holding on to that assumption, let’s recall what the components of the Identity Metasystem were, as follows:

A way to represent identities using claims

A means for IPs, RPs, and Ss to negotiate

An encapsulating protocol to obtain claims and requirements

A means to bridge technology and organizational boundaries using claims transformation

A consistent user experience across multiple contexts, technologies, and operators

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

157

The component-consistent user experience across contexts cannot be addressed directly by a protocol (even if it is the existence of a common metaprotocol that makes consistency possible to begin with). Therefore, we defer consideration about it until after the discussion on WS-*. All the other components ﬁnd perfect ﬁts in the entities and capabilities provided by the WS-* speciﬁcations. A Way to Represent Identities Using Claims The obvious candidate for representing an identity in data exchanges is the WS-Security token. A token is self-contained and claim-based by design, so it owns the necessary expressive power for describing a digital identity as we deﬁned it. The deﬁnition of token in WS-Security and the token-proﬁles mechanism avoids dependencies from existing and future authentication technologies, maintaining the potential to embrace them all. Finally, a token issued by an STS can be tracked with cryptographic certainty to its source. That makes the RSTRSTR transaction described in the section “WS-Trust” the perfect implementation of the process, followed by the S for acquiring an identity from the IP. A Means for Identity Providers, Relying Parties, and Subjects to Negotiate Web services architectures try to keep out of band communication to a minimum, aiming to expose all the information relevant to invocation via standard means. WSDL and WS-Policy, with its specializations such as WS-SecurityPolicy, make explicit to everyone the requirements that must be satisﬁed for being able to use a certain web service. The requirements can cover the most diverse areas, and they can certainly address things especially relevant to the metasystem such as expressing which authentication technology should be used. WSMetadataExchange makes it possible to acquire such requirements directly online, keeping the need for coupling between parties as low as possible. RPs can easily use the tools above for expressing what it takes for engaging in business with them.

The WS-Security token is the perfect ﬁt for representing an identity

WS-Policy and WSMetadataExchange provide an effective way of expressing and negotiating requirements

158

Hints Toward a Solution

WS-Policy and WS-Metadata exchange can easily tell the subject that the web service of an online wine merchant requires a SAML token from the STS of the department of motor vehicles (driver’s licenses), and that such a token must contain a claim with the age of the S. An S can acquire the relevant policies via WS-MetadataExchange and make a match between requirements and capabilities. An IP that would expose its identityissuing capabilities by mean of an STS could specify its requirements using exactly the same speciﬁcations.

WS-Security token generality makes WS-Security ideal as an encapsulating protocol

STSs are natural claim transformers

An Encapsulating Protocol to Obtain Claims and Requirements Because we implemented digital identities using security tokens, it follows pretty naturally that the encapsulating protocol is WSSecurity itself. WS-Security deﬁnes how to attach and use security tokens to messages. Such a deﬁnition does not change regardless of the source from which the WS-Security token was derived, being it SAML, X.509, Kerberos, or any other technology. WS-Security serves the purpose of the encapsulating protocol very well. A Means to Bridge Technology and Organizational Boundaries Using Claims Transformation Claims transformation can be easily performed by an STS. Security tokens are ﬂexible enough to provide the technology and claim types transformations for bridging differences in requirements such as the ones described in the section “Claim Transformers.” The Dance of Identity—Implemented by WS-* Now that we have deﬁned a mapping between the Identity Metasystem and web services elements, we can give concrete indications about how the sequences presented in the section “The Dance of Identity” can be implemented with technologies available today. We will revisit the two sequences, specifying how every step is realized with WS-*.

WS-* Web Services Speciﬁcations: The Reiﬁcation of the Identity Metasystem

The Canonical Scenario Again we have one subject, S, one relying party, RP, and an identity provider, IP. The RP is implemented as a web service; the IP offers its functions by mean of an STS. (An STS that offers IP functions is often referred to as an IP-STS.) S was and remains a person, a human user of the system. For the purpose of this walkthrough, we will assume that S uses some sort of agent that hides the complexities of the web services interactions. We will get back to that agent in greater detail in the section “Presenting Windows CardSpace.”

With this web services mapping in mind, let’s revisit the original sequence under a new light (see Figure 2-7): 1. S wants to call RP. The S’s agent reaches out to the RP

via WS-MetadataExchange, to acquire the RP’s policy and requirements. The WS-MetadataExchange returns a WS-Policy document containing some WSSecurityPolicy assertions. The RP states that it will consider for authentication only the users presenting an identity issued by IP’s STS, in SAML1.1 format and containing Claim1 and Claim2. 2. The S’s agent checks if S has a relationship with IP that

would allow it to ask for a token of the right format and with the requested claims in it. It then presents to S its options (that is, all the courses of actions that will end with the acquisition of a token satisfying RP’s policy). 3. Assuming that S does have a suitable relationship with

IP and that S chooses to pursue that option among the ones offered by the agent, S’s agent uses WSMetadataExchange for acquiring IP’s invocation policy. 4. The S agent uses the information acquired in the former

step for requesting an identity from IP’s STS, by sending an appropriate RST. The agent will also take care of

159

160

Hints Toward a Solution

ﬁnding the token that the IP-STS requested for securing the RST. 5. The S’s agent receives the RSTR from IP, and with it the

required token. The S’s agent returns the token to S. S goes through the experience of examining the details of the identity, such as the content of Claim1 and Claim2, and decides whether it consents to the disclosure of that information to RP. 6. If S decides to disclose, it uses WS-Security for securing

the token obtained from IP the invocation to RP.

WS-Policy WS-Security Policy

IP

5

?

?

SAML Claim 1 Claim 2

SAML Claim 1 Claim 2

WS-Mex 3 WS-Trust 4

S

SAML Claim 1 Claim 2 6

1

WS-Security

WS-Mex

?

RP

IPi IP

2

IP SAML Claim 1 Claim 2

IP SAML Claim 1 Claim 2 WS-Policy WS-Security Policy

Figure 2-7 The schema of the canonical identity transaction, showing which WS-* standards are used for implementing every step

Presenting Windows CardSpace

The preceding sequence uses only technologies in wide availability already today, yet all the requirements imposed by the Identity Metasystem are preserved. If all parties understand WS*, a requirement that does not mandate any particular platform per se, the negotiation capabilities of WS-Policy and WSMetadataExchange guarantee that if there is a match among the parties, it will be found. WS-Security ensures that the speciﬁc technologies are properly tunneled while maintaining a common abstract protocol, whereas WS-Trust guarantees that if there is a trust path between parties, the system will be able to exploit it for ﬂowing identity information. Brokered Trust The case of brokered trust is analogous to the one described in the section “The Dance of Identity.” The rules of mapping to WS-* elements are the same ones demonstrated in the previous section. There is one thing that is worth highlighting: IP2 is still implemented as an STS; however, in the brokered trust scenario it performs pure claim transformation rather than sheer identity provisioning. An STS that performs that kind of function is called a Resource STS, or R-STS, because it takes care of mapping claims for a resource as opposed to providing identities for generic utilization. RSTSs are discussed more in depth in Chapter 4, in the section about federation, and in Chapter 6.

Presenting Windows CardSpace At ﬁrst glance, many of the Identity Metasystem requirements sounded almost utopist. Lucky for us, the WS-* speciﬁcations committees already covered many of the issues we had to face, including the toughest ones involving wide industry consensus, and now the Identity Metasystem can beneﬁt from their work. What sheer protocols can’t address, however, is the human integration aspect.

161

WS-* is the only requirement here. Every entity can be implemented on any platform or technology

162

Hints Toward a Solution

What About the Web Browser? We have seen in detail how web services provide all the necessary power for implementing secure identity transactions. It is common knowledge, however, that as of today the vast majority of interactions on the Internet goes through a web browser. As observed in the section “WS-Federation,” the web browser is passive. If S were to use a browser for performing Step 6 from Figure 2-7, and RP were a website as opposed to a web service, there would be no way of using WS-Security for applying the token to the invocation. The case is easily addressed by using the same trick employed by WSFederation (that is, using transport-based security in the segments of the schema that are not WS-* capable). Note that all the WS-Trust calls do not necessarily have to go through the browser; in fact, in the sequence in “The Canonical Scenario,” those operations go through the S agent, which may be WS-* capable even if the main transaction is being handled by a browser.

WS-* is great, but what about human integration?

The hard-learned lessons from poorly usable systems are captured by the “User Control and Consent” law and, above all, by the “Human Integration” law. Expecting the user to understand WS-MetadataExchange and WS-Trust is possibly even more naïve than expecting the user to be able to assess the identity of a website from its SSL certiﬁcate. Having a solid layer of common protocols is a prerequisite for having a consistent experience across contexts. However, the experience must be good to begin with. Here, good stands for all the criteria established by the laws. The user must understand what is going on, he must be aware of his options, he must be able to make decisions in a natural fashion and be conﬁdent of the expected outcome, he must be empowered to understand with whom he is dealing with, and so on. In the section “The Dance of Identity— Implemented by WS-*,” we described in detail how the two most common scenarios in the Identity Metasystem are implemented via web services. In those sequences, we have seen

Presenting Windows CardSpace

163

how all the negotiations and low-level protocol interactions were performed by an agent. The subject examined the data summarized by the agent and directed its behavior for executing the subject’s behavior (for example, disclosing a certain claim to a speciﬁc RP). The agent decoupled the subject from the complexities of the underlying system, leveraging all the good properties of the protocols for acquiring as much data as possible and presenting information to the subject in the best way for enabling truly informed decisions. Windows CardSpace is the implementation of that agent on the Windows platform. It enables Windows users to participate in the Identity Metasystem, taking care of the nitty-gritty details of RP and IP communications while presenting to the user an intuitive façade. Some form of user agent is a necessity, imposed by the human-integration requirements of the Identity Metasystem. As long as the trafﬁc generated abides to the open protocols we have seen so far and the UI provides an experience compatible with the identity laws, every platform has the freedom to come up with its own (or even more than one) agent. Apple Macintosh and Novell Linux are examples of non-Windows platform for which a user agent is already available. Although there are no guarantees that the experience will be replicated verbatim on every selector and on every platform, thus far the card metaphor is being consistently used across the various projects.

Windows CardSpace enables Windows users to participate in the Identity Metasystem

CardSpace is what allows Windows users to experience situations like the wine seller example in an extremely natural fashion, where having your age veriﬁed is as simple as clicking a picture of your driving license on the screen. Where the user experience is just natural gestures and the control that derives from it, the system supplies all the intelligence necessary for probing services for policies or calculating what it takes for obtaining a token from a certain STS. Windows CardSpace is intimately tied to its platform. Whereas the trafﬁc it generates is entirely based on the WS-* open standards we mentioned, and hence virtually indistinguishable from the output of user agents

CardSpace presents the user with an easy metaphor, but under the hood it uses the full power of WS-* and the Identity Metasystem

164

Hints Toward a Solution

on other platforms, the user experience and operating system integration take full advantage of Windows peculiarities and security features. The experience has been designed for the ground up for abiding by the identity laws. The remainder of the book is dedicated to exploring how CardSpace puts the user in control of his own destiny, by fully leveraging the possibilities offered by the Identity Metasystem.

Summary Where Chapter 1 described problems and shortcomings, this chapter gave hope about the existence of a sustainable solution. We started by stressing the need for reaching a solution that would satisfy all online players. We went on exploring the current thinking about identity systems, showing how past errors and success stories were distilled through an industry-wide dialog on the seven laws of identity. We introduced the Identity Metasystem, an abstract model that addresses the common issues of identity management in full respect of the identity laws. We have seen how the Identity Metasystem is not an alternative proposition to today’s technology, but rather a further level of abstraction that relies on current systems and facilitates interoperability. Such a design choice guarantees investment protection and makes the solution future-proof, gracefully accommodating yet-to-be invented protocols. We spent a fair amount of time on the WS-* speciﬁcations, understanding their role in the industry and digging into the details of the standards that are more relevant to the identity space. Once we gained more practical knowledge of web services, we were ﬁnally able to put all the pieces together and deﬁne a solid architecture for the Identity Metasystem model.

Summary

After the protocol aspects were all addressed, we deﬁned the role of CardSpace as the user experience designed for empowering Windows users to be ﬁrst-class citizens of the Identity Metasystem. This chapter concludes Part I of the book, devoted to understanding the problem we are trying to solve, the solution in its entirety, and the intended role of CardSpace in the grand scheme of things. The remainder of the book focuses exclusively on CardSpace. What it is, how to use it, and how to design systems that take full advantage of it. Part II introduces the technology and the basic use cases from the user and developer viewpoints. Part III then goes into more depth about what it means to be an RP or an IP.

165

This page intentionally left blank

Part II

The Technology

Chapter 3

Windows CardSpace

169

Chapter 4

CardSpace Implementation

Chapter 5

Guidance for a Relying Party

223 269

167

This page intentionally left blank

3

Windows CardSpace Now that the advantages of the Identity Metasystem have been explained, let’s take a look at what Windows CardSpace is and how it works with the metasystem to provide a ﬂexible, usercentric model for managing digital identities. This will provide a strong foundation for understanding CardSpace, including what the typical user and web developer experiences look like. In addition, this chapter explains what data is on a card and what a card actually represents. This discussion is followed by an overview of some of the common tasks a user might want to perform in CardSpace.

CardSpace Walkthroughs A good way to begin understanding Windows CardSpace is to see an average user’s experience and then take a look at the same scenario from a web developer’s perspective. This gives a well-rounded view of a CardSpace interaction.

A good way to start understanding CardSpace is to see it in action

169

170

Windows CardSpace

This sample walkthrough demonstrates a common CardSpace scenario: logging in to a website. The site is able to request different type of cards, which contain different information; in this case, only an email address is requested. From the User’s Perspective CardSpace can be opened by a simple user action, such as a button click

When users go to a site that uses CardSpace, they will see a logon button that they can use to submit an Information Card. Figure 3-1 shows a very simple example.

CardSpace displays site information to help the user make an informed decision

When the button is clicked, CardSpace opens and shows the identity of the site that is requesting a card. This page, shown in Figure 3-2, can help the user evaluate the site and make a decision as to whether to use a card. This page appears only the ﬁrst time a card is used at a site and can be a cue to users to pay special attention to the page they are visiting. If users think they are returning to a site that they frequently visit, but this page comes up, it could be a tip-off of an attempted phishing attack.

Users are in control; they can pick the cards they want to use

Users are then shown their cards so that they can pick which one they would like to send (see Figure 3-3). To start with, the user will have no cards, but in this example the user already has several. Creating cards is covered later in the chapter.

Figure 3-1

A typical Information Card logon control

CardSpace Walkthroughs

Figure 3-2 The Relying Party Identiﬁcation page helps the user identify the site that is requesting a card.

Figure 3-3 CardSpace’s Card Chooser lets users pick the card they want to use.

171

172

Windows CardSpace

The information to be disclosed about the user can be reviewed before sending

The cards that appear in CardSpace are referred to as Information Cards; this is a general term that can be used by any Identity Selector that uses cards to represent digital identity. By double-clicking one of these cards or clicking the Preview button when a card is selected, the user can see the information that the site requested and the values that the identity provider (IP) will provide for the requested values. As shown in Figure 34, the site in this example requires only an email address, and the IP provides the value [email protected]. After the user reviews the information that will be disclosed, the card is sent to the site by clicking Send. This doesn’t really send a card, of course, but rather releases a security token to the website that would be used to identify the user. This should all look pretty simple. The UI ﬂow is meant be usable to the broad computer-using community, and the use of the card metaphor in the UI really helps make the process tangible.

Figure 3-4 The Card Details page lets the user review the information that will be sent.

CardSpace Walkthroughs

173

From the Web Developer’s Perspective

CardSpace-enabling a website takes minimal work for a web developer. However, a few key components must be implemented:

HTTPS Login page. The certiﬁcate from the SSL connection is shown to the users to help them identify the site.

Information Card tag. This tag will open CardSpace and allow the site to specify which claims it is requesting, as well as other policy-related information.

Token Processor page. When the security token is returned, the website will need to verify the digital signature on the token, as well as retrieve the requested claim values

HTTPS Login Page The requirement to use HTTPS is meant to help the user be able to identify the page that is requesting a token, as well as provide extra security as the token is transmitted back to the website. The Secure Sockets Layer (SSL) certiﬁcate provides extra assurance when a site is requesting sensitive information or protects an important resource, such as a bank account. In other cases, even though certiﬁcates can be bought fairly cheaply, this requirement of using HTTPS can be a barrier to deploying CardSpace on some smaller sites. This is why as part of the .NET Framework 3.5, the requirement that an SSL certiﬁcate be used was removed. However, it is still recommended for sites that want the strongest security because without it the token from CardSpace will not be encrypted, and the user will not be able to identify the site to the same level of certainty.

An HTTPS page provides stronger security and better identiﬁes the site

174

Windows CardSpace

Only a simple tag is required for a site to use Information Cards

Information Card Object Tag To use CardSpace at a website, an Information Card tag is needed. This can simply be placed in a standard HTML form, as shown in the following example: “ />

Notice the method is set to “post” and the action is set to “TokenProcessingPage.aspx”. These attributes are standard for all HTML forms and specify to which page the value of the elements inside the form will be sent. In this case, it is the token, returned from the Information Card object, that will be posted to the speciﬁed page. The tag type is set to “application/xinformationCard”, which is the ActiveX object that calls CardSpace. The next line speciﬁes the required claims; in this case, only the email address is being requested. In the example, the claim URI is shortened for clarity; the full URI is “http://schemas.xmlsoap.org/ws/2005/05/identity/claims /emailaddress”. When the Submit button is clicked, CardSpace

will open, requesting a token that contains the email address, as in the previous walkthrough.

A Token Processor page is needed to get information from the token

Token Processor Page The Token Processor page receives the post from the page hosting the Information Card tag. This is a standard forms post, and the returned token will be posted using the name of the tag (in this example, “CardSpaceToken”). The token is then passed to code to process the token. This code can be written in

Is CardSpace Just for Websites?

175

any language, including C#, VB.NET, Java, and PHP. It is up to the website to decide which libraries best ﬁt with their deployment.

Is CardSpace Just for Websites? CardSpace provides a consistent user experience for accessing digital identities across a range of applications. The ﬁrst version of CardSpace supports four main categories of applications.

Web pages. This is one of the major areas of focus for CardSpace. Web page developers need to make minimal changes to their HTML to support CardSpace. This can be done by using the ‘application/xinformationCard’ tag. There are also a number of tool kits available to help with deployment.

Rich applications using web services. Windows Communication Foundation (WCF) supports CardSpace and greatly simpliﬁes writing a web service with a clientside application that uses CardSpace for authentication. Often switching from one authentication type (such as username and password) to Information Cards is as simple as changing a few lines in the web services conﬁguration ﬁle.

Managed-code applications. These are applications that don’t use WCF but still have reason to use CardSpace. All the CardSpace APIs exposed to WCF are also exposed to a managed application in the System.IdentityModel.Selectors.dll assembly.

Native-code application. The CardSpace APIs are also available to native applications by including the infocardapi.dll.

These different types of applications are discussed in further detail in Chapter 4, “CardSpace Implementation.”

CardSpace works with a variety of applications

176

Windows CardSpace

System Requirements CardSpace installs with .NET Framework 3.0 and later

CardSpace is a client-side application and has speciﬁc requirements to run. To take advantage of all the features CardSpace has to offer, one of the following conﬁgurations is recommended:

Windows Vista. This is the easy one. All the required components are installed by default.

Windows XP SP2. Requires the .NET Framework. Version 3.0 or 3.5 must be installed as well as Internet Explorer 7. Both are free downloads from the Microsoft website. To take advantage of all the CardSpace features in version 3.5, an updated Internet Explorer 7 ActiveX control also needs to be installed.

Windows Server 2003. This also requires that the .NET Framework version 3.0 or 3.5 and Internet Explorer 7 be installed.

.NET Framework 3.0 (or 3.5) is always required to run Windows CardSpace because it contains the core CardSpace system components. They also install components that CardSpace requires: the Windows Communication Foundation and the 2.0 Common Language Runtime. CardSpace can work with different browsers

Internet Explorer 7 (IE7) is necessary because it has support for the Information Card tag. As previously shown, the tag is required to allow web developers to request a token from CardSpace. Technically speaking, IE7 is not a requirement to use CardSpace. It is only used when the RP is a website. In addition, CardSpace is designed to be used by non-Microsoft developed browser plug-ins, too. This can include controls that run in other browsers, such as Firefox.

What CardSpace Provides

177

Does Firefox Work with CardSpace? It might come as a surprise that other browsers can work with CardSpace. Isn’t CardSpace a Microsoft technology? CardSpace works with all browsers, particularly ones that have broad adoption like Firefox; this is really a requirement if the Information Card model is to become ubiquitous. To encourage the development of other plug-ins that work with CardSpace, the GetBrowserToken() method that installs with CardSpace is available in infocardapi.dll This is the same method that is called by IE7, and it makes it simple to prompt a user for a digital identity from CardSpace. Firefox 3 has plans to ship with a CardSpace plug-in. Also a working plug-in can also be installed from http://perpetual-motion.com/. It is likely that more implementations will follow.

What CardSpace Provides To understand the value that CardSpace provides, it is important to have a solid grasp of the Identity Metasystem, which was covered in Chapter 2, “Hints Toward a Solution.” CardSpace plays a key role in the Metasystem as an Identity Selector. The value that an Identity Selector provides is as follows:

A consistent user experience that keeps the user in control

An identity framework that can broker trusted interaction between a RP and IP

Increased security and phishing protection

CardSpace in an Identity Selector

Consistent User Experience

Why is a consistent user experience so important? A good user experience is one that feels intuitive to the typical user. If the user experience is consistent across applications, users will be

Consistent experience helps put the user in control

178

Windows CardSpace

able to understand the steps in the process without a deep understanding of the underlying technology. Users will become accustomed to the routine involved while providing digital identity and will know what to expect each time they are involved in an interaction using their digital identity. Having a consistent experience allows the user to anticipate what the experience will be like across applications. Then, if something outside the expected routine occurs, this can help alert the user that something is amiss. A consistent user experience increases security by making the user a more knowledgeable participant in securityrelated transactions.

Information Cards are not physical cards

Why Cards? A common misperception about Windows CardSpace and Information Cards is that they are a technology that uses a physical card that can be carried around in your pocket. This isn’t the case, of course; Information Cards are not real cards. They are simply virtual representations of digital identity. However, those thoughts of real cards that get conjured up are intentional because the model was meant to give the user the impression that these are easy to understand objects that can be used in predictable and intuitive ways. The idea is that the user knows how to use real cards, so he or she can easily adapt to virtual ones.

Other Identity Selectors Although CardSpace is the Microsoft implementation of an Identity Selector, it is not the only one. The protocols and standards used by CardSpace are intentionally available for others to use and build interoperable systems. Work is being done on several different implementations of Identity Selectors that can run cross-platform, including Mac and Linux. Notable is the Bandit Project’s DigitalMe Identity Selector. To learn more about non-Microsoft offerings that work with the Identity Metasystem, check out the Open-Source Identity System (OSIS) site at http://osis.netmesh.org.

What CardSpace Provides

For Information Cards to provide a truly effective user experience, they need to mirror our real-world experiences with physical cards. That is why the card metaphor was selected; it is very ﬂexible and naturally satisﬁes the scenarios that require digital identity. In fact, cards work so well as a representation of digital identity, looking at the cards in your wallet is a very illustrative way to think about Information Card use cases. For the sake of illustration, let’s examine a few of the real-world usage scenarios where physical cards are used:

Thomas works at a high-tech company. Every morning he swipes his card key, and the built-in RFID identiﬁes him and grants him access to the building.

Katie is a university student and can get a bus pass sticker for her ID card each quarter. When she wants to take the bus, she just needs to show the pass to the driver.

Scott stops by the corner store to buy some beer. First he shows his driver’s license to prove he is of legal drinking age, and then he uses his debit card, along with a PIN, to complete the purchase.

At the grocery store where Liz shops, they’ve given her a club card that she can use to get discounts on items she buys. The store then tailors advertising to her based on her shopping habits. The logo on the card serves as a way for the store to advertise.

Of course, there are many more such examples, such as library cards and all membership cards in general. What’s striking is the wide range of uses these cards can have, but they all exhibit a similar routine in how they are managed and used. This has great advantages when somebody is given a new card because there is normally no learning curve. And when somebody asks for a card, users have a strong understanding of what that means and what information they are releasing. That’s the exact type of experience Information Cards are meant to provide.

179

Information Cards can be used in situations similar to those in which we use physical cards

180

Windows CardSpace

Can What’s in Your Wallet Stop Phishing? Picture the cards in your wallet; you are probably pretty familiar with them. In fact, if you picked up a wallet on the street that was identical to yours but containing somebody else’s cards, you’ll have a pretty immediate reaction. (Hey, this isn’t my wallet!) The CardSpace UI creates a similar experience. As you accumulate cards and customize them with images or name them, you start to have a personalized card collection. Why is it signiﬁcant that a user be able to easily identify their cards? It makes it harder for a malicious page or application to try to spoof the CardSpace experience. The malicious application can create a user interface that looks like CardSpace (just like I can buy a wallet that looks like yours), but it’s much more difﬁcult to guess the cards users have and consequently difﬁcult to trick them into thinking they are really using CardSpace. This is designed to raise the bar on phishing or spooﬁng attacks, where otherwise a user may be tricked into an experience that looks like the CardSpace UI but which is actually designed to woo users into believing they are in a trusted experience and then to release sensitive information. If users have a gut reaction when presented with this type of experience (Hey, this isn’t my CardSpace!), they are less likely to fall for this type of scam.

Having an intuitive understanding of cards makes it easy to select the right card

Another interesting thing about cards is that even though the cards in the usage scenarios have similarities, it’s easy for users to understand which card to use in a given context. When Katie gets on the bus, she can easily understand that she needs to show her bus pass; she doesn’t need to stumble through showing each card in her wallet until she comes across one the bus driver will accept. Similarly, when users are asked to submit an Information Card to a site, they can use the context in which they are using the card to guide them. In most cases, it will be clear that they are submitting a card to identify who they are, to make a purchase, or to prove that as a member of an auto club that they deserve 20 percent off a hotel reservation. Thinking of

What CardSpace Provides

181

digital identities as cards makes the task of selecting the correct identity easy for an average user. The user’s experience is also simpliﬁed in more complicated situations where several different digital identities could satisfy a particular request. This is a potentially confusing situation; however, given the context of the interaction, users can select the card they want to use. For instance, users could have a card that they like to use when browsing the web that has a fake name and rarely used email address and another card that they use when shopping that has their real name and main email address. Based on the site users are visiting, it is easy to select the identity they want to use. By putting users in control and empowering them to understand the identity transaction, the ﬁrst law of identity, “User Control and Consent” (see Chapter 2), is realized. Brokering Trusted Interactions

One of the crucial aspects of physical cards that also applies to Information Cards is the brokering of trust from the IP to the RP. Why does the person to whom you are showing your card (the RP) believe that the card really contains information about you (the subject) and that they can put trust in the fact that the information is being asserted by a trusted third party (the IP). Or to put it another way, when Scott goes to buy his beer, why does this clerk believe the ID card proves Scott can legally purchase alcohol (and that the ID card isn’t borrowed from a friend) and that it was actually issued by the department of motor vehicles? This demonstrates a brokering of trust, where the RP can believe the statements made about a subject without directly contacting the IP. The following must be proven to be true for the transfer of trust to succeed:

The information on the card is truly being provided by a trusted party.

The information applies to the subject presenting the card.

It is essential that the source of the information on a card can be veriﬁed

182

Windows CardSpace

In Scott’s case, the watermarking and other details on the card make it hard to reproduce, so it can be trusted that it really was created by the department of motor vehicles, which satisﬁes the ﬁrst condition. The second condition is met by the picture of Scott on the card, which the clerk can use to identify that the card does apply to Scott. The other usage scenarios previously listed show the variety of ways that these conditions can be met. Information Cards broker trust in the same manner that real cards do. The technology that is used to ensure the information comes from the IP is different because it is a virtual card rather than a physical card. In addition, the means by which the user proves that the information refers to them may vary, but the way the user can conceptualize the interaction is the same. Digital signatures are used to prove the source of information

Proof that the information actually is provided by a trusted IP is provided by using a digital signature over the token, which contains the information (claims) that is being asserted. The signature can be cryptographically veriﬁed as having been produced by the IP. Figure 3-5 shows Scott’s information that has been signed. Any token format may be used to express the claims and their values, as long as it is understood by the IP and RP. The current

Figure 3-5 The claim values in the CardSpace security token are wrapped inside of a digital signature of the IP. This guarantees it is the IP that is asserting the claims.

What CardSpace Provides

standard is to use a SAML1.1 token. This is just a standard; CardSpace is token-agnostic because it is just negotiating the interaction between the RP and IP. This interaction is illustrated in Figure 3-6. The steps in the interaction are as follows: 1. The RP makes a request. When the user tries to access a

resource, the RP can make a request for a security token. This request contains details about the format of the token it wants, who it wants the token to be issued by, and what information (claims) it wants in the token. 2. The user picks a card. Based on the request, the user

selects the card he wants to use. 3. The request is forwarded to the IP. The card the user

picks is supported by a speciﬁc IP. When the card is selected, a request for a security token is sent to the IP. In this request, the user will also provide some authentication information, to prove who he is. (This is discussed in more detail later in the chapter, in the section “Authentication with an IP.”) 4. The IP returns a security token. Satisﬁed that the user is

who he says he is, the IP returns a signed security token. 5. The user reviews the token. The IP can provide display

information, so CardSpace can show the user what information is being disclosed. 6. The token is returned. The token that was requested is

returned to the RP, and it can make an authentication decision. Chapter 2, in the section “The Seven Laws of Identity,” discussed the value of the second law of identity: “Minimum Disclosure for Constrained Use.” CardSpace’s use of claims follows this law. Because the RP can be very speciﬁc about the information it needs, the IP can limit the information it includes

183

184

Windows CardSpace

Identity Provider

Relying Party 3. Request is forwarded to IP.

4. IP returns security token.

1. RP makes request.

2. User picks a card.

6. Token is returned.

CardSpace

5. User reviews token.

Figure 3-6

The request made by the RP being brokered to the IP

in the token to what is actually being requested. There is no need to see all the information the IP knows about the user.

A Deeper Look at Information Cards Cards contain information about how they can be used

An Information Card is a collection of data that represents a digital identity. Information Cards contain metadata necessary for the use of the digital identity that the card represents. As previously discussed, these cards are not physical cards, but virtual cards that can be managed on your computer. Each of these digital identities is an expression of what the IP is willing to assert about the user. A user can have cards to represent different aspects of the identity or different identities, such as the following:

A driver’s license

A bank account

An identity in an online video game

Information Cards can be used anywhere that a person wants to convey data about themselves to another party.

A Deeper Look at Information Cards

The metadata contains the information needed to connect to the IP and request a security token. The metadata also provides CardSpace with information about the digital identity that the card represents so that it can help guide the user. The main data contained in a card includes the following:

Display information. This can include an image to use on the card, as well as a name for the card.

Where to contact the IP. The identity exposes a web service that produces the security tokens; naturally enough, this is called the Security Token Service, or STS. The URL of the STS is contained within the card.

How to authenticate to the IP. Along with containing where the STS is published, it is also necessary to know what authentication the user will need to perform to retrieve the security token.

Supported claims list. Data expresses the types of claims an IP will provide. This list of types of claims is used by CardSpace to help direct the user to a card that supports the claims that a RP is requesting.

Supported token types. Data expresses which types of tokens an IP can produce. This generally includes SAML1.1, but is up to the IP to determine. The list of supported token types is also used by CardSpace to help direct the user to a card that can satisfy the request.

Issuer name. This is a particularly important value for helping CardSpace to guide the user to a card that can satisfy the current request. It is a logical URI that refers to the IP. Because the URI is logical (doesn’t refer to a physical address), multiple STSs can represent the same IP. This may be useful for many different reasons, such as setting up a fallback STS or deploying STSs for different geographic regions.

185

186

Windows CardSpace

How Does CardSpace Help the User Select a Card? When a request for a security token is made by an RP, CardSpace matches up the request with available cards. The following matching criteria are used:

Which IP is being requested

What claims are being requested

What token type is requested

If the card cannot satisfy the request, CardSpace turns the card image a dull gray and provides text explaining why the card cannot be used. Also, if the currently selected card can’t satisfy the request, the send button is disabled. All of this is done to help make the user experience ﬂow smoothly and make it easier for users to select the correct card.

The information about the user is not in the card. The IP stores the personal information such as age or Social Security Number, and thus the information is stored at the STS and requires some form of authentication to retrieve. The separation of the user’s information from the Information Card is shown in Figure 3-7. Sensitive Managed Card data is stored at the IP

Imagine a bank issues an Information Card that can be used as a credit card. When people shop online and want to use the card, they authenticate to the credit card STS. How this authentication is done is covered in more detail later in this chapter, but one method is by using a smartcard. After authenticating users, the IP sends back a token that contains their credit card information, which is then sent to the RP. Now the question is what if somebody installed this card on his laptop and the laptop got stolen—can the thief now use the card to go on a spending spree? The answer, is no, not without the smartcard, or knowledge of how to authenticate to the IP as the user. The valuable data is not stored on the laptop; it is back at the credit card STS.

A Deeper Look at Information Cards

The Information Card contains the web service URL of the identity provider’s STS; for example, URL = http://mySafeID.

It is used to request a security token from the identity provider STS.

The identity provider STS keeps the actual data, such as credit card numbers.

Figure 3-7

The claim values are kept at the STS, not on the card.

Without some way to authenticate to the STS, the thief cannot gain access to the data. It is similar to somebody getting the URL to the login page of your bank’s website. There’s nothing really interesting to be gained, unless there is some way to authenticate. Information Cards are just a pretty wrapper around the details of how to connect to a web service that the average user is not interested in knowing. The digital identity is asserted by the security token that is returned by this service. Card Types

Information Cards come in one of two different types. The main difference between the types of cards is the location of the STS that the card references and where the claim data is stored.

Personal Cards use an STS that installs with Windows CardSpace. It allows users to express information about themselves to relying parties. Personal Cards generate unique identity information and keys for cryptography to enable users to uniquely and securely identify themselves. Creating a Personal Card is as simple as a couple of clicks in the CardSpace UI.

187

188

Windows CardSpace

Managed Cards use an STS on a remote machine. This service is typically provided by a third party, who can provide a card to a user, and then after users have authenticated themselves to that provider, issues a token containing the data that the provider is willing to release. This is accomplished through a WS-Trust RST/RSTR exchange, as discussed in Chapter 2, in the section on WSTrust. The process by which an IP provides this card to a user is covered in greater detail later in this chapter.

Personal Information Cards Users can create and manage their own identities

CardSpace supports user-created identities in the form of Personal Cards. Although the claims in such identities are not veriﬁed, they can be very useful. CardSpace essentially enables users to convey information to an RP, without having to type the same set of fairly commonly used ﬁelds over and over. Users are restricted in the types of claims that Information Cards support. CardSpace only supports a ﬁxed set of claims. Table 3-1 lists these claims. Table 3-1

Claims Supported by Personal Cards

Claim URI

Claim Purpose

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ givenname

Given (ﬁrst) name

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ surname

Surname (last name)

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ emailaddress

Email address

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ streetaddress

Street address

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ locality

Name of city or town

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ stateorprovince

State or province

A Deeper Look at Information Cards Claim URI

Claim Purpose

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ postalcode

Postal code (ZIP code)

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ country

Country

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ homephone

Home phone number

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ mobilephone

Mobile phone number

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ otherphone

Alternative phone number

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ dateofbirth

Date of birth

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ gender

Gender

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ website

URL of a website

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ privatepersonalidentiﬁer

A site-speciﬁc identity

189

Why Would an RP Accept a Card the User Created? At ﬁrst glance, it seems strange that an RP would accept a card, or digital identity, that a user created for his own use. Isn’t it better to have a trusted IP manage the digital identity? It really depends on what that identity is being used for. If the claim values need to be certiﬁed by a third party, such as when doing age veriﬁcation, the card should come from a trusted third party. However, if the card is being used to log the user on to a site and to prove on repeat visits that it is the same user, the Personal Card ﬁts the bill. The cryptographic keys generated for each Personal Card provide strong assurance that the same card is being used. The Personal Card can also be used in cases where the site is willing to trust the user to ﬁll in

190

Windows CardSpace

accurate claim values. Typical claim values that the user might provide are email address, name, and street address. This is on par with how most information is collected on the Internet today—users can sign up with various websites without any third-party conﬁrmation of the details that they provide to the website. This is the case when a user creates accounts at web commerce sites or blogs. He provides information in a web form without any third-party validation, and the site accepts it without question.

User-created identities contain lowvalue information

Note that the claims supported by Personal Cards are not very sensitive; that is, while the information describes the person, it does not expose his private data, such as credit card numbers, account numbers, Social Security Number, and passwords. By restricting the claims that Personal Cards support, CardSpace stops the user from inadvertently exposing those kinds of private data to other parties. In addition, because the Personal Card STS is on the user’s machine, the data is also on the user’s machine. By keeping only the less-sensitive data on the user box, there is less to motivate attackers to try and compromise the system; and if they do compromise the system, there is little to gain in terms of personal user information. As the issuer of the Information Card, the user has the capability to modify the values in the claims of the card, except the private personal identiﬁer.

A card can be uniquely identiﬁed by its PPID

Unique Personal Cards If the user has the capability to create a card that has all the same data for the claims in it, how can an RP use such cards for authentication? The answer lies in the implementation details of the claim represented by the URI http://schemas.xmlsoap.org/ ws/2005/05/identity/claims/privatepersonalidentiﬁer. This URI represents a piece of data that is called a private personal identiﬁer (PPID). This claim is not editable by the user; instead, it is generated by CardSpace.

A Deeper Look at Information Cards

With every new Personal Card that is created in CardSpace, a master key and card ID are generated and stored with the card. The card ID contains a randomly generated globally unique identiﬁer (GUID). The master key is 32 bytes of random data. Because each card generates a card ID and master key, each card is different from the last. For each RP that the user visits, CardSpace uses properties from the RP’s certiﬁcate, along with the card ID, to generate a unique PPID. If the RP does not have a certiﬁcate, the domain name from the site URL is used instead. It also uses elements from the RP’s certiﬁcate, along with the master key, to create a cryptographic public/private key pair. Because the PPID and the cryptographic key pair are unique to a speciﬁc Personal Card, when it is used at a speciﬁc RP, the relying party can use the PPID and keypair to validate which card is being used. To create this mapping, the RP would save the PPID in the token it gets from CardSpace and the public key in the token. Then when a card is submitted, it associates this information with an account. When subsequent tokens are submitted with the same PPID and public key, the RP can identify that it is the same user and log him in to the associated account. Figure 3-8 shows how these two identiﬁers are created using the RP certiﬁcate. Two very signiﬁcant features follow from this. First, because users now have something speciﬁc only to them and that cannot be derived from other information, users can use that to identify

Relying Party’s Certificate

Relying Party’s Certificate

+ +

Card ID

Master Key

PPID

Public/Private Key Pair

Figure 3-8 The card’s PPID and cryptographic keypair are generated when visiting a site.

191

192

Windows CardSpace

themselves to a party. Second, because the PPID and cryptographic keypair are generated using information that differs for each RP, either the certiﬁcate or domain name, the values generated are also different for each RP. This means, by default, the user is not transmitting some global identiﬁer. The PPID is different for each site and as such helps protect the user’s privacy

This fulﬁlls the promise of the fourth law of identity: “Directed Identity.” Different RPs get different identity identiﬁers from users, which increases the protection of their privacy by ensuring that RPs cannot simply correlate information behind the backs of users.

How Is the RP Certiﬁcate Used? It is important to understand how CardSpace uses the certiﬁcate to generate the PPID and keypair so that the same values will be generated when certiﬁcates change or when there are multiple servers supporting a site. Most X.509 certiﬁcates deﬁne the subject of the certiﬁcate by specifying a subject Distinguished Name (DN) that looks something like “CN=www.contoso.com O=Contoso L=Redmond S=WA C=United States”. As shown in this example, the CN is usually the domain name of the site; O is the organization name; and L, S, and C give local, state, and country information. For an Extended Validation (EV) certiﬁcate, CardSpace use the O,L,S, and C (OLSC) values from the certiﬁcate to help generate the PPID and keypair. When certiﬁcate keys are refreshed or the same organization deploys CardSpace on different sites, the self-issued token identiﬁers will stay the same as long as OLSC remains the same. Non-EV certiﬁcates follow a similar rule. However, in addition to the OLSC of the RP certiﬁcate, the OLSC of all the certiﬁcates in the certiﬁcate chain are used. This means the certiﬁcate chain must also remain the same when the RP certiﬁcate is changed.

A Deeper Look at Information Cards

193

The PPID generated by CardSpace is sent to the RP as a Base64encoded SHA1 hash. Here is an example of such a hash: RJzXlauo+mGTa6UlmyK7cCzSmNbFUuJXpsh/yMQLa7s=. Occasionally, the RP and the user may need to communicate about which speciﬁc card was used at the site. For example, if users want to remove a particular Personal Card from their account, but the claims on all of their cards are identical, the only way for users to know the difference between the two is the PPID. Yet, a 40-digit hexadecimal string is unwieldy for users to read off during a support call, so CardSpace instead displays the PPID claim to users as the “site-speciﬁc card ID,” which is a 10digit representation of the PPID that CardSpace has generated. Figure 3-9 shows the site-speciﬁc card ID, as shown in CardSpace. Although it may be tempting to use only the PPID to identify a user, one additional check must be done to ensure maximum

Figure 3-9 CardSpace displays the site-speciﬁc card ID when the PPID claim is requested.

The key used to sign the token must also be checked

194

Windows CardSpace

security. The token produced by CardSpace for Personal Cards is a SAML1.1 assertion, which contains the public key of the card for that RP. Like the PPID, the public key is unique to the relationship between the RP and the card. The security token is digitally signed by the private key. This signature provides strong cryptographic proof that the token was really created by the owner of the card. The PPID is a weaker form of identiﬁcation. If somebody somehow sneaks a peek at the contents of the security token, he will ﬁnd out the PPID of the user, and he could create his own token that contains that PPID. When the attacker saw the original token, he would also discover the public key in the token. But it is of no real value to the attacker because it is the private key used for the signing, so the attacker would be unable to generate an imposter token if the RP veriﬁes the PPID and the public key of the incoming tokens. If the system only uses the PPID, the security of the system is based only on a shared symmetric key, rather than a much stronger asymmetric key.

Personal Cards can be an easy way to improve security on most sites

Uses of Personal Cards Personal Cards can be used in a wide variety of situations that exist on the Internet today. As a replacement for username and password authentication, Personal Cards provide a new level of security, along with usability. In addition, the convenience of providing common data to websites can signiﬁcantly lower the likelihood of “drop-off” on new account sign-up. It also makes it easy for users to keep information current at sites where they use cards. If users update their home phone numbers, the next time they use a card at a site it will automatically get this new information, without users having to remember to “update their proﬁle.” Finally, with users able to create as many cards as they want, each different persona that they want to have is easily accommodated.

A Deeper Look at Information Cards

195

How Is the Site-Speciﬁc Card ID Calculated? The purpose of the site-speciﬁc card ID is to provide a user-friendly form of the bytes in the PPID. To create the site-speciﬁc card ID, ﬁrst the PPID bytes are hashed with a SHA1 hash function. Next, the ﬁrst 10 bytes of the hash are taken and each is divided by 32. The remainder of each division is saved, yielding 10 numbers, ranging between 0 and 31. Each number is then mapped to a character using the Table 3-2. So if the numbers were (5,23,13,11,16,8,20,12,5,31), the resulting ID would be 5RD-BG8M-C5D. Table 3-2

Character Mapping Table

Range

Character

Range

Character

0

Q

16

G

1

L

17

H

2

2

18

J

3

3

19

K

4

4

20

M

5

5

21

N

6

6

22

P

7

7

23

R

8

8

24

S

9

9

25

T

10

A

26

U

11

B

27

V

12

C

28

W

13

D

29

X

14

E

30

Y

15

F

31

Z

An intentional property of the characters chosen is to avoid confusion by omitting characters that look similar. For instance notice that no numbers map to zero (0) or the letter O.

196

Windows CardSpace

Managed Information Cards Managed Cards store sensitive information at the IP

CardSpace supports the handling of digital identities by remote IPs in the form of Managed Information Cards. They are referred to as Managed Cards because the information is managed for the user by a third-party. Unlike Personal Cards, where security tokens are created using claim values stored on the user’s machine, security tokens created when using Managed Cards are generated on a remote machine, where the claim values are stored. The token does not originate with the client’s computer, but from a service hosted by the IP, which runs an STS, as discussed in the section “WS-Trust” in Chapter 2. The STS produces security tokens for the user with data populated by the IP. This is the type of card that would be used in cases where there is a strong assurance required for the security of the data that is released in the security token.

Managed Cards are distributed in CRD ﬁles

How does a user get a Managed Card? Managed Cards are issued by an IP. They are delivered as a digitally signed XML ﬁle that contains the metadata that contains the details needed to use the card. This metadata contains information about the issuer, the claims the issuer supports, card details, the types of tokens the issuer supports, and the authentication type. Of course, this complexity is hidden from users. They receive the card as a ﬁle with a .crd extension, which has a card icon associated with it, as shown in Figure 3-10. When the user receives the card (with the .crd) extension, the user can import it into CardSpace by double-clicking the card

Figure 3-10 Managed Cards use the .crd ﬁle extension and have an associated card icon.

A Deeper Look at Information Cards

197

ﬁle. There is no programmatic method to import the card without the interaction of the user—this is designed with the ﬁrst law of identity, covered in Chapter 2, in mind (“User Control and Consent”)—so that users are always involved in every aspect of their digital identity. Authentication with an IP Managed Cards represent digital identities that are released as security tokens only after the user has successfully authenticated to the IP. To allow CardSpace to let the user authenticate, the IP must support one of the following four authentication schemes:

X.509 certiﬁcate. An IP can require that the client provide proof of a speciﬁc X.509 certiﬁcate. Through this, the IP enables the use of soft certiﬁcates, smartcards, or other devices that expose an X.509 certiﬁcate to the crypto API (CAPI) as a form of client identiﬁcation.

Kerberos. An IP can require the client to submit a Kerberos token to authenticate. This enables the use of a Managed Card when connected to a Windows domain.

Username and Password. The IP can also use a username and password for user authentication.

Personal Card. A Personal Card can be used for authentication to the STS. This Personal Card must have previously been submitted to the IP, so the card’s PPID and public key can be used to authenticate the user.

When a Managed Card is used, the user is prompted from the CardSpace UI to provide the credentials required for authentication (see Figure 3-11). The four credential types presented in the previous list are what CardSpace currently supports. In future releases, additional authentication types can be added, which is a deﬁnite CardSpace advantage. As new authentication technologies role out, the user experience stays mostly the same. Everything users have learned about using Information Cards will still apply.

An IP can choose which authentication method to use with their cards

198

Windows CardSpace

Why Do Managed Cards Use Username and Password Authentication? At ﬁrst glance, a (username and password)-backed Managed Card seems to defeat the purpose of a Managed Card. Wasn’t the whole point of CardSpace to do away with usernames and passwords? Not exactly, but it is an understandable misperception. Usernames and passwords represent a lot of the problems with online security. They encourage users to follow bad practices (such as reusing the same password), and they are simply a bare credential that doesn’t allow centralized IPs to provide trustworthy identities that can be used at various IPs. Using a (username and password)-backed card mitigates many of these problems. For starters, it’s just a single username and password that users need to remember to use their card. That card can then be securely reused at a number of RP sites, so the total number of passwords the user needs to keep track of can be signiﬁcantly reduced. Now one password can securely be used to log the user into many different sites. This helps reduce bad password practices and improves security by only having one party for which the user uses a username and password. However, it doesn’t make username and password suddenly more secure. There are still risks; they have just been reduced. If a malicious party tricks users into using their username and password at their site, it can reuse the credentials to authenticate to the Managed Card provider, which isn’t possible with the other credential types. So, although there is some reason to use username and password, the main reason is probably still to allow IPs a baby step while switching over from username and password authentication to using Information Cards.

The capability to support multiple authentication types, have multiple IPs, and use different token formats is how CardSpace satisﬁes the ﬁfth law of identity: “Pluralism of Operators and Technologies.”

A Deeper Look at Information Cards

Figure 3-11 The authentication dialog for a Managed Card that requires a username and password

Makeup of a Managed Card The Managed Card contains the information that CardSpace needs to contact the IP STS and request a security token. The elements that describe the card and the IP found in the card are the following:

Card ID. The card ID is used to index the card. Only one card with a particular card ID can be stored in the card store. An attempt to load in an additional card with the same card ID will notify the user that the card will replace the previously stored card.

Version. The card version is used by CardSpace to determine whether a card is newer or older than an existing card in the store. In any case, users are notiﬁed when

199

200

Windows CardSpace

they attempt to import a card with the same card ID, and they can decide from there what to do.

Card name. The card name is the label on the card when it is imported into the card store. The name of the card is the only thing that the user can modify.

Card image. The card is imprinted with a single image of the issuer’s choosing. The image can be of any size; a scaled version is copied into the card store at card import time. CardSpace scales the card image to ﬁt 120×80 pixels in the Identity Selector and will also scale the image dynamically to 90×60 pixels on other pages. An aspect ratio of 3:2 is always maintained.

Issuer. The issuer is a URI representing the issuer (IP) of the Managed Card. This is often identical to the URL of the STS, but is not required to be so. This is the same issuer that can be speciﬁed in the security policy from the RP.

Privacy policy. The privacy policy is a URL pointing to a text ﬁle that informs the user of the privacy policy of the IP.

Time issued. Time issued is a date/timestamp of the moment the card was issued.

Time expires. Time expires is a date/timestamp representing the card’s expiry. The issued and expiry values are purely cosmetic—CardSpace will display them, but no action is taken if the card is used outside of that date range.

The Managed Card also contains a list of STSs. Each token service is deﬁned by two elements. First, there is the endpoint reference, which consists of the following:

Address. The address is the URL of the STS from which to get the token.

A Deeper Look at Information Cards

MEX address. The MEX address is the URL with which to perform a metadata exchange with the STS. For security purposes, this address must be declared using SSL (using https://). Without the use of SSL, the client would not be able to perform any form of server authentication. Because the MEX information is instrumental in securing the next steps, a malicious endpoint would be able to communicate a false policy that could expose the user’s credentials when the user went to contact the false STS. Using SSL ensures that CardSpace can acquire a certiﬁcate to the endpoint.

Identity. Identity is the X.509 certiﬁcate used to provide the identity of the issuer to the user. Typically, this is the same certiﬁcate used to digitally sign the Managed Card.

Second, the token service contains information about the method used to authenticate to the STS in a user credential element, using one of the four supported authentication types supported by CardSpace for Managed Cards. The elements in the user credential are the following:

Display credential hint. A small message displayed to the user before authentication. This can range from “Please insert your smartcard now” to “Use your domain credentials” to “Hello World!”

X.509 V3 credential. An XML fragment describing the X.509 certiﬁcate required for authentication as a Base64encoded SHA1 thumbprint of the certiﬁcate.

Kerberos V5 credential. An empty element that indicates that the STS requires a Kerberos token for authentication.

Username password credential. An element that optionally contains a default username that is displayed when the STS requests a username and password authentication.

201

202

Windows CardSpace

Self-issued credential. An element that contains the PPID of a Personal Card that has previously been submitted to the IP. This allows the release of a Managed Card security token with the presentation of a Personal Card.

Along with the details of the STS, the card contains information about the types of security token that the STS will release and the claims that are supported:

Supported token type list. A collection of token types supported by the STS. For example, a SAML1.0 assertion would be urn:oasis:names:tc:SAML:1.0:assertion. Values for this are simply strings that the RP and the IP can agree on.

Supported claim type list. A collection of claims. Each claim listed contains a URI, a display tag, and a description. The URI is the identiﬁer that the RP speciﬁes in their security policy when asking for the claim.

Claims in Managed Cards Managed Cards declare the claims they support by providing the URIs, display tags, and descriptions for each of the claims. This enables a fairly unlimited capability for an IP to transport data to the RP. The IP has the capability to dictate what claims they support and in what token format they want to deliver them. IPs can support any claim type that they choose

Where are all the claim URIs deﬁned? There is no set library of claim URIs; there are the ones previously mentioned that are used for the Personal Card that can be used as a basis. Ultimately, it is up to the IP to decide which claim URIs they want to use. If they have a very close working relationship with the RP that will be requesting the claims, these two parties can come to an agreement as to which URIs will be used.

A Deeper Look at Information Cards

203

However, when claims are supported by multiple IPs and RPs, the process of determining what claims are, their URIs, and their formats are free to be negotiated between the parties involved or taken up by standards bodies. Uses of Managed Cards The very existence of Managed Cards opens new possibilities for electronic commerce. Suddenly, it is possible for the IP that we are comfortable with in the real world to have the facility to extend their use to the Internet. Some of the uses of cards that seem particularly ready to become Information Cards include the following:

Membership cards. Being able to prove membership to some club or group, at another site, that may be offering discounts based on membership, is difﬁcult to do. However, with Information Cards this becomes easy, and it has very practical applications.

Employee card. Cards issued by an employer can be used to access externally managed resources, such as beneﬁts sites, or can be used to set up trust relationships between companies. This makes it easy to share resources across companies.

Identity cards. Last but not least, cards can be used to identify who we are in consistent ways as a real identity or a persona. Uses for this type of card include veriﬁcation of age, gender, and marital status. All of these are generally easy to fake when somebody is online at present, but there is an ever-increasing need for these types of assurances.

In reality, the possibilities are endless; these are just a few hints at what Managed Cards can be used for. If you want other ideas, just take a look in your wallet.

Managed Cards are very ﬂexible and have many use cases

204

Windows CardSpace

Features of the CardSpace UI Before going into the details of how to accomplish common management tasks with Windows CardSpace, there are a couple of security-related UI features that are very noticeable when using CardSpace. These include the following:

Private desktop. This feature isolates the CardSpace UI from other applications.

Disable CardSpace option. The option to Disable Windows CardSpace appears on some pages in the UI. This helps prevent a malicious website from repeatedly bringing up the CardSpace UI.

Relying Party Identiﬁcation page. This is the ﬁrst page the user sees when going to an RP for the ﬁrst time, and it helps the user evaluate the identity of the RP.

Managed Card Import page. This page is similar to the RP identiﬁcation page, except that it shows the user the identity of the IP that created the Managed Card that the user is importing.

Each of these features is discussed in the following sections. Private Desktop

Every time CardSpace opens, all the applications already open on the user’s desktop fade and cannot be accessed while CardSpace is up. It appears that the applications have frozen. If you have the clock open on the taskbar, it will stay at the time when CardSpace appeared. Was there a rift in time? What you are actually seeing behind the CardSpace window is just a bitmap, a screenshot that was taken of the user’s desktop. The bitmap has been set in the background of a private desktop. Windows desktops provide isolation from code running on other desktops. The most commonly seen desktop switch is from the default desktop, where user applications run, to the winlogon desktop. This switch is triggered by pressing Ctrl+Alt+Del to lock your computer or enter your password. Figure 3-12 shows CardSpace open in the private desktop.

Features of the CardSpace UI

205

Figure 3-12 The applications in the background are shown as grayed out when CardSpace is open. The grayed-out applications are actually just a bitmap of the default user desktop.

Winlogon isolates itself from the default user desktop for the same reason as CardSpace: to make it more difﬁcult for malicious applications to steal sensitive information. Just like winlogon protects against software capturing your password, CardSpace makes it more difﬁcult for malicious software to perform screen-scraping or key-capture attacks.

For additional security, CardSpace opens on a separate desktop

Is the Private Desktop Impenetrable? Impenetrable is a very high bar. Although CardSpace raises the bar and makes many attacks much more difﬁcult, it cannot claim invincibility. The desktop is vulnerable to hardware-based attacks, where an external keylogger is attached between the keyboard and the computer so that it can intercept user key strokes. There is little a software-based solution can do in this case, unless your keyboard can do cryptography. In addition, CardSpace can provide little security against code executing with administrator privileges on the computer. However, regardless of the account that is being used, it is always a good security practice to restrict physical access to your computer to only trusted people. Also take the necessary precautions to prevent malicious code from being installed or run on your computer.

206

Windows CardSpace

The desktop provides the following:

Protection for users as they enter authentication information when using a Managed Card

A barrier to malicious applications that try to capture information about the cards that the users have because this information can be used at some later point to try and trick users into thinking they are in the CardSpace experience.

Despite the advantages of the private desktop, some of the CardSpace UI executes on the default desktop. Any time CardSpace opens a ﬁle dialog box, the user is switched back to the default desktop. A window opens behind the ﬁle box, displaying the bitmap of the faded desktop, to maintain a consistent experience. This keeps the ﬁle dialog box isolated from the main CardSpace UI because it has extensibility hooks that make it unsafe to open on the private desktop. These hooks could otherwise introduce a path for malicious code to execute on the private desktop. As an experiment, when CardSpace opens a ﬁle dialog, try pressing the Windows key. You’ll see the Start menu pop-up, a sure indicator that you are not on the private desktop. Disabling CardSpace In case of a badly behaved application, CardSpace can be disabled

Although the CardSpace private desktop raises the security bar, it does introduce a couple of concerns. One of those concerns is giving a website the capability to cause a desktop switch on the user’s computer. This can be a major pain if the site calls CardSpace in a loop, effectively rendering the user’s computer unusable. The Disable Windows CardSpace option is the escape hatch. This causes a different error code to be returned to Internet Explorer, which will redirect the user to a safe page. This page is a local resource ﬁle located at res://icardie.dll/ safe_page.html. If you have Internet Explorer 7 and type this in the address bar, you will see the safe page, which is also shown in Figure 3-13.

Features of the CardSpace UI

207

Figure 3-13 When CardSpace is disabled, Internet Explorer navigates the CardSpace safe page.

After the disable option is used, CardSpace will not be able to be called from that instance of Internet Explorer. Relying Party Identiﬁcation Page

How do you identify the RP that is requesting a card? During the ﬁrst visit to a RP, the user is shown a page that identiﬁes the site/RP. The information on the page is taken from the RP’s certiﬁcate; in the case of a website, it is take from the SSL certiﬁcate. This means it is required that a website uses SSL when using CardSpace. The common name (CN) from the subject ﬁeld of the site’s certiﬁcate is displayed on the page in the section “Site Information.” The CN of the certiﬁcate issuer appears in the section “Site Information Veriﬁed By” (see Figure 3-14). In the case where the site does not have an SSL certiﬁcate, and the .NET Framework 3.5 CardSpace client is being used, the URL of the site will be shown, as well as a warning that the information released will not be encrypted.

The RP Identiﬁcation page helps users evaluate the sites they are visiting

208

Windows CardSpace

Figure 3-14

The Relying Party Identiﬁcation page

This page also provides a link to view the privacy statement. This allows the RP to publish a privacy policy in plaintext that can be read from within the CardSpace UI. The link to the policy can be provided in the HTML of the tag or in the policy of a WCF application. Sites with EV certiﬁcates can display logos and location information

For some certiﬁcates, such as the one used at this site, part of the information is not displayed. The certiﬁcate from the site is not an EV certiﬁcate. Another beneﬁt of an EV certiﬁcate is that is allows logo URLs to be used to display logos on the CardSpace Relying Party Identiﬁcation page. Figure 3-15 shows a page with an EV certiﬁcate. Managed Card Import Page

The Import page allows the user to evaluate the IP that issued the card

The Managed Card Import page is very similar to the Relying Party Identiﬁcation page. It exhibits the same behavior when displaying certiﬁcates and EV certiﬁcates. The difference is that instead of identifying an RP, it is used to identify the IP that issued the card. When the IP provides a Managed Card with a .crd extension, it needs to digitally sign the ﬁle with a certiﬁcate.

Features of the CardSpace UI

Figure 3-15

209

The Relying Party Identiﬁcation page with an EV certiﬁcate

The certiﬁcate that is used to do the signing is displayed in the Managed Card Import page. It is important that users be able to identify who has provided the card because once the card is imported, users will use it to authenticate to their IP. As shown in Figure 3-16, the Import page also shows what the card that will be installed looks like.

What Is an EV Certiﬁcate? To acquire an Extended Validation certiﬁcate, a site needs to go through extra steps while registering for the certiﬁcate. These steps include proving that they are a real business and that the information on the certiﬁcate, such as the location of the business, is in fact correct. Internet Explorer 7 turns the address bar green to help users identify EV certiﬁcates. Once users start looking for EV certiﬁcates, it will be harder for major sites to be phished. There is some criticism of the program because in might be difﬁcult or impossible for some smaller sites to get EV certiﬁcates, and therefore they might unfairly appear to be less safe than larger businesses.

210

Windows CardSpace

Figure 3-16

The Managed Card Import page shows the IP information.

Common CardSpace Management Tasks CardSpace acts as a central location for the digital identities. This means that along with using the identities at a variety of RPs, a host of management tasks are necessary. Some of the main tasks are as follows:

CardSpace in Management mode. All management tasks can be done whenever CardSpace is open, but this also makes it possible to perform card management tasks while not interacting with an RP.

Creating and editing Personal Cards. Creating and managing self-issued identities.

Moving cards between computers. It is common to use different computers throughout the day to accommodate the cards needed to be able to roam.

PIN protect a card. Some cards may require additional security to make sure they are not used by the wrong person. A PIN can be set to provide this extra protection.

Common CardSpace Management Tasks

Management Mode

So far, the only way that has been shown to open CardSpace is by going to an RP and using a card. Sometimes a user might want to open CardSpace to manage her cards. For this very purpose, CardSpace installs a Control Panel applet. It can be a little hard to ﬁnd when the Control Panel is in Classic view. First, click User Accounts, and then the Windows CardSpace applet appears. Clicking the applet, which is shown in Figure 3-17, will open CardSpace. If you are looking to open CardSpace directly from code, there are the following options:

Managed code. Reference the System.IdentityModel. Selectors.dll assembly and call the static method Manage() off of the CardSpaceSelector object.

Native code. Include infocardapi.dll and call Manage().

Both of these calls will open CardSpace in the same way as clicking the Control Panel applet.

Figure 3-17 The Windows CardSpace Control Panel applet opens CardSpace, to enable card management tasks.

211

For managing cards, CardSpace can be opened from the Control Panel

212

Windows CardSpace

Creating and Editing a Personal Card

One of the ﬁrst experiences users are likely to have with CardSpace is creating a Personal Card. From the Card Chooser page, there is an Add a Card card. Either double-click the card or click the card and click the Add button (see Figure 3-18). CardSpace navigates to the Add a Card page, shown in Figure 319, which displays the options for adding a card: Create a Personal Card or Install a Managed Card. Choose to create a Personal Card. The next page is for editing the new Personal Card (see Figure 320). The values that can be edited are broken into two main categories:

Card properties. The name and image shown on the card can be changed. These properties are used to draw the cards and help the user recognize and customize their cards. They are never sent to the RP.

Figure 3-18

Add a card starts the card-creation process.

Common CardSpace Management Tasks

Figure 3-19

The Add a Card page

Figure 3-20

The Edit Card page

213

214

Windows CardSpace

Information that you can send with this card. Here’s where the user can specify the values for the claims that the card supports. Only the claims an RP requests are sent, not the entire set of information that the user ﬁlls out.

Once done editing the card, click the Save button, and the card appears in your collection (see Figure 3-21). Any time users want to change the claim values or properties on the card, they can double-click it (or select Preview), then click Edit, and they will be back on the Edit page where further modiﬁcations can be made. Moving Cards Between Computers Cards can be moved between machines in an encrypted ﬁle

Most people work from several different computers; it’s common to use one at home and one at work, so Information Cards need to move, too. CardSpace v1 enables this by allowing

Figure 3-21

The newly created card is added to the collection.

Common CardSpace Management Tasks

backing up of cards to a ﬁle that can roam with the user. The ﬁle is encrypted using a password of the user’s choosing and is then saved to a ﬁle with a .crds extension. The .crds ﬁle icon is shown in Figure 3-22. This ﬁle can be moved between different computers by any usual means of transferring a ﬁle, such as a USB memory stick. The link to backed-up cards is on the main Card Chooser page. Click the Backup Cards link on the task pane, shown in Figure 3-23. The next page shown enables the selection of which cards should be backed up to the roaming ﬁle (see Figure 3-24). By default, all the cards are selected, but any subset of cards can be selected by checking or unchecking a card.

Figure 3-22 computers.

A CardSpace backup ﬁle can be moved between

Figure 3-23 Cards can be backed up from the task pane in the Card Chooser page.

215

216

Windows CardSpace

Figure 3-24

Individual cards can be included while backing up cards.

Then on the next page the back up ﬁle can be named (see Figure 3-25).

Figure 3-25 The Name the Backup File page lets the user pick the ﬁle to back up to.

Common CardSpace Management Tasks

As a last step, the password is provided that will be used to protect the ﬁle (see Figure 3-26). CardSpace requires a minimum of an eight-character password. The ﬁle is then saved and CardSpace returns to the Card Chooser page. The ﬁle can then be roamed to the desired machine. When it is on the new machine, double-clicking the backup ﬁle will bring up CardSpace and prompt for the password to decrypt the ﬁle. The cards that are about to be restored are shown for review, and when the user gives the okay by clicking Restore, they get copied over to the local collection and are ready to be used. Only cards with last modiﬁed times older than the ones being installed are overwritten. The card-restore capability of CardSpace is somewhat limited in this regard because there is no option to pick which cards will be restored and no indication of which cards will be overwritten.

Figure 3-26

A password is used to encrypt the backup ﬁle.

217

218

Windows CardSpace

Another interesting part of the backup and restore behavior is that card history is not backed up. This means that after roaming a card to a new computer, returning to a previously visited site will trigger the ﬁrst-time use experience and show the RP Identiﬁcation page.

User Experience Changes in .NET Framework 3.5 In the .NET Framework 3.5 release, there have been a few minor changes in the user experience based on usability feedback. The changes focus on three main areas:

Simplify use of Personal Cards

Simplify import of Managed Cards

Give the Managed Card provider more ways to communicate information to the user

Is It Safe to Roam Cards to an Untrusted Computer? Moving cards around is simple, but is it okay to put them on the computer at the library or an Internet cafe? Such computers are untrusted because you don’t know what malicious code might be running on them. Because the ﬁle is decrypted by code running on the computer, and the secret cryptographic information is copied to the computer’s local STS, malicious code might be able to steal cryptographic key material for Personal Cards. In addition, it would be easy to forget to delete your cards from the computer, so the next person who comes along can access your cards. However, the future looks bright for card roaming. Microsoft has publicly stated that it is looking at improving the roaming story, which could include putting STSs on mobile devices and making Information Cards anywhere much easier and much safer to use. This would allow roamed cards to be used on any computer, without releasing any secret key material and provide a secure and portable means of authentication.

User Experience Changes in .NET Framework 3.5

219

Simpliﬁed Use of Personal Cards

When users ﬁrst encounter a site that uses Information Cards, it is important that they have a smooth experience. If they become confused or frustrated, a lasting negative impression can be formed about Information Cards. With this in mind, a few of the bumps that existed in the ﬁrst-time user experience were addressed in CardSpace’s .NET Framework 3.5 release.

The number of clicks to create and use a card has been reduced

One signiﬁcant change was to take users directly to the cardcreation page, if they did not previously have a Personal Card. This got them pointed in the right direction and reduced the number of decisions they needed to make. Otherwise, they were just dropped into CardSpace, left to ﬁgure out what task they should be doing. Another improvement was to only show the user the input ﬁelds for the claims that were being requested. Previously, when all 14 supported claims were shown, users would think it meant the site they were visiting wanted all the information. They would then take a long time ﬁlling it all out or cancel out of CardSpace because they did not want to release so much personal information. Additionally, users can send the card directly from the page they initially type the claim information into. Previously, CardSpace made the user go back to the card selection page and then review the claim information before sending. This makes the experience much more seamless. Overall, the changes are minor but when put together have a signiﬁcant impact on user’s ﬁrst-time experience with CardSpace.

The user is more clearly shown which claims are being requested

220

Windows CardSpace

Simplify Import of Managed Cards CardSpace exits after the card is imported

There was a bottomless pit in the CardSpace experience. When importing a Managed Card, the user is taken to the Card Chooser page. The user could then go to the Details page of the card they imported, exit that page, go back to the Chooser page, and then repeat the entire process. The problem was there wasn’t a clear end to the import task. CardSpace in .NET 3.5 ﬁxes this by changing the Install button to Install and Exit. After the card has been imported, CardSpace will automatically close. Better Communication to the User

There were two main improvements in this area. The ﬁrst provides a card provider a way to provide the user with contact information, similar to the phone number and address information you probably have on the back of many of the cards in your wallet. The IP can add additional information to their cards

This information can be included in an ‘issuerInformation’ element in the Managed Card ﬁle and can contain up to 20 name-value pairs, which are shown on the Card Details page so that the user has easy access to them when looking at the cards. And although any URLs that are included (such as a link to a help page) will not directly open a browser window, they can be cut and pasted from the CardSpace desktop to a browser windows on the user’s primary desktop. A window cannot be opened directly, for security reasons, so the CardSpace desktop is isolated from the browser process.

Custom fault messages are displayed in the CardSpace UI

Another way for the card provider to communicate to the user is when an error occurs in using the card. In the ﬁrst release of CardSpace, a fairly generic message was displayed. With CardSpace in .NET 3.5, however, the IP’s STS can send a custom message back in a SOAP fault. The message can be anything the IP deems as useful, ranging from “Bad username or password” to “Your club membership has been discontinued,” depending on the type of card.

Summary

Summary Windows CardSpace is a client-side application that enables the simple management and use of digital identities. CardSpace can be used by websites to provide secure authentication, as well as by rich client applications that take advantage of web services. Information Cards are the cards that are displayed in CardSpace and represent the user’s digital identity. An Information Card contains the information needed to use a digital identity. This is done by retrieving a security token from an STS. The Information Card does not contain claim information; it is maintained at the STS. The CardSpace UI makes it easy for the average user to perform several common tasks. This includes creating Personal Cards, installing Managed Cards, and roaming cards between computers.

221

This page intentionally left blank

4

CardSpace Implementation CardSpace supports a large number of deployment scenarios. It can be used in simple logon scenarios, using Personal Cards. It also supports Managed Cards, allowing a website to trust a third-party IP. There are also more advanced federation deployments that require multiple security token services for a single CardSpace interaction. Then to add another dimension, this can all be done by websites, Web service applications, and native and managed client applications. Yet, despite the diversity of deployment options, CardSpace is able to let the average user interact with their digital identities in a consistent way. CardSpace also provides a consistent experience for the developer, a standardized digital identity model with which to work. Despite the many implementation scenarios, the developer can simply think about the digital identity and what is needed to use it in a uniform way.

223

224

CardSpace Implementation

Using CardSpace in the Browser CardSpace works with many different types of applications

Practically all organizations have a website offering a broad range of services and resources. There are other ways to provide these services, such as using Web services and rich client applications, but for the time being websites dominate. Because many of these sites require some level of user authentication, it’s not surprising that most of the interest in CardSpace is being generated by individuals or businesses that want to use Information Cards on their website. It’s also not surprising CardSpace deployments are designed to help facilitate website adoptions. A website will require some changes to its logon pages, but the majority of the site can remain unchanged. Here’s a summary of the logon process, with Information Cards: 1. The Information Card extension in the Web page is

invoked by the user. 2. The user selects a card. 3. CardSpace returns the token that the card represents to

the site, which posts it to a login page, where it is processed. 4. If the user is authenticated, the site can use standard

infrastructure for “logging on the user.” This probably involves setting a cookie or some other session state. Speciﬁcally, the site needs to add an Information Card control, post the returned token to an authentication page, and have some code for authenticating the token. Understanding the Information Card Browser Extension

The Information Card browser extension is the door between worlds. It allows the HTML of a Web page to open CardSpace and request a token. This allows the user to select a card, and then CardSpace makes the necessary Web service calls to

Using CardSpace in the Browser

225

acquire the token and satisfy the request. The token is then returned back to the Web page. The Information Card extension that comes in Internet Explorer 7 supports two different syntaxes for calling into CardSpace: an HTML and an XHTML object tag. The HTML syntax is used by an ActiveX object, and the XHTML tag is used by a binary behavior object. Another option is to use the extension developed by Perpetual Motion (http://perpetual-motion.com/) that works with Firefox and supports both syntaxes, too. Future extensions will be expected to support these syntaxes, so Web developers will not have to treat how Information Cards are requested based on the browser the user is running as a special case.

A site developer can use an HTML or XHTML tag to request an Information Card

What’s the Difference Between the Syntaxes? Neither syntax provides a clear advantage over the other. The HTML tag is more commonly adopted by existing sites, but this might just be due to the fact that most of the ﬁrst published examples used the HTML object tag, and it is a familiar syntax for most Web developers. Given this, there is not a signiﬁcant reason for people to explore other options. An advantage of the XHTML tag in Internet Explorer is that it is implemented using a binary behavior object, whereas the HTML object tag uses an ActiveX object. This allows the XHTML tag to still work even if ActiveX objects are disabled, which may occur when high security settings are applied. In most cases, this probably isn’t a big win, because in the default conﬁguration ActiveX objects are enabled, but it’s good to know just in case that security setting on the client is a concern. It is easy to change the syntax a site uses, because both are expressed in a small amount of HTML, and switching between them does not have broader impact on the site.

226

CardSpace Implementation

The following listings are examples of the HTML and XHTML syntaxes. Both of these examples have the same meaning, and result in the same behavior. To help keep the lines manageable, the URIs used have been abbreviated. The … in each URI is shorthand for "schemas.xmlsoap.org/ws/2005/05/identity", so "http://.../issuer/self" actually represents "http://schemas.xmlsoap.org/ws/2005/05/identity/ issuer/self".

The HTML extension, which calls the ActiveX object in Internet Explorer, looks like this: " />

Using CardSpace in the Browser

The XHTML extension, which calls the binary behavior object in Internet Explorer, is shown in this listing:

Both of these examples have the same meaning. They both make a call to CardSpace, requesting a Personal Card, requiring the email address and given name claims, and asking for an optional Web page claim. Immediately apparent in both examples is that the objects work within a standard Web form. Forms are commonly used in websites to collect information from a user for processing. Consider the following line:

227

228

CardSpace Implementation

The token can be posted as part of a standard form

The attributes set on the form element specify where the token will be processed. The method attribute is set to post, which means when the Submit button in the form is clicked, the values of the elements in the form will be posted back to the Web server for processing. The action attribute speciﬁes the page to which the data will be sent. In this case, it is sent to TokenProcessingPage.aspx. For another example of a page that uses a form post, see the section “HTTP and HTTPS: The King Is Naked” from Chapter 1. It shows how a form post works when a username and a password are used. When the form is posted, the elements inside the form are posted as name value pairs. In the post, the name that is used to identify the token is the name set on the Information Card browser extension. In the preceding examples, it is 'CardSpaceToken'. Details about how the posted data is processed by the website are covered later in this chapter. How Are the Extension Properties Used?

The site can express the requirements for the requested token

Let’s take a further look at the properties on an Information Card extension object. These properties are used by the website to describe the type of information the site requires in the token it gets from CardSpace. This includes being able to request who issues the token (who the signing authority is for the token), which claims should be included in the token, and what the format of the token should be. Issuer The issuer property on the extension is used to specify who the website wants the token to be issued by. This could be a selfissued token, or some other issuer. CardSpace will enable any cards that are backed by the requested issuer. If a site wants the user to use a Personal Card, the issuer should be set to the selfissued URI, "http://schemas.xmlsoap.org/ws/2005/05/ identity/issuer/self". If the site wants a Managed Card to be used, issuer should be set to the issuer of that card.

Using CardSpace in the Browser

CardSpace determines the URI of an issuer by the value of the issuer element in the Managed Card ﬁle (see the section “Makeup of a Managed Card” in Chapter 3, “Windows CardSpace”). This can be any valid URI the Managed Card provider has chosen to represent themselves with, such as "http://issuer/departmentoﬂicensing". CardSpace uses the issuer that the website has speciﬁed to highlight a card that can be used for the current operation. This means if the self-issued URI is speciﬁed, only Personal Cards can be used; all Managed Cards will appear grayed out, and the Send button will appear disabled. Similarly, if a Managed Card’s URI is used, only cards from that issuer can be used. Issuer is an optional property on the browser extension object. If it is omitted, this is interpreted by CardSpace to mean any issuer can be used, so all cards that can satisfy the requested claims and token type will be enabled. In all cases, when the token is returned to the site, the site should make sure that it is actually signed by a trusted issuer. The fact that a speciﬁc issuer is speciﬁed in the browser extension does not guarantee that a token from that issuer is being returned to the website. That CardSpace only enables cards that match the speciﬁed issuer is a usability feature and should not be treated as a security feature. IssuerPolicy This property is used solely for federation scenarios, and in most cases is not speciﬁed. It indicates the MetadataExchange (MEX) endpoint of an STS. For now, we will skip over this case and revisit it in more detail later in this chapter, in the section “Federation with CardSpace.” RequiredClaims This property is used to specify a list of claim types that the website is requiring. This allows the site to request an email address or any other information they are interested in. CardSpace will

229

230

CardSpace Implementation

include this list of claims in the RST to the card provider when requesting the token. The card provider should then only return the information being requested (minimal disclosure). CardSpace also uses this claims list to match cards, disabling any cards that do not support the claims being requested. Just as with issuer matching, this helps the user select a card that can be used to satisfy the current request. There must be at least one required claim speciﬁed in the extension. (This is the only property that requires a value.) If the site does not have a reason to request a claim-speciﬁc claim, just asking for the private personal identiﬁer is probably a good choice. This won’t needlessly disclose any of the user’s personal information or cause the user to have to stop what he is doing (such as logging in to your site) and ﬁll out any information on the card. The required claims appear as a whitespace separated list when being set in an HTML tag. In an XHTML tag, each claim appears as a separate element, with an attribute marking it as required or optional. OptionalClaims Optional claims represent information that the site might like to know about the user, but isn’t requiring. The site may choose to use optional claims if it is requesting information that may not apply to all users. A common example would be when a site does not require some information, such as a blog URL. The blog URL may provide more proﬁle information about a user, but is not required, because not everybody has a blog. TokenType Token type lets the website specify the token type they will accept. CardSpace Personal Cards support SAML 1.0 and SAML 1.1 tokens. In this case, a token type of 'urn:oasis:names:tc: SAML:1.0:assertion' should be speciﬁed. For Managed Cards,

Using CardSpace in the Browser

any format that the card provider would like can be used: SAML or a token format that the provider invents. What is important is that the website and the IP both understand the format. CardSpace will not inspect whether the token conforms to a speciﬁc format For instance, we could deﬁne our own token format and assign it a URI. Let’s say the following line of XML represents a token with our formatting: Thomas

Let’s also say the URI speciﬁed by the RP website is "http://myTokenType". This would work perfectly well with CardSpace. This really illustrates the ﬂexibility of CardSpace. The token types that a card provider supports are included in the Managed Card ﬁle, in SupportedTokenTypeList. CardSpace will disable any cards that do not support the requested token type. If no token type is deﬁned on the extension, any token type will be accepted. PrivacyUrl The site can specify a link to a privacy policy, which will be displayed in CardSpace. The privacy policy view in CardSpace only supports text, so the URL should point to a plain text resource. The privacy policy is available to the user from the relying party identiﬁcation page, which is the ﬁrst page a user will see when visiting a site for the ﬁrst time. PrivacyVersion A privacy version must be supplied if the privacy URL is set. This indicates the version of the privacy policy. If the policy gets updated at some point, the version should be increased. When the version changes, CardSpace will notify the user of the change by retriggering the relying party identiﬁcation page and providing an information bar stating that there has been a version change.

231

232

CardSpace Implementation

Scripting CardSpace CardSpace can be called directly from a script

In addition to being used in a static HTML tag, CardSpace can be invoked from a script running in the Web page. Calling CardSpace from a script enables the website’s requirements to be set dynamically. Scripts also support richer error handling and make it easier to detect client-side support for Information Cards. In this section, we cover how to call CardSpace with a script, including error handling. Chapter 5, “Guidance for a Relying Party,” goes into deployment details, such as detecting client-side support. The following example requests the same token as the previous HTML and XHTML examples. The big difference is the Submit button and Information Card object are not in the form. When the button is clicked, the script dynamically sets the requested issuer and claims types on the object. The object is then invoked by calling the Value property. When this property is called, CardSpace opens. The script then sets the properties return value, which is the resulting token, on the hidden input element in the form, which is posted to the processing page.

Why Dynamically Set Site Requirements? It might seem odd at ﬁrst that there would be cases where setting the site requirements would be useful. Shouldn’t the site know what kind of card it wants ahead of time? This is true if the site accepts cards from a single issuer, but becomes harder in some multi-issuer cases. If the site allows employees from company A and company B to log on to their site, it is possible that users will ﬁrst be asked to select which company they are coming from on the website. This lets the site update its policy, dynamically, to match cards from that company. Another way to solve this problem is if company A and company B have a unique claim type, such as http://claim/type/friendsOfCompanyC, this claim could be requested, and issuer left blank. That way both company A and company B cards would match the requested policy, whereas other cards wouldn’t. Of course, that requires cooperation between all the companies involved, which might be impractical.

Using CardSpace in the Browser function SubmitCard(card) { card.issuer = ‘http://.../issuer/self’; card.requiredClaims.Add( ‘http://.../emailaddress’); card.requiredClaims.Add( ‘http://.../givenname’); card.optionalClaims.Add( ‘http://.../webpage’); var token = document.getElementById( "CardSpaceToken");

try { token.value = card.value; } catch (e) { Alert("error:" + e.number); } cardForm.submit(); }

Error Handling As with all software, sometimes errors occur when using CardSpace, and the websites should be written to handle them appropriately.

233

234

CardSpace Implementation

When an error is returned from CardSpace and a script is not used, very little error information is returned. The only indication that an error occurred is that the site gets an empty or null value, rather than a token. Any information about the type of error is lost. If the token is null, the site has to hope that the user was given a relevant error message by the CardSpace application or that the user simply cancelled out of CardSpace instead of choosing a card to submit. This approach correctly handles the majority of errors that a user is likely to hit after a site has been deployed. When calling CardSpace from a script it is possible to get error codes

However, during the development process, it can be useful to get richer error information. Retrieving this error information requires some scripting. This can be done by catching exceptions thrown by the call. In the preceding example, this was done with the following try/catch block. If an error occurs, an exception is thrown, and a message box will pop up with the corresponding error number. try { token.value = card.value; } catch (e) { Alert("error:" + e.number); }

Of course, this method of error handling is just an example, but it demonstrates how the error code can be retrieved. There are several possible error conditions

In addition to CardSpace displaying some error messages, and in other cases returning error codes, Internet Explorer will sometimes redirect to an embedded resource page. These are the three main error-handling strategies used by CardSpace.

Using CardSpace in the Browser

Here are the most common errors that can occur, and how they are handled:

User Cancelled. This is probably the most common error; it happens when a user cancels out of CardSpace instead of choosing a card. There could be several reasons why a user might do this. For example, they change their mind and decide not to send a card, or they don’t have the type of card that is being requested. In this case, there is little the site needs to do; the user should be aware that he chose not to send a card, and should not be surprised that he was not logged in to the site.

Not Installed. If the CardSpace extension is installed, but .NET 3.0 is not, the core CardSpace components will not be available. If the extension is called in this case, Internet Explorer will redirect to a “not installed” page, which contains a link for installing .NET 3.0. This is a reasonable safety net; however, it is probably better for a site to check up front if the machine is CardSpace enabled.

Service Failure. A service exception can occur if the CardSpace service failed to start. This could be caused by the service being disabled. In this case, CardSpace will redirect the user to a “browser resource” page, which will give a standard error message.

Identity Validation Error. This can occur if the certiﬁcate on the website does not pass the check that CardSpace uses to verify certiﬁcates. The certiﬁcate must chain to a trusted certiﬁcate authority or be in the trusted people’s store.

Service Busy. CardSpace can only have one instance open per user at a time. This restriction is enforced because of CardSpace’s private desktop. If CardSpace is open, and the site tries to make a call into CardSpace, this error will be returned. This should be a fairly rare

235

236

CardSpace Implementation

case, unless a site tries to use CardSpace without requiring user interaction.

Access Denied. CardSpace will return an access denied error if the Information Card tag is in an embedded frame from a domain other than the domain of the parent page. This prevents a malicious site from embedding another website’s logon control into its own page. The version of CardSpace that shipped with .NET 3.0 also requires that a site be HTTPS. If the site is HTTP, an “access denied” error is returned. This type of error can easily be avoided by blocking HTTP access to the logon page or by redirecting to an HTTPS page. The .NET 3.5 version of CardSpace can support an HTTP page; so, catching the “access denied” error can be a useful way to tell people they need to upgrade.

Untrusted Recipient. This error will be returned if the user clicks the Disable Windows CardSpace link from within CardSpace. In addition to throwing an exception, Internet Explorer will redirect to a page that explains the cause of the failure.

Trust Exchange. This error can occur in federated scenarios if an STS returns an error. Because it will only occur in federated scenarios, most deployments won’t need to take it into account.

Argument Error. When an invalid value is passed, such as a negative value for PolicyVersion, this will hopefully only be seen by a developer, who is writing HTML to call into CardSpace. In such a case, the event logs on the CardSpace machine should be checked for more detail.

Policy Error. This is also hit when there is an error in the HTML used to call CardSpace. Instead of a bad value, it is more likely to occur if the website supplied requirements fail to meet basic CardSpace requirements. The most common case is if no required claims are requested.

Using CardSpace in the Browser

237

Using the Event Viewer If you plan to do any development work with CardSpace, it’s good to be familiar with Windows Event Viewer (see Figure 4-1). Many errors that CardSpace encounters are only logged in the Event Viewer. For others, even if an error message is shown in CardSpace, the Event Viewer has more detailed information in the log ﬁles. The Event Viewer can be opened by going to Control Panel, Administrator Tools, and clicking the Event Viewer shortcut. Or, it can be accessed by entering eventvwr in the Run box.

Unsupported Error. This error occurs when a request is made for a self-issued token that cannot be satisﬁed. For instance, if a self-issued token were requested, with a claim that is not supported on the Personal Card, such as a Social Security Number, it would trigger this error.

Out of all these cases, only the ﬁrst two are very likely to occur. The ﬁrst can be ignored, and the second can be detected before making the call.

Figure 4-1

The Event Viewer showing some CardSpace errors

238

CardSpace Implementation

CardSpace events appear in the Application logs, which can be navigated to by the tree view on the left. The CardSpace logs will have a source of CardSpace 3.0.0.0 for the .NET 3.0 version of CardSpace. Processing the Token

Processing the token returned by CardSpace would typically be done by a token-processing library; there are several available, and surely more to come. The details of this section are useful in understanding how tokens are processed, but it is not a guide to implementation. In most cases, it makes more sense to use a pre-existing library. Several steps are required to process a token

Now that the website can request a token from CardSpace, the token is then posted to a token-processing page. There are four main parts to processing the token:

Token decryption. In many cases, the token will be encrypted for the website, so it must be decrypted.

Token integrity check. The signature on the token must be validated to ensure that the token has not been tampered with, and that it comes from a trusted party.

Token validation. Check that the token is valid and that it has not expired or was meant for a different site.

Retrieval of claim value. Parse the claim values out of the token and use them to authenticate the user or make an access decision.

Token Decryption In most cases, the token returned by CardSpace will be encrypted in an EncryptedData element. This would typically be encrypted to the public key of the website’s certiﬁcate. The encrypted token would look similar to the XML element shown in Figure 4-2.

Using CardSpace in the Browser

Figure 4-2

An EncryptedData element

For the website to get to the token content, it must ﬁrst perform the decryption. To do this, it needs the private key of the HTTPS certiﬁcate, as illustrated in Figure 4-3. Encrypted Token …

+

Private Key For HTTPS Certificate

Decrypted Token …

Figure 4-3

The website must decrypt the token to get the content

239

240

CardSpace Implementation

To decrypt the token, the site must have access to the SSL private key

Although it is easy to state that the key must be used, actually getting access to the key is a bit more complicated. In standard deployments, the HTTPS certiﬁcate is isolated from the code that runs on a server’s Web page. Even though the code is executed on the server, if a ﬂaw were found in the code, a remote user could exploit it to access the certiﬁcate’s private key. It is safer to set up security such that the process running the site cannot access the private certiﬁcate keys. One common solution is to grant minimal access to the key so that it can be used by calling a decryption API. Another solution is to use a tokendecryption process running on the Web server. (You can ﬁnd an example at www.leastprivilege.com.) This can separate the decryption of the token and access to the sites certiﬁcate from the code running in the Web page. Figure 4-4 provides an example of a decrypted SAML token.

Figure 4-4

An example of a decrypted SAML token

Using CardSpace in the Browser

Token Integrity It is of extreme importance that a website can verify that a token came from a speciﬁc IP. The trust that a website can have about the information in a token hinges on the capability to verify that the token comes from a trusted party and has not been modiﬁed. This is accomplished by verifying the signature on the token. This provides a cryptographically secure integrity check, which ensures that the token contains the data as intended by the signing party. Also, because the signing is done with a private key, the website can use the public key to identify the signer. Solutions for managing the keys are left for Chapter 6, “Identity Consumers,” but simply put, as long as the website can use the public key to identify a party, it can be sure which party generated the token. Token Validation Token validation can take many forms, and the form depends on the type of token. Because SAML tokens are commonly generated by CardSpace, they are used to illustrate some of the validation that can be done.

SAML assertions contain conditions that should be veriﬁed. These include NotBefore and NotOnOrAfter attributes:

These attributes specify the time span for which the token is valid, encoded in UTC. A token processor should verify these values to make sure the token has not expired. In some cases, a website may want to allow for a time skew. This can be useful because computer clocks are not perfectly in sync, which could erroneously cause a token to fail validation. Depending on the environment, allowing for a time skew between ﬁve to ten minutes is probably reasonable. Another condition that can be added to a SAML assertion is an audience restriction condition using AudienceRestrictionCondition (see Figure 4-5). This can be used to specify the relying party for which the token was gen-

241

The integrity of the token needs to be veriﬁed to be sure it is from the correct issuer

Several checks need to be made to establish the validity of the token

242

CardSpace Implementation

Figure 4-5 assertion

An audience restriction condition added to a SAML

erated. If an audience restriction condition is present in the token, the website should verify that it was the intended recipient. This is just a matter of verifying that the URL in AudienceRestrictionCondition matches the URL of the website. Although this is simple, it is important because it can help the site protect itself against reply attacks. The attack would work by one site requesting a token from a user, and then trying to impersonate that user by replying the token to a different site. However, because the token speciﬁes the URL of the site the token was meant for, the second site would be able to reject the token. Retrieval of Claim Values After the token has been veriﬁed, the claim values can be retrieved. The ﬁrst step is to verify that all required claims have been provided. The next step is to use the claims to perform whatever task is at hand. In many cases, this will be logging on the user and might involve looking up some sort of user identiﬁer. In other cases, it could be retrieving an age or some other value required to make a decision about the subject. It is good to keep in mind that even though the values are packaged in a token, they are still user-provided values, particularly in the case of a Personal Card, and as such it should be treated as any other user input. This means it should not be trusted, and precautions should be taken against SQL injection and cross-site scripting attacks. The claims sent in the token can be used to transmit any required information

The claims values returned can be used in many different ways; this is both the beauty and the power of the claims-based model. When a site knows some strongly asserted information about a subject, it can devise its own rules for how to process

Using CardSpace in the Browser

Figure 4-6

Claims returned in the token

this information. Figure 4-6 shows how the claims emailaddress, givenname, and webpage returned in the token. Accepting Personal Cards at a Website

To help make the process of accepting a card more concrete, we elaborate on the simple case of accepting a Personal Card for logging in to a site. The site logon page would contain a form that speciﬁes the self-issued URI for the issue, as the claims that it would like. In this case, the site will simply request the Private Personal Identiﬁer (PPID) claim:

243

244

CardSpace Implementation

The user can either create and submit a new Personal Card or reuse a Card that was previously created. As noted in Chapter 3, it is perfectly ﬁne for a user to reuse a card across sites because the Personal Card creates a new PPID and signing key pair for each site visited. The signing key is used to prove possession of a Personal Card

When the token is returned from CardSpace, it is posted to the token-processing page and decrypted. Because the token is generated by CardSpace’s self-issued token provider, it is signed using an RSA key. This key is generated by CardSpace when a Personal Card is used at a site; so if the user hasn’t registered the card at the site before, there is no way for the site to recognize it. However, it can still verify the integrity of the token by ensuring that the signature is valid. The token veriﬁcation checks described in the previous section apply because CardSpace generates SAML tokens for the selfissued card. The PPID claim can then be retrieved from the token. In combination, the RSA signing key and PPID value can be used to identify the subject and authenticate the user. The RSA signing key is required because it provides the cryptographic proof of identity, and PPID can be a useful lookup key for ﬁnding the user’s account in a database. You can ﬁnd more information about how to deploy this in Chapter 5. Accepting Managed Cards at a Website

To request a Managed Card the card issuer should be speciﬁed

In principal, the process for accepting a Managed Card is very similar to accepting a Personal Card. We will take a look at the implementation details for the canonical case of age veriﬁcation. In this example, the issuer will be the ﬁctitious Managed Card provider Department of Licensing, whose issuer URI is http://issuer/departmentoﬂicensing. The wine seller site trusts them to perform age veriﬁcation and requests an age veriﬁcation claim. The Managed Card provider has developed the claim

Using CardSpace in the Browser "http://id4less/claims/legalToDrink" for this very pur-

pose. The wine shop then hosts the following HTML in their login page:

When CardSpace comes up, the user is directed to select the correct Managed Card, because other cards are disabled. When they select the card, the user authenticates to the Managed Card provider’s token service, as discussed in Chapter 3, and the token is sent to the website. After decrypting the token, the site veriﬁes the identity of the signer of the token. Because the token was created by a Managed Card provider, it would normally be signed using the certiﬁcate of the card provider. As long as the website has previously obtained a copy of the public certiﬁcate, it can use it to verify that the token was signed by Identities 4 Less.

245

246

CardSpace Implementation

After validating the tokens expiration time and audience restriction attributes, the value of the "http://id4less/claims/ legalToDrink" claim can be pulled from the token and checked to see whether it is true or false and either block or allow the purchase accordingly. Auditing and Nonauditing IPs

An interesting aspect of an IP’s implementation is whether it chooses to be told which sites it is issuing a token for. This decision has both privacy and security implications. Auditing IPs can track the sites a user visits

An auditing IP wants to know the sites their cards are used at, whereas a nonauditing provider issues tokens without knowing the intended recipient. When using a card at a website, the capability of an IP to audit a card is dictated by the presence of RequiresAppliesTo in the Managed Card ﬁles it issues to users. If this element is present, CardSpace will send the identity of the site to the IP. If the element is absent, the IP has chosen to be nonauditing, and the website identity will not be sent.

Nonauditing IPs do not know which site a user visits

In the nonauditing case, the IP must be willing to disclose information to any website that the user has decided to trust. In addition, without knowing which site a token is being released for, it is not possible for the IP to set AudienceRestrictionCondition in the generated token. This makes it easier for the token to be replayed to a different site. Of course, the beneﬁt of a nonauditing IP is that it allows the user to submit their identity information without being tracked. When a token is released from a nonauditing IP, CardSpace will encrypt the token. CardSpace does the encryption because the website’s certiﬁcate is not sent to the IP. Instead, the token is encrypted by the IP for CardSpace, which then uses the website’s certiﬁcate to encrypt the token and release it to the site.

Using CardSpace in the Browser

247

When an IP speciﬁes the RequiresAppliesTo element in the Managed Card ﬁle, it chooses to take on the role of an auditing IP. In this case, the IP is handed full information about the recipient of the token, including the URL of the site and the site certiﬁcate. It is then also responsible for encrypting the token that will be released. Because the IP knows the identity of the website, it can set AudienceRestrictionCondition in the token, and as previously discussed, this makes the token more difﬁcult to use in a replay attack. Also, because the IP is given the certiﬁcate of the site, the IP can help evaluate the identity of the site for the user. For example, if the user tries to use Information Cards at a known phishing site, the IP can use the certiﬁcate to identify the site. In addition, an IP may choose to only allow a card to be used at a speciﬁc set of sites. By evaluating the site certiﬁcate, it could enforce this policy. This could be used by an IP to protect high-value identities, limit where the card can be used, and prevent malicious sites from being able to request the information. Because the IP is now responsible for doing the token encryption, CardSpace will pass the token back to the website, unmodiﬁed. This means that if for some reason the IP does not encrypt the token, it will be sent to the site in the clear. This ﬂexibility allows IPs and websites to agree upon their own encryption strategies, which CardSpace does not need to understand. Although this can be useful, it also puts an extra burden on IPs to ensure they are doing the right thing and not sending data in the clear that should be encrypted. See Chapter 6 for more details.

Different security assurances are available to auditing and nonauditing IPs

248

CardSpace Implementation

Federation with CardSpace Federation works in more complicated cross-organizational scenarios

The deployments covered so far are common for many websites. In these cases, somebody acting as an individual wants to access a site. A more advanced scenario is when somebody acts as a member of an organization, and that person then wants to access the resources maintained by another organization. We have explored an example of that scenario during our discussion of the Identity Laws in Chapter 2, “Hints Toward a Solution,” speciﬁcally in the sections “User Control and Consent,” “Minimal Disclosure for a Constrained Use,” and in the enumeration of the components of the Identity Metasystem, namely in the “Claim Transformers” section. To further understand the scenario, we can look at an example of when an employee at one company needs to access a document that is maintained at another company’s site. In this case, a federated approach to identity management can beneﬁt both companies. It means users only need accounts at the company they work for. This reduces account management cost because there is a single location to maintain account data, or incur other costs, such as password resets. In addition, it makes it easier to ensure account status is accurate. If an employee is leaving a company, only their employer needs to disable their account to prevent their access to partner resources. How does this result in a new deployment pattern for CardSpace? We’ll ﬁrst walk through some of the justiﬁcation for this and then go deeper into the details. Imagine a wholesaler builds a website that allows retail companies to place orders. This could be accomplished by each retailer becoming a Managed Card provider for their own employees. The wholesaler could then let the retailers’ employees use their cards to prove their identities. The wholesaler just maintains a list of retailers that it trusts and accepts cards from those retailers.

Federation with CardSpace

249

The wholesaler likely has some additional business logic about how it processes the claims that it receives, when the users use their card. An example would be all managers with a high spending limit are “preferred” customers and gets special services. This works ﬁne until the wholesaler decides it is going to start a second website. Now this site needs to re-implement the business logic to determine which customers are “preferred.” Adding to the complexity, there are probably multiple retailers that buy from the wholesaler. Each might provide different claim types. Consequently, different rules need to be created and maintained for each retailer. As the wholesaler adds new websites, the problem spins out of control, because the mapping between claims from retailers to “preferred” customers needs to be continuously duplicated. This is when the new federation deployment pattern comes to the rescue. The solution requires the wholesaler to deploy a new security token service. This token service allows the wholesalers to centralize the processing for the following:

Which card issuers are trusted

How to normalize different issuers’ claim types

How to derive new claim values, such as “preferred” customers.

Because the new STS is used to protect resources, and is maintained by the entity that owns the resources, it is referred to as a Resource STS (R-STS). The schema shown in Figure 4-7 represents a concrete implementation of the pattern “Brokered Trust” introduced in the section “The Dance of Identity” in Chapter 2.

Adding an STS reduces the need to duplicate business logic

250

CardSpace Implementation

Resource STS

Identity Provider

Website

CardSpace

Figure 4-7

Implementation of the pattern Brokered Trust

When a website wants to request a token from an R-STS, it must specify the MEX endpoint for the R-STS. This allows CardSpace to get the resource STS’s policy and determine the R-STS’s security requirements. The MEX endpoint is set by using the issuerPolicy property on the browser extension. It needs to be set to the URL that publishes the policy for the R-STS. In this case, the issuer property on the browser extension is just the URL of the resource R-STS’s endpoint, which is used to issue the requested token. Because a MEX policy can describe multiple endpoints, the issuer URL is used to select which to use. CardSpace uses the RSTS token request policy to match cards

In turn, the STS can then request a token from an IP, specifying the usual options in the request, such as requested claims. CardSpace will then allow a user to select a card that satisﬁes the STS’s request. The token from the IP sent to the STS, which returns a token that satisﬁes the original request from the site. At this point, the ﬂow is the same as any other request. The token is posted to the token-processing page and validated. That processing code should verify that the identity of the token issuer is the resource STS, and implement business logic based on the set of normalized claims.

Federation with CardSpace

This interaction does not signiﬁcantly change the user’s experience. The interaction with the R-STS isn’t explicitly shown to the user. That is, the user never sees the identity information for the R-STS. Because the R-STS acts on behalf of the website, it is the website’s identity that is shown on the recipient identiﬁcation page in CardSpace. The one indication that the card may actually be sent to an STS instead of directly to the website is the text that appears in CardSpace: “Cards that are sent to this site may be sent to the site’s designated agents.” The federated deployment is not limited to a single R-STS. There can be any number of R-STSs chained, which can allow business logic to be spread out between them (see Figure 4-8). However, each R-STS adds to the time it takes for a user to use a card because each STS interaction can take several seconds. The transaction time is added to both the beginning and end of the CardSpace interaction: At the start of the transaction, the requirements of the STSs are collected from the MEX endpoints; at the end, as the tokens are requested and returned by the STSs. During both of these actions, the CardSpace progress dialog is shown. Resource STS

Resource STS

Identity Provider

Website

CardSpace

Figure 4-8

Multiple R-STSs

251

252

CardSpace Implementation

CardSpace and Windows Communication Foundation CardSpace is integrated into Windows Communication Foundation

As well as offering website support, CardSpace can be easily integrated into Web services that use Windows Communication Foundation (WCF). In fact, CardSpace is very tightly integrated with WCF and easily used with rich-client applications. This section is meant to give a brief introduction to WCF to help you understand how WCF works with CardSpace. To gain a full understanding of WCF would require a whole other book (for example, Windows Communication Foundation Unleashed, Sams Publishing, 2007). Windows Communication Foundation

Most people’s use of the Web is through a Web browser, browsing between websites. Yet, online activities can be made richer by the use of specialized applications that access online services for speciﬁc purposes but do not require downloading Web pages and being conﬁned to the navigation models used by the browser. A good example of a rich-client application could be one used for banking, which gives a secure client application experience, but is able to connect to an online service to access an account. Custom applications built for employees to access company data or perform daily tasks are another good use. Rich clients allow us to directly access online data or save our data to a secure location, which we can then access from any machine. WCF supports these exact types of clients, making it easy for developers to wire up the services needed to support the applications, reliably and securely. A WCF service is described using a data contract; this describes the functions exposed by the Web service, such as their names and parameters. In addition, services will need to referenced by an endpoint address; this is the URL were the service can be reached.

CardSpace and Windows Communication Foundation

253

A WCF service is described with an address, which describes where the service is available. The address is expressed as a URI, such as the following: HTTP://bankingserver:9001/BankServices/GetBalance

The service also requires a contract that describes how to pass data to the services and which methods are available. The following listing shows a simple contract for a service that returns an account balance. A rich client could use the interface deﬁned in the contract to call a Web service, pass no parameters, and get back a double that represents the current account balance. using System.ServiceModel; namespace BankServices { [ServiceContract] interface IBalance { [OperationContract] double GetBalance(); } }

Also required for describing a WCF service is the binding information. The binding information deﬁnes the requirements for communicating with the service. Among other requirements, it describes the transport that will be used (for example HTTP or TCP) and the security requirements for calling the service. Address, contract, and binding are often referred to as the ABC’s of a WCF service. Using the IBalance interface described previously, let’s take a look at some server and client code for a Web service that supports use of the interface. A class must be deﬁned that implements the IBalance interface. In this example, the AccountManager class performs that role.

This simple example of a CardSpace enabled WCF service illustrates how easily CardSpace works with WCF.

254

CardSpace Implementation using System; using System.ServiceModel; namespace BankServices { class AccountManager : IBalance { public double GetBalance() { // add logic of retrieving the actual // balance from a database return 20000.00; } } class Program { string serviceUri = “HTTP://bankingserver:9001/BankServices”; static void Main(string[] args) { ServiceHost sh= new ServiceHost(typeof(AccountManager) , new Uri(serviceUri)); sh.Open(); //This keeps the service process running // as Web service calls are received // they will be serviced on // other process threads Console.ReadLine(); sh.Close(); } } }

The AccountManager class is then run in a service host (ServiceHost), which is available at the speciﬁed endpoint to service incoming requests. Naturally, a client must be written to call the service. The client sets up a WCF channel to the service:

CardSpace and Windows Communication Foundation using System; using System.ServiceModel; namespace BankClient { class Program { static void Main(string[] args) { ChannelFactory< BankServices.AccountManager > cnFactory = new ChannelFactory< BankServices.AccountManager >("bankClient"); BankServices.AccountManager chn = cnFactory.CreateChannel(); Console.WriteLine(chn.GetBalance()); } } }

Address information about where the service can be reached and which contact and binding to use is set in a client conﬁguration ﬁle (app.conﬁg):

Obviously missing from this example is security. As is, anybody can access the GetAccount interface. Fortunately, adding CardSpace is easy. Adding CardSpace to WCF

Using CardSpace with WCF has many similarities to using CardSpace with the browser. The overall interaction is basically the same:

255

256

CardSpace Implementation

Most of the concepts that apply to using CardSpace in the browser also apply to using CardSpace with a WCF client

1. The user attempts to access a restricted Web service and

is prompted for a card. 2. The user selects and submits a card. 3. CardSpace returns a token. WCF sends this token to the

Web server. 4. WCF performs the token decryption, and performs token

validation. 5. The Web service processes issuer and claims information

to authenticate the user. We’ll take a look at the details of each of these steps, but it is important to note, this enables the ws-* transactions, such as ws-security, as discussed in Chapter 2. Calling CardSpace from WCF

It all starts with the service being able to invoke CardSpace. To do this, the service needs to be able to specify the security requirements that a client must meet to communicate with the service. This is set in the services binding. Speciﬁc bindings and authentication types are used with CardSpace

There are different binding types deﬁned; the different types specify different default values. Speciﬁc binding types are easiest to use with CardSpace. The most restrictive and consequently easiest to use binding type that works with CardSpace is wsHttpBinding. This binding uses the HTTP transport, provides message security and transactions and reliability. In addition, wsHttpBinding can be used to satisfy the service’s security requirement that an "IssuedToken" must be the client credential used for authentication. Other available credential types include certiﬁcates, basic, and windows, but IssuedToken is particularly interesting because it is the credential type that uses the tokens from CardSpace. Here’s what the binding looks like in a WCF conﬁguration ﬁle:

CardSpace and Windows Communication Foundation

Notice that cllientCredentialType is set to "IssuedToken". When this binding is used to secure a service, it will cause WCF to make a call into CardSpace for a token, and the user will be prompted to pick a card. Easy, right? It is; however, it doesn’t give you control over key aspects of the token request, such as which issuer is expected or which claims are required. wsHttpBinding requests a token by any issuer, and only requests the PPID claim.x These defaults can’t be changed with wsHttpBinding. Although these are reasonable defaults for simple cases, in most scenarios it will be desirable to be able to specify the issuer and requested claims. For this extra control, use wsFederationHttpBinding. The following example shows how to use wsFederationHttpBinding in a WCF conﬁguration ﬁle:

257

258

CardSpace Implementation

In this example, "http://schemas.xmlsoap.org/ws/2005/ 05/identity" has been replaced with "http://…" to help readability. When a Web service uses this binding, it is requesting a Personal Card, because the issuer address is set to the selfissued URI. The issuer can be set to the URI of any card provider, just like in the browser scenarios at the start of this chapter. In this example, the email address claim is required, and a phone number is marked as optional. To specify a claim as required or optional, the isOptional attribute can be set. By default, isOptional is set to false, which means the claim value is required. Again, the similarities between the WCF conﬁguration ﬁle and the HTML used to invoke CardSpace are apparent. Decrypting the Token Tokens are encrypted to the service endpoint identity

After a card is used that meets the requirements of the site, the Web service needs to decrypt the token. This is a good point at which to discuss how the token was encrypted. Just like when websites use CardSpace, Web services also identify themselves with a certiﬁcate. The certiﬁcate is used to show the site’s identity on CardSpace’s recipient identiﬁcation site. Also, as with the website, CardSpace encrypts tokens to this certiﬁcate. To specify which certiﬁcate it will use, the Web service’s endpoint needs to be conﬁgured with an identity that has a certiﬁcate reference. This can be done in a WCF conﬁguration ﬁle.

The service element shown here deﬁnes the information about the endpoint address of the service, most notably the identity of the service and the service binding (in this case, wsFederationHttpBinding) and a service behavior. The service behaviors are used to control how the service performs speciﬁc runtime operations.

The conﬁguration example speciﬁes which certiﬁcate will be automatically used by WCF to perform the token decryption. To perform the token decryption, the service will need to be able to access the private key of the certiﬁcate. When the process that hosts the service has been granted access to the certiﬁcate, WCF will take care of the rest and do the decryption with no extra code or conﬁguration required.

259

260

CardSpace Implementation

Verifying the Token

WCF also does a lot of work when performing token validation. The WCF object model ensures the token has not been corrupted and is well formed. The expiration time of the token is also checked. To accept Personal Cards, all RSA keys need to be allowed

Verifying the token issuer is a bit more involved because it often depends on the issuers that a Web service trusts. If Personal Cards will be used, all tokens signed using a RSA key must be accepted, because every card will have a unique key. To allow the Web service to use these keys, the allowUntrustedRsaissuers attribute must be set to true:

This element is set on the service’s behavior, as shown in the previous section. After accepting the token, the signing key can be used to identify the owner of the card. A scheme for doing this is discussed in the next chapter. If the token is generated by a Managed Card provider, the certiﬁcate used to sign the token must be veriﬁed to match the certiﬁcate of the expected issuer. The certiﬁcate of the issuer is acquired out of band and should be stored on the server that hosts the Web service. Processing Claims After the token is validated, the claims it contains can be used

After the issuer identity has been processed, the claims in the token should be used to further authenticate the user or authorize their access to a resource. The claims of a user can be accessed by the AuthenticationContext WCF object. The AuthenticationContext object can be accessed directly within the service, as shown in the following listing.

CardSpace and Windows Communication Foundation

261

AuthorizationContext context = OperationContext.Current.ServiceSecurityContext. AuthorizationContext; foreach (ClaimSet claimSet in context.ClaimSets) { foreach (Claim claim in claimSet) { Console.WriteLine("claim.Resource"); Console.WriteLine("claim.ClaimType"); } }

The claims can then be used to perform any desired checks. Additional Policy Options

As pointed out, the policy options used by the browser extension can also be set in a WCF conﬁguration ﬁle. These include the required issuer, required claims, and optional claims. The other policy options that can be speciﬁed include the following: token type, the issuer’s MEX endpoint, privacy policy URL, and privacy policy version. The options available from the browser are actually a subset of the WCF options. WCF offers more support because it is able to provide active protocol security. This means the token returned by CardSpace can be cryptographically tied to the channel between the user’s client application and the Web service endpoint. The token is bound to the channel using a proof token. This is done by having a reference to the proof token contained within the message returned by the IP’s STS, which also contains the issued token. Then the proof token is used to prove that the user presenting the issued token is the user that the token was meant for. This is strong mitigation for reply attacks. The characteristics of the proof token and how it is used can vary based on the options provided. The interesting options are the following:

A rich client has more conﬁguration settings then a website

262

CardSpace Implementation

KeyType. Used to specify that either a symmetric or an asymmetric key should be used in the proof token. Symmetric keys classically provide faster crypto operations, but are shared between the relying party and CardSpace client, and so are arguably less secure. The CardSpace default is to use an asymmetric proof key.

encryptWith. Speciﬁes the encryption algorithm that will be used to by the proof token. The supported values depend on the KeyType.

signWith. Speciﬁes the signing algorithm that will be used by the proof token. Again, the supported values will depend on the KeyType.

keySize. Speciﬁes the size of the proof key.

EncryptionAlgorithm. The encryption algorithm can also be speciﬁed and is used to determine which algorithm will be used to protect the proof key.

Despite the additional options available when using CardSpace with WCF, the usage of CardSpace with WCF Web services and with websites follow similar patterns and use the same basic options. So although using CardSpace with websites is the more prevalent model, learning to use CardSpace with Web services is a natural progression.

CardSpace’s API can be called directly

CardSpace Without Web Services Both websites and Web services were the primary focus of CardSpace v1. However, other deployment scenarios are possible. CardSpace exposes both native and managed APIs that can be used by C++ and C#. This makes a wide variety of applications possible. Because WCF does not provide native code

CardSpace Without Web Services

support, this is the way to use CardSpace with a C or C++ application and in applications that don’t use Web services. One use is to use CardSpace for authentication to a multiplayer game. For performance reasons, these games are typically written in native code. They also use their own schemes to authenticate to central servers. They would be ideal candidates to use CardSpace for authentication because they could leverage existing infrastructure to perform strong authentication. In addition, if a Managed Card provider issued a Gamer Card, it could be used by a user to identify himself across games, which could be useful when rounding up a match with friends. An Information Card could also be requested by a locally running application to get user proﬁle information. A Managed Card could contain information about a user’s preferred language or favorite color. The application then requests and uses those values to customize the user’s experience, without needing to store or roam the user’s proﬁle. The standard CardSpace APIs are used for the following tasks:

Open CardSpace’s management experience

Import a ﬁle into CardSpace

Get a token from CardSpace

Get a browser token from CardSpace

The native APIs are available in the infocardapi.dll that installs with CardSpace. To use these functions, infocard.h from the Windows Platform SDK is needed. The assembly System.IdentityModel.Selectors.dll, which also installs with CardSpace, implements the managed interfaces to CardSpace. The namespace used is System.IdentiyModel.Selectors. These managed interfaces are how WCF calls into CardSpace.

263

264

CardSpace Implementation

Manage CardSpace

To open CardSpace to Manage Cards is the most straightforward of the calls. The call takes no parameters and opens CardSpace. The native call is as follows: HRESULT _stdcall ManageCardSpace();

And the managed call is this: void CardSpaceSelector.Manage();

Import a CardSpace File The import API allows an application to open CardSpace at the Import Card page

Two types of ﬁles can be imported into CardSpace: a Managed Card ﬁle, issued by an IP; and a backup ﬁle, which contains a collection of the user’s cards. Both can be imported into the user’s local store by calling the import API. This API will open CardSpace and prompt the user to import the speciﬁed ﬁle. There is no way to silently import these ﬁles into the CardSpace local store. The native call is as follows: HRESULT _stdcall ImportInformationCard( __in LPCWSTR ﬁlename);

The managed call is this: void CardSpaceSelector.Import(string ﬁlename);

The import call can be particularly useful when writing an application to distribute Managed Cards. An example is an application distributed by group policy on corporate desktops, which prompts users to install a Managed Card. Get a Token from CardSpace GetToken is used to request a token from CardSpace

This is probably one of the most useful calls available to a developer who wants to develop a native application that works with CardSpace. The GetToken() call initiates a token request,

CardSpace Without Web Services

and makes use of all the policy options available to WCF. However, it was designed to be called by WCF, and consequently, the parameters are very specialized for that purpose. The native call looks like this: HRESULT __stdcall GetToken( __in DWORD cPolicyChain, __in_ecount(cPolicyChain)PPOLICY_ELEMENT pPolicyChain, __deref_out PGENERIC_XML_TOKEN* securityToken, __deref_out PINFORMATIONCARD_CRYPTO_HANDLE* phProofTokenCrypto );

The managed call looks like this: Void void CardSpaceSelector.GetToken( XmlElement endpoint, IEnumerable policy, XmlElement requireRemoteTokenIssuer, SecurityTokenSerializer tokenSerializer);

The parameters of this call are difﬁcult to use. The ﬁrst parameter, endpoint, contains a ws-addressing element that represents the relying party. This will contain the certiﬁcate used to identify the relying party, too. The second parameter, policy, contains the ws-trust policy, containing the requested claims and privacy policy information. The third parameter, requireRemoteTokenIssuer, takes the ws-addressing element that deﬁnes the required token issuer. And ﬁnally, tokenSerializer returns the token from CardSpace. The sample code in the following listing illustrates making a call into CardSpace using the native GetToken call. As it is easy to see, the required values are a bit hard to read. Of note, the relying party http://relyingparty/endpoint would be the URL that uniquely deﬁnes the party the token will be released to. The base 64-encoded blob inside the X509Certiﬁcate element has been truncated, but it is just the certiﬁcate of the relying party that the token will be encrypted to.

265

266

CardSpace Implementation POLICY_ELEMENT policy; policy.targetEndpointAddress = L" http://relyingparty/endpoint MIIDwj…N1P8uZL/ygF3rMlvFfxSWi/Ro0H8lﬂi7sR KtI3/uvxK/Oo9SX3UL91KVz+5rnoB+EDoFBkUYEK "; policy.issuerEndpointAddress = L" http://issuer/departmentoﬂicensing "; policy.issuedTokenParameters = L" "; policy.privacyNoticeLink = L"; policy.privacyNoticeVersion = 0; policy.useManagedPresentation = FALSE; PGENERIC_XML_TOKEN securityToken = NULL; PINFORMATIONCARD_CRYPTO_HANDLE phProofTokenCrypto = NULL; if( S_OK != GetToken( 1, &policy, &securityToken, &phProofTokenCrypto ) ) { printf("GetToken failed"); } if( !FreeToken( securityToken ) ) { printf("FreeToken failed"); } if( S_OK != CloseCryptoHandle( phProofTokenCrypto ) ) { printf("CloseCryptoHandle failed"); }

CardSpace Without Web Services

267

The example also shows how claims can be requested; in this case, an email address is required. Also, issuerEndpointAddress is set to the URL of the issuer http://issuer/departmentoﬂicensing, which will be used by CardSpace to enable only the applicable cards. Just to restate the obvious, GetToken() was not designed to be called directly in an easy fashion, but in some cases it can be rather useful. Get a Browser Token from CardSpace GetBrowserToken() is only available from native code. That’s

because it was written speciﬁcally to be called by browser extensions, which are written in native code. This call is how Internet Explorer calls into CardSpace, and should be used by other browser extensions, too. HRESULT __stdcall GetBrowserToken( __in DWORD dwParamType, __in PVOID pParam, __out_opt DWORD* pcbToken, __out_bcount_opt(*pcbToken) PBYTE* ppToken );

The DWORD dwParamType speciﬁes the type of struct type passed into pParam. The only value supported for CardSpace v1 is dwParamType=1; this means the pParam type will be of type RecipientPolicy. This is also deﬁned in infocard.h. Although the direct API calls into CardSpace are more burdensome, it is nice to have them available to enable native and client-only applications access to CardSpace.

The GetBrowserToken call is used indirectly by websites

268

CardSpace Implementation

Summary CardSpace can accommodate a wide range of deployment scenarios. These range from the simple self-issued token cases, used for logon to a website, to the more advanced case federation and Web services scenarios. Less-user-friendly, yet powerful, direct API calls are available for managed and native applications. Regardless of the type of application, the interaction with CardSpace follows a consistent pattern: 1. Relying party speciﬁes token requirements. 2. CardSpace is shown. 3. User selects a card that meets the requirements. 4. A token is sent to the relying party.

When the relying party receives the token validation, and processing also follows a similar pattern: 1. Token is decrypted. 2. Token signature is veriﬁed. 3. Token expiration time and other properties are veriﬁed. 4. Claims retrieved and used.

The consistency of use across the wide number of scenarios is part of the power of the Information Card model. This allows the application or Web developer to look at identity in the same way and implement consistent rules across applications.

5

Guidance for a Relying Party As the previous chapters have made clear, in a variety of situations it is appropriate for a relying party (RP) to use CardSpace. The manner in which to use CardSpace depends on a number of factors, and these should be considered carefully before embarking upon widescale changes to a website. Once a website has decided that it wants to use Information Cards and has an idea of how that impacts its business, incorporating the changes required to add the support is fairly straightforward. With minor changes to the database and hosting environment, and the enhancement of a few key pages in the site, the transformation is quickly achieved. This chapter examines the impacts of adopting Information Cards for an RP and provides practical guidance for applying the requisite changes to the website.

An Information Card represents a digital identity

269

270

Guidance for a Relying Party

■ Perspective: Information Cards, not CardSpace This chapter refers to support for Information Cards—not CardSpace—because CardSpace is just one implementation of the technology that gives the user the capability to sign in using an Information Card. This guidance is designed to work across different browsers and platforms, both client and server. To facilitate this, there are no Microsoft-centric Information Card logos, and the wording is kept very generic and plain so as not to promote any implementation over another. In the actual implementation of a website or application that uses Information Cards, a strong effort should be made to ensure that a user of any platform or technology that supports the Information Card concept is welcomed. Avoiding the use of the terms CardSpace and instead using (codename) InfoCards is more appropriate.

Deciding to Be a Relying Party With the release of the ﬁrst version of CardSpace in the fall of 2006, the era of stronger, safer, and more ﬂexible identity technologies is just beginning. Technology adoption in a marketplace generally happens in several phases and can be divided by the characteristics of the consumers in each phase:

Innovators are those with their ﬁnger on the pulse of the market, who venture forth in new technologies and markets, accepting the risks of proving new ground.

Early adopters tend to be industry leaders, well respected, who use new technology to gain a competitive advantage in the market.

Early majority consumers spend considerable time and effort to educate themselves on changes in the marketplace and follow the early-adopter crowd only after they are convinced that everyone else is likely to proceed.

Deciding to Be a Relying Party

Late majority are the latter part of the majority crowd, and they tend to be motivated less to move toward newer technologies, moving when it becomes a foregone conclusion.

Laggards are risk-adverse consumers, often waiting until there is no choice.

271

The consumers of the new identity technologies are not end users, but rather they are companies that leverage these technologies to provide their end users with greater security and functionality, which translates to an edge in the marketplace. At an individual level, companies, websites, and developers are starting to embrace these technologies, ﬁrst on a small scale and expanding outward. Impact on the marketplace will not happen instantly, as adoption needs to take place by the thousands, and then by the tens and hundreds of thousands. Industry innovators and early adopters will be the ﬁrst to embrace this new generation of identity technologies. In exchange for the beneﬁts that working within the Identity Metasystem provides, these pioneers are adopting the supporting technologies and changes in infrastructure. The changes are primarily technology choices, although there are some changes of philosophy involved. Changes include the following:

SSL certiﬁcates. Used to allow relying parties to identify themselves. Extended Validation (EV) SSL certiﬁcates raise the bar with greater scrutiny, additional checks, and a guarantee from the certifying authority.

Cryptography. Not only the foundation for HTTPS, but the encryption and digital signatures that are part of WS-*.

WS-*. Speciﬁcations providing interoperable protocols for security, reliable messaging, and transactions in loosely coupled systems. For RPs, the pieces of WS-* required are small; at a minimum, Extended Markup

Adopting support for Information Cards requires changes at the server

272

Guidance for a Relying Party

Language (XML) Signature and XML Encryption are required to accept tokens via a POST from the browser over Secure HyperText Transfer Protocol (HTTPS).

There are many different reasons to use Information Cards

Increasing awareness around privacy. Greater concerns around data security and privacy are encouraging RPs to reevaluate the types of information they request and store about their users. Limiting the types of identifying information and private data about users decreases potential legal liabilities in the event of a breach.

Websites interested in using Information Cards can choose their own level of comfort, deciding on speciﬁcally which features they would like to adopt, to gain the following:

Form ﬁlling. Filling in commonly found ﬁelds in websites, saving users time and effort. This can be done with little effort.

Simple authentication. Using Information Cards as a replacement for usernames and passwords, enhancing existing web-based systems. As the most common proﬁle for using Information Cards, this is accomplished with a modest level of effort.

Extended authentication. Deploying a resource Security Token Service (STS), ofﬂoading the authentication services onto other servers, and even possibly outsourcing those services to other companies. Adopting an STS is signiﬁcantly more effort and requires a greater understanding of WS-* and the mechanics of the Identity Metasystem.

Claims-based programming. Accepting identity information from identity providers (IPs) and using that information to make service decisions. This level of involvement really pushes far more fundamental changes in application architecture and design.

Deciding to Be a Relying Party

273

Identity federation. Creating relationships between entities to accept identities and grant access to services based on the nature of those relationships and the claims asserted. The crowning achievement in identity technology, federation provides consumers the capability to use their digital identity where it best suits them and enables businesses to offer services and collaboration with others that were previously unachievable.

■ Perspective: Is CardSpace an Effective Tool for CAPTCHA? Websites commonly employ CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart) mechanisms to combat spammers, fraudsters, and the other hordes of automated-tool-wielding barbarians. CardSpace does provide an interface where users are required to take steps to produce a token that the website can use. A website employing JavaScript to engage the Identity Selector could potentially use CardSpace to prove the existence of a human on the other side of the wire. Although it would be possible to build a tool to automatically generate tokens that a website is looking for, it would be a large task to perform the XML creation, signing, and encryption. Add to that the effort required to attack a website using it in an automated fashion when the website is using JavaScript to call for the selector, and it would certainly be prohibitive by many orders of magnitude. Even with the advent of farms of low-wage workers in disadvantaged countries solving graphical CAPTCHAs for mere fractions of a cent per click for spam purposes, CardSpace has an additional mitigation: The tokens coming from a single card to a relying party would have the same Private Personal Identiﬁer (PPID) and card issuer’s public key. The phraud-farmhand would need to constantly create new cards, a process that is far from instantaneous, and thanks to the protected desktop that CardSpace executes in, extremely difﬁcult to automate. Final answer: Maybe.

274

Guidance for a Relying Party

Putting CardSpace to Work Internet applications and websites are as varied in style and execution as they are in the content they provide. It is a trivial exercise to visit a dozen different websites and ﬁnd a dozen different ways to authenticate. Although each website is certainly entitled to design from the ground up how authentication is presented, there nonetheless are consistent patterns and practices that users have come to rely upon. In-depth user testing focusing on authentication has exposed several aspects of website design that users expect when using a site. The processes for account creation, recovery, and sign in are very common across websites. Even speciﬁc details such as layout and ﬁeld sizes are remarkably common. When websites conform to these unwritten standards, users are less likely to get confused and abandon their visit. Users expect interfaces to be consistent

When adding support for Information Cards on a website, the site designer needs to spend some time to ensure that the changes are clear, unobtrusive, and presented in a manner that enables the user to use Information Cards naturally, and that the changes don’t create a negative impact on the site developer. The processes for adding support for Information Cards on a website are presented as a set of conceptual and design guidelines. Each of these guidelines is fairly broad and can be easily applied to a wide variety of sites. A designer who deviates from these guidelines must carefully consider how to apply those changes to ensure that the user doesn’t leave the site because it’s difﬁcult to understand. The principal processes covered in this chapter have been designed and tested with users to facilitate adoption of Information Cards, and to minimize possible user confusion. Although the focus is weighted toward the usage of Personal Cards, many of the principles can be applied to scenarios where Managed Cards are used, too.

Putting CardSpace to Work

275

■ Perspective: An Era of Hybrid Authentication In labs, samples, and test sites, it is easy to build a website that relies entirely on Information Cards. As simple as it is, it’s clear that adoption of Information Cards as an authentication mechanism will happen over time. Despite the shortcomings as an authentication method, passwords will remain in widespread use until a viable replacement attains complete ubiquity. Until then, websites need to start enabling technologies beyond passwords without replacing them entirely. This is called hybrid authentication. Hybrid authentication is expected to comprise the majority of RP implementations in the foreseeable future. Most of the guidance in this chapter revolves around changes to websites enabling Information Cards alongside password authentication. For scenarios that extend beyond the speciﬁcations laid out here, take the time to examine the scenario for usability, security, and scalability issues.

Preparation

To accept Information Cards, the server environment must be conﬁgured correctly. Websites may have addressed some or all these issues already; but when working with security tokens, these become critical for success. Ensure that the server is set to the correct time. Security tokens are time stamped, and with greater control over the accuracy of the timekeeping of the server, the window for accepting tokens can be narrowed, limiting the opportunity for token replay and man-in-the-middle attacks. An SSL certiﬁcate becomes more than a simple requirement for HTTPS encryption. The certiﬁcate represents the identity of the RP, as assured by the certiﬁcate authority. The RP should ensure that the SSL certiﬁcate contains up-to-date and correct data and that the certiﬁcate authority is viewed as trustworthy.

Servers should be synchronized to the current time

276

Guidance for a Relying Party

EV certiﬁcates are available from most certiﬁcate authorities

Consider the use of EV certiﬁcates, if possible. EV certiﬁcates are not required, but for businesses that believe their online identity beneﬁts from the greater assurance afforded customers, these certiﬁcates can prove invaluable. Because EV certiﬁcates require more time and effort to secure, and are limited to protecting a singular domain (wildcard EV certiﬁcates are not permitted), they should be acquired earlier rather than later. In addition, if the EV certiﬁcate contains a logotype extension, it is critical that the full URL of the logo points to the appropriate graphic and continues to do so.

SSL certiﬁcate private keys are normally not used by an application

Make the certiﬁcate private keys to the application available. This is a signiﬁcant change and one that is unlikely to be in place before using Information Cards. Generally, cryptography has been used for transport-level encryption only, and therefore access to the private keys has not been granted to the web application itself. To perform the message-level decryption of the security tokens posted by the client, the private keys are required. How you accomplish this is speciﬁc to the platform on which the application is hosted. Database Changes

Support for Information Cards can be added to any database

To accept Information Cards for authentication, additions to the website’s database are made to handle the data required for authentication and account maintenance. To minimize the impact of adding support for Information Cards, you should make these changes in a way that does not require you to modify existing tables, views, or procedures. The addition of a single table, with a foreign key relationship to the existing index of users, provides a fairly hands-off approach to existing data and enables users to associate more than one card with their accounts.

Putting CardSpace to Work

InformationCards

PK

UniqueID

FK1

UserID PPID IssuerID

Figure 5-1 Cards

277

Users

PK

UserID FirstName LastName EmailAddress

A typical database schema for a site to support Information

The data for Information Card support includes the following:

UniqueID. Depending on the speciﬁc implementation, this is either an auto-generated index value or unique identiﬁer generated as a result of the token processing. In many implementations, it is generated as a hash of the PPID and the issuer’s identity (RSA public key).

UserID. The existing account identiﬁer that can be used as a foreign key to the InformationCards table.

PPID. The PPID (Private Personal Identiﬁer) claim from the token. This is different from the site-speciﬁc ID that the user sees in the Identity Selector (see the sidebar “The Site-Speciﬁc ID”). IssuerID. Storing the identity of the issuer is optional. This is valuable in situations where the websites accept Managed Information Cards and may need to update the UniqueID if the IP changes its certiﬁcate keypair. This could also be implemented as a foreign key to a database of issuer identities.

Examining the Authentication Experience

For authentication on websites today, some elements are nearly identical on most sites (for example, two entry ﬁelds and a button), but some elements are less common but are often found in

The user never sees the PPID directly in CardSpace

278

Guidance for a Relying Party

one form or another (a check box for Remember Me, for instance, and a link for Forgot Your Password?). Figure 5-2 summarizes the typical user experience. Most websites rely on usernames and passwords

The variants of this pattern are virtually endless and are played out on the Internet every day. Still, users can use the username and password sign-in effectively, even on sites they have never visited before. The inertia of this pattern is so strong that in initial testing with Information Cards, users didn’t even see the alternative sign-in graphic (which was very large), skipping past it to get to the traditional username and password sign-in. Developing the New Authentication Experience

JavaScript is a scripting language built in to browsers

The ﬁrst step in accepting Information Cards is to validate that the client actually supports the capability to communicate with

Figure 5-2 Typical user experience in a site without support for Information Cards

Putting CardSpace to Work

Perform ClientSide Detection

Does the browser support Information Cards?

No

Web Page Without Card Support

Figure 5-3 Cards

Yes

Card-Enabled Web Page

Ascertaining the client’s capability to use Information

the website using Information Cards. The radically different design of different browsers on different platforms and devices means that different vendors will have to implement their Identity Selector in signiﬁcantly different ways. This makes it increasingly difﬁcult to detect the support for Information Cards across all platforms. The most effective way to determine whether a platform is supported is to use JavaScript to query the capabilities of the browser and change the user interface accordingly. After you have done that, you can adjust the user interface to reﬂect the client’s abilities. Figure 5-3 summarizes the validation process. Here is a JavaScript function a web developer can use to interrogate the browser’s support of Information Cards: function AreCardsSupported() { /// /// Determines if information cards are supported /// by the browser. /// /// /// true-if the browser supports information cards.

279

280

Guidance for a Relying Party /// var IEVer = -1; if (navigator.appName == 'Microsoft Internet ➥ Explorer') if (new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})") .exec(navigator.userAgent) != null) IEVer = parseFloat( RegExp.$1 );

CardSpace is supported on Internet Explorer 7.0 and later

// Look for IE 7+. if( IEVer >= 7 ) { var embed = document.createElement("object"); embed.setAttribute("type", ➥"application/x-informationCard"); return (""+embed.issuerPolicy != "undeﬁned" && ➥ embed.isInstalled); } // not IE (any version) if( IEVer < 0 && navigator.mimeTypes && ➥ navigator.mimeTypes.length) {

The Firefox extension for CardSpace can be detected by raising an event

// check to see whether there is a // mimeType handler. x = navigator.mimeTypes[ ➥'application/xinformationCard']; if (x && x.enabledPlugin) return true; // check for the IdentitySelector event handler is there. if(document.addEventListener) { var event = document.createEvent("Events"); event.initEvent("IdentitySelectorAvailable", ➥ true, true); top.dispatchEvent(event); if( top.IdentitySelectorAvailable == true) return true; } } return false; }

The code performs a few checks to determine whether Information Cards are supported. First, it checks whether the browser is Internet Explorer. If it is, and at least version 7 (the ﬁrst version to support CardSpace), it attempts to create and use the CardSpace ActiveX object. On other browsers, it checks for one of two possibilities: either a registered mimeType handler that supports the application/x-informationCard type, or it

Putting CardSpace to Work

looks for the event listener in the Firefox extension. Upon the loading of the Hypertext Markup Language (HTML) document in the browser, the JavaScript function to determine the presence of card support is called, and the developer can use the result to alter the presentation of the page accordingly. Cascading Style Sheets (CSS) and JavaScript make this possible with little effort: function ShowCSSClass(cssClass) { var elements = document.getElementsByTagName('*'); var pattern = new RegExp("(^|\\s)" + ➥ cssClass + "(\\s|$)"); for(each in elements) if(pattern.test(elements[each].className)) elements[each].style.display = 'block'; } function SetupPage() { ShowCSSClass( AreCardsSupported() ? "CardsSupported" : "CardsNotSupported" ); } Show this when cards are supported. Show this when cards are not supported.

281

282

Guidance for a Relying Party

The web page can change based on capabilities

The preceding code demonstrates how to easily use two CSS classes (CardsSupported and CardsNotSupported) and the JavaScript AreCardsSupported() function to dynamically change the user interface the client renders, depending on whether Information Card support is present. With such a technique, a typical sign-in experience is transformed from the “username and password” style of authentication prompt into one that supports Information Cards, as shown in Figure 5-4. In the Information Card–enabled user interface, the user is presented with three important visual elements:

Figure 5-4 Cards

User experience in a site with support for Information

Putting CardSpace to Work

Sign In with Your Information Card button. Clicking the button will cause the user’s Identity Selector to appear and allow the user to select a card. The button should indicate what the user is doing with the card, if possible. In this case, the user is being prompted to sign in.

Don’t Have Your Card? link. Clicking this link will take users to the recovery page, where they can do one of several tasks, depending on why they don’t have a card.

What Is This? link. Clicking this link gives the website the opportunity to inform the user about Information Cards and why using cards is beneﬁcial. This link is especially important because the concept of Information Cards is very new, and most users will not know about them.

283

Depending on the preferences of the website, the Remember Me Next Time check box can also be included, which simply notiﬁes the website to set a cookie, the same way a site using username and password for authentication does.

■ Perspective: Accessibility—Another Feature? Notice the subtle underline of the letter i on all the Information Card buttons in the visuals presented. This is done to accentuate the suggested hot key for an Information Card sign-in button. Setting the accesskey attribute to the i on the button or link used to engage the Identity Selector allows the user to use the keyboard to sign in. This can be accomplished via HTML: Click me

Or attach it to the visual element via JavaScript: document.getElementById("icButton").accessKey = "i";

Different browsers and different platforms implement keyboard hot keys differently; on a Mac, the hot key pattern is typically Command+key, Mozilla browsers user Shift+Alt+key, and Internet Explorer uses Alt+key.

284

Guidance for a Relying Party

Disabled elements are usually shaded light gray

When the client lacks the capability to use Information Cards, the developer has the choice of simply hiding the new functionality or displaying it in such a way that the user can’t attempt to use it, but does have the opportunity to learn about it. Figure 5-5 shows a dialog box from such a web page. When the client doesn’t support Information Cards, the sign-in button is shown, but it is disabled. There is also a link for the user to click to ﬁnd out more about Information Cards (Why can’t I use this?); the link leads to a page that informs users not only what Information Cards are but also why they can’t use them and how they can get support for them on their particular platform.

Figure 5-5

User experience in a site without Information Card support

Putting CardSpace to Work

285

■ Perspective: Why Show the Experience, Even When the

User Can’t Use It? In the beginning, end-user testing revealed that some of the early assumptions about the presentation of authentication controls on the web page were painfully counterproductive, and often left the user confused. The goal was to not only introduce Information Cards to users who might not otherwise know about them, but to also provide a fast, convenient way to use them in the long term. The user experience must train users to look for the Information Card sign-in, but not handle it in such a way that it would seem to be unwieldy or irritating. With the recent introduction of Information Cards, RPs not only have to add the support for accepting them, but they must also convince users of the beneﬁts and convenience of using them. Although it certainly is the RP’s choice to teach the user or not, the long-term reciprocal beneﬁts of using Information Cards (faster sign-up, lower drop-off, identity federation) to authenticate to the website should encourage sites to opt for the “path of enlightenment.”

Signing In

The sign-in process itself is fast and quite simple. It becomes increasingly more complicated when the user attempts to do the right thing but still fails to authenticate. Unlike the case in which a username and password are used for authentication and the user makes a mistake in typing in those credentials, if the token is successfully submitted to the website, it is much less likely that a mistake on the user’s part has been made. Figure 5-6 shows the sign-in process. When the user submits a security token by clicking the Sign In button, selecting a card, and sending it to the website, the site ﬁrst mechanically processes the token (decryption and validation). When the website is conﬁdent that the token is genuine, the next step is to determine whether that card is associated with

Signing in should be fast and simple

286

Guidance for a Relying Party

Please Sign In User name: Sign in with your Information Card

or

Password:

Is this card associated with an account?

Yes

No

Choose:

The user is signed in.

Associate with an existing account Create a new account Choose a different card

Welcome back to the website

Figure 5-6

Signing in to a website with Information Cards

an account. The particulars of the token are matched against the local database; if a match is found, the user is signed in. In the case of many websites, this involves setting an authentication cookie—which should still be done—and the client is then directed to the appropriate page. Handling the Unknown Card An unknown card is one that the website has not received before

Until Information Card adoption becomes commonplace, the most likely scenario is that the user will not have previously registered his card with the website. In the event that the card is not recognized, the user should then be prompted as to what he wants to do, by way of being directed to a new web page (see Figure 5-7).

Putting CardSpace to Work

Figure 5-7

A user presents a card the website does not recognize.

The website options guide users to the next step:

Associate your card with your existing account. In the majority of cases, users will likely have an existing account that they currently access via username and password authentication. Alternatively, users might also choose this option if they are trying to recover their account by presenting a new Information Card. In either case, selecting this option will start a variant of the recovery process.

Create a new account. When users want to create an account, they can use this option. This will start the process of new account creation.

Return to the main page. If the user selects the wrong Information Card, the user is offered the opportunity to return and select a different card or to sign in with a username and password.

Whatever the case, at this point the website already has some information about this user—in this case, his ﬁrst name—and can use that information to provide the user a better experience.

287

288

Guidance for a Relying Party

Associating an Information Card with an Account Accounts are often related to an email address

To associate the user’s account with an Information Card, it is necessary to prove ownership of the account. Two of the easiest methods the website can use is the existing username and password credentials and conﬁrmation of the user’s e-mail address, previously stored with the website (see Figure 5-8). Users opting for username and password authentication just enter their credentials and have the card associated with their account. The second method of authentication is to send users an email message to the address in their card containing instructions and a cryptographically generated code and have them respond to that to prove they control that email address. A possible web page that implements such a system would look something like Figure 5-9. Creating a New Account

Perhaps the most compelling use of Information Cards for a commercial website is using cards to accelerate account signup. A user may submit a card and with no additional effort (except maybe email conﬁrmation) have an account created. Websites constantly battle against drop-off (a user leaves the website before completing a transaction), and anything that can make the process just a little bit simpler may encourage users to continue the transaction and make a purchase.

Sign In User name:

Choose: Authenticate via:

Password:

Associate with an existing account Username/Password Create a new account Proof of account

Choose a different card

Send email confirmation

Figure 5-8

Associating an Information Card with an account

Putting CardSpace to Work

Figure 5-9

289

Performing an alternative authentication of the user

■ Perspective: Closing the Username and Password Gap? After users have moved on and have begun using an Information Card rather than username and password for authentication, what good is their password? Passwords remain the focal point for phishing; after all, a cleverly built email can still fool enough users to divulge their password to make it worthwhile to continue the practice. Should you turn off the username and password authentication route after a user has made the switch? It is difﬁcult to argue that it should be done without the user’s consent, but perhaps in the account management page, an option to “allow sign in via Information Cards only” is reasonable. Unfortunately, users who would seek out and voluntarily take advantage of the increased security by turning off their password authentication are much less likely to be deceived by a phishing scam. In a year or two, the answer to this might become more apparent as user uptake increases and the passwordphishing landscape changes.

290

Guidance for a Relying Party

Simpliﬁed signup can lower drop-off

Account creation, therefore, must not only be simple, it must also be lightweight enough that the user can continue the transaction without missing a step. Done properly, there is more than one entry point into the signup process. Users can explicitly create an account, or they can just present a card to sign in with and create an account inline. Another way to look at it is this: Users come to a website, do a little “window” shopping, and ﬁnd something worth buying. When they are used to using Information Cards and know that they can click the Sign In button to get quickly to the end of the sale (and not have to remember if they’ve been to the site before, or even whether they have an account), they know that it’s going to be fast. The impact of this ease of use will be quite impressive. Depending on the amount of validation a website requires, the new account process could potentially be invisible and instantaneous (see Figure 5-10). Implicit Sign Up

Explicit Sign Up Registration:

Choose:

Sign Up for Your Membership to the Club.

Associate with an existing account

Sign in with your Information Card

User name: Email: Password:

Create a new account

Confirm Password:

Create User

Choose a different card

Optional Validation Steps

The user is signed in.

Welcome back to the website.

Figure 5-10

Creating a new account

Putting CardSpace to Work

291

The modiﬁed user interface that supports both the existing formbased signup and the Information Card model would look something like that shown in Figure 5-11. The button is accompanied by a link that again helps users understand what exactly they are seeing. Recovering an Account

As mentioned earlier in this chapter, the account-recovery process overlaps with the card-association process. At their roots, they both accomplish the same thing: They enable users to prove that they control an account and provide the capability to associate a card with it. In practical terms, websites should

Figure 5-11

User experience for creating a new account

Users must be able to recover their accounts

292

Guidance for a Relying Party

provide pathways that work for both, in anticipation of user needs. Users navigate to the account-recovery page and are presented with several options to prove control of their accounts (see Figure 5-12). The web page shows three different ways to regain control of an account if the user does not have her card. First, she can show a card she does have and begin the validation process via email based on the email address claim in the card she presents. Or she could simply type in the email address and begin the same

Figure 5-12

User experience for account recovery

Putting CardSpace to Work

293

process. Or she could use her username and password to authenticate and just associate a new card. To verify the user possesses control of the email account, the website generates a secret, which is mailed to the user. The user replays the secret back to the website, thereby demonstrating control of the email account. When used with Information Cards, it is critical that the Information Card be presented to the website after the user validates the email address and that the email address in the card match the email address to which the secret was sent. This prevents unwary users from accidentally clicking a link and validating an email address by mistake.

■ Perspective: Alternative Security Measures for

Authentication A common trend with websites is to ask additional questions: for example, “What is your mother’s maiden name?” and “What city were you born in?” These questions are often used for “enhancing” authentication, or worse, authentication itself. Proponents of this type of security believe that these qualify as “something you know” and therefore are sufﬁcient to prove or assist in proving identity. The trouble with using questions such as these is that this merely becomes an arms race and eventually falls prey to modern methods of pre-texting and phishing. Not all that long ago, before computers roamed the Earth, it was easy enough to use only a credit card number over the phone—or even in person—to buy goods and services. The algorithm used to generate card numbers (called the Luhn formula) wasn’t widely known, and many merchants (and card issuers) treated possession of the card number as possession of the account itself. After fraud levels increased, card issuers required the accompaniment of the expiry date—a fact that only the cardholder and the card issuer would know—to be able to charge to the account. Of course, the inevitable happened; fraudsters began to acquire the expiry dates to go with the account number. Card issuers fought back again, and in the late 1990s they added the Card Security Code

294

Guidance for a Relying Party

(CSC), another number added to the physical card that is not embossed nor included on the magnetic stripe. Merchants are instructed to not store the CSC so as to limit the damage if their database is exposed by hackers, but the proliferation of fraud continues. In reality, knowing someone’s mother’s maiden name does not prove that you are that person, rather that you simply know that person’s mother’s maiden name. Other questions that are just statements of fact fall under this same category and should really be avoided. At the lowest level, they could even be deﬁned as shared secrets, with emphasis on shared. To use questions as a form of authentication, the questions should be geared toward describing the relationship between the two parties. Questions such as “When did you last sign-in?” “How long have you been a member?” and “Approximately how many transactions have you done this month?” are more likely to provide assurance that users are actually who they say they are, but such “authentication” should use enough questions to be thorough. In the end, proving control of an email address doesn’t absolutely guarantee identity either; you can think of it as a form of primitive federation. (After all, the RP is essentially relying on the email service provider to properly authenticate the user.) It is wise to consider all avenues of attack when utilizing an alternative authentication mechanism.

Prompting the User to Use Information Cards Messages are used to prompt the user to action

Despite the changes to the user interface, users may ignore elements in the page that they believe are not related to the task at hand. Gentle guidance using passive notiﬁcation can be employed to assist these users in stepping up to using Information Cards. This is predicated on the client actually having support for Information Cards (which was detected earlier). When clients sign in with a username and password, the website can notify users that they have the option of using an Information Card (see Figure 5-13) and step them through the process.

Putting CardSpace to Work

295

Figure 5-13 Notiﬁcation when a user does not have a card associated with his account

If users sign in using a username and password, and have at least one Information Card associated with their account, they should receive a different style of warning. This could be perfectly innocent—users might not be at a computer where they have their Information Cards stored, or it could be because they have lost control of their cards, and need to revoke the capability to sign in with them (see Figure 5-14).

Users may still access their account without a card

When users log in and receive this warning, they have the opportunity to visit the account maintenance page, which will allow them to remove the old card association and optionally add a new one. Websites should be careful when implementing passive notiﬁcation. They need to do so in such a way that gives a user the option to dismiss them permanently.

Figure 5-14 account

Notiﬁcation when users have a card associated with their

Passive notiﬁcation doesn’t force the user to acknowledge the message

296

Guidance for a Relying Party

■ Perspective: Passive User Notiﬁcation During user testing of these scenarios, when users used CardSpace, they sometimes found themselves changing contexts (switching back from the protected desktop after sending a token) and suddenly not understanding what had just transpired. Even though they expected to be logged in to the website, they didn’t react as if that is what they had done. Adding in a pop-up message to notify users about what they had done was very effective and well received. After testing was completed, a user-experience expert pointed out that pop-up messages work well in testing, but in the real world, users become irritated with them quickly and will complain. Faced with the realization that the user must be notiﬁed and that the notiﬁcation must be accomplished without causing irritation, a series of passive web page visuals were created that simulate commonly found effects in desktop applications. Two of these proved to be quite effective, providing the required notiﬁcation and opportunity to react when required (but also being easy to ignore). The ﬁrst is modeled after the information bar found in modern browsers—the little brightly colored bar across the top of the page that pops down when the user is asked to acknowledge a situation that may be a security risk (see Figure 5-15). The bar, colored purple, is a stark contrast to the web page and is designed to catch the eye. The bar is animated so as to drop down into view, wait 15 seconds, and then remove itself. The bar contains a small message, with optional links to enable the user to take an action upon seeing it. The user can also click the X at the far right of the bar to dismiss it instantly. The second was modeled after the “toast” (or desktop alert) that popular email software pops up in a lower corner of the screen (see Figure 5-16). It, too, is animated so as to catch the user’s eye but not cause irritation.

Figure 5-15 of an event

A pop-down information bar to passively notify the user

Putting CardSpace to Work

Figure 5-16 an event

297

A pop-up information bar to passively notify the user of

It is quite clear that the use of Information Cards is enhanced signiﬁcantly when a user is presented with effective, yet passive, notiﬁcations. Web developers would be wise to adopt one of these methods or create other ones that achieve the same goals and ﬁt with their website aesthetics.

Account Maintenance

Some roaming users will opt not to move their cards from one computer to another. If the website implements a many-to-one card association with accounts, users should be able to simply add or remove cards from their account. The difﬁculty with this is that a user can potentially create two cards with exactly the same claims, but not the same PPID and keypair. Unfortunately, there are limited ways to tell the cards apart at this point. The only empirical data available to the website is to use the sitespeciﬁc ID and list the cards the user has associated with the website (see Figure 5-17). This may optionally be coupled by showing the last sign-in time of that particular card.

Users can export their cards and take them to another computer

298

Guidance for a Relying Party

Figure 5-17 Suggested user experience to allow users to edit the cards associated with their account

The Site-Speciﬁc ID The site-speciﬁc ID (SSID) is not the same thing as the Private Personal Identiﬁer (PPID), but the two are related. The SSID is a lightweight distillation of the PPID, for the speciﬁc purpose of allowing the user to easily read the SSID, and possibly communicate it to another party, to ﬁnd a particular record. It is not intended to be used in place of the PPID for authentication or comparison; it is there merely as a convenient cosmetic representation. The C# code to calculate the SSID looks like this: /// /// /// /// /// /// /// /// /// ///

Generates the site-speciﬁc ID to match the one in the Identity Selector. The Identity Selector displays this instead of displaying the PPID. the PPID a string containing the XXX-XXXX-XXX cosmetic value

Privacy and Liability

299

/// public static string CalculateSiteSpeciﬁcID(string ppid) { int callSignChars = 10; char[] charMap = ➥"QL23456789ABCDEFGHJKMNPRSTUVWXYZ".ToCharArray(); int charMapLength = charMap.Length; byte[] raw = Convert.FromBase64String(ppid); raw = SHA1.Create().ComputeHash(raw); StringBuilder callSign = new StringBuilder(); for (int i = 0; i < callSignChars; i++) { // // after char 3 and char 7, place a dash // if (i == 3 || i == 7) { callSign.Append('-'); } callSign.Append(charMap[raw[i] % charMapLength]); } return callSign.ToString(); }

Privacy and Liability Many websites are only now becoming aware of the responsibility they bear toward the safekeeping of the information customers have exposed to them. Almost weekly, news comes out reporting that a company, university, hospital, or government has leaked private customer data, exposing their users to privacy loss, fraud, or identity theft. These leaks can be very dangerous not only to the individuals but also to the companies themselves. One way a company can reduce the potential liability for mishandling or exposing data is to limit the amount of personally identiﬁable information (PII) it stores. PII is data that can be used to uniquely identify, link, contact, or ﬁnd an individual. PII is not always instantly recognizable as such when left uncorrelated with other data, and so some measure of diligence must be applied to recognize it, in or out of

Privacy is a strong concern for most users

300

Guidance for a Relying Party

context. Elements that may be considered PII include the following:

Names. First/last names.

Street addresses. Any past or present street addresses of the individual. With other data, even the municipality and ZIP code can often focus the scope down to a single individual.

Telephone numbers. Mobile numbers, home numbers, pager numbers, or even fax numbers.

Credit card data. Prized by fraudsters, credit card numbers are a high-value target.

Email addresses. Often used as a unique identiﬁer for tracking users, these have potential for both tracking a user and abuse from spam.

Date of birth/death. Either of these dates can be used to greatly narrow the search for an individual. Signiﬁcant dates of children and parents can also be considered PII.

Financial/tax records. Account balances, tax refunds, mortgage information, and even purchase history are potentially PII.

Employment information. Any data about past or present employment.

Biometric data. From the simple measurements of an individual (height and weight) to highly speciﬁc aspects of their person (ﬁngerprints, DNA, retinal scans).

National ID number. In many countries, the government issues individuals unique identiﬁcation numbers. In the United States, this is the Social Security Number. Although often for a singular purpose (e.g., taxation), the role of these numbers has expanded to become a standard common identiﬁer far exceeding the original intent.

Privacy and Liability

301

Companies can limit their liability with regard to PII in several ways, often by changing what or how information is stored. Options for reducing potential liability include the following:

Store less. The simplest way to limit potential leaks is to not have less information to leak. Collecting extra data that isn’t being used can increase user concern and irritation and aggravate the liability in the event of a breach.

Generalize. Instead of storing speciﬁc information about a person, the same value can often be reached by storing data that is less speciﬁc. For example, rather than store the date of birth, store the age as a category (over 21, for example, or between 25 and 35 years old).

Mask/obscure data. Email addresses and other highvalue PII can be stored for later comparison and lookup by using a one-way hash. This enables you to look up an account based on claims presented from the user but does not give the potential attacker information that can be used to identify the user.

Decouple PII when possible. Some information can be stored without any personally identiﬁable link. Examine data for potential places where knowing the person tied to it is not necessary.

Perform a security audit. Consult with security experts and carry out an independent security audit of all aspects of the system.

Review the privacy policy. In cooperation with legal counsel, review the policies and procedures regarding collection, retention, and usage of any PII.

Customers increasingly want to know that their PII is treated with respect and that their security and privacy are being handled appropriately. Assessing the security and privacy policies of partners and vendors is also quite important. Examining the data

A one-way hash is an encoding that cannot be reversed

302

Guidance for a Relying Party

being transmitted to other parties and ensuring that the privacy and security of customers is being maintained can also limit liability.

Summary Safety should be a high priority

Websites face increasing pressure from competition and deepening responsibilities to their customers to provide better, faster, more effective service. But they must also protect user data from harm. Using hybrid authentication, support for Information Cards can be introduced into a website today, providing users access to stronger authentication and protection from phishing, while providing a simpler, streamlined interface. Combined with taking the additional steps of reviewing and revising what data is stored, how it is collected, and under what conditions it is revealed, Information Cards will increase the security and safety for users.

Part III

Practical Considerations

Chapter 6

Identity Consumers

Chapter 7

Identity Providers

305 323

303

This page intentionally left blank

6

Identity Consumers Organizations interested in using Information Cards must ascertain for themselves the role they intend to play in the Identity Metasystem. Initially, there might be a desire to become an identity provider (IP) because at ﬁrst glance it seems as if having your own branded card is necessary for working with Information Cards. Although having a branded managed card is a beneﬁt, this beneﬁt alone does not make up for all the cost and responsibility that becoming a IP entails. Regardless of the choice to become an IP, all sites participating in the Metasystem will also ﬁll the role of relying party (RP). RPs that decide to use identities provided by other parties have many other choices to make: whose identities to accept, what information to ask for, and how to make use of it. The contractual ramiﬁcations of these RP/IP relationships and potential industry standardization may also impact many aspects of these decisions.

305

306

Identity Consumers

Common Misconceptions about Becoming an Identity Provider Many organizations won’t need to be identity providers

Managed Cards are issued with the IP’s logo

Most organizations initially believe that they will need to issue their own Managed Information Cards, for a variety of reasons. Practically speaking, many of these motivations provide little business value on their own for the cost and complexity they introduce into the system. Consider the following common, but incomplete reasons for becoming an IP:

I want to have a branded Information Card. Branding is an important feature of CardSpace, and having users exposed to a card with the company logo in their Identity Selector on a regular basis could provide a measure of brand strengthening. As an additional beneﬁt to using Managed Information Cards, it certainly can be a valuable bonus, but on its own this is a poor reason for going to the expense and complexity of introducing a Security Token Service (STS) into the system. As well, users could end up engulfed in cards—see the sidebar “Proliferation of Cards in My Wallet.”

Other sites can use my card for their sign in. Federating with other websites is a fantastic reason for issuing Managed Information Cards. However, if the organizations don’t have any identity federation or agreements with other sites in place right now, it would be prudent to discuss this with these potential partners to ensure that users would be able to use cards on other sites. You can easily understand the problem: If a company issues general-purpose credit cards, and no merchants accept them, they probably will not fare too well.

Personal Cards contain a ﬁxed number of claims.

I want more than a Personal Card. Personal Information Cards are limited in the claims they can pass to the RP. However, they allow users to manage the information that they know best—their own. Personal Cards provide

Common Misconceptions about Becoming an Identity Provider

307

a great experience for the user and gives users access to phishing-resistant identities along with strong cryptographic security. Personal Cards have been designed to ﬁt the needs of a signiﬁcant variety of sites and can be introduced into a system with much less effort.

I just want to use Managed Cards. Managed Information Cards can lend the perception that an organization is an innovator, but it is good to be sure there are additional advantages.

Managed Cards can contain any number of claims

If an organization isn’t providing the identities for use outside the conﬁnes of their own sites, and the websites that consume the identities have complete access to the identity store anyway (because they share a common database and service layer), then in some cases Managed Information Cards issued by the company aren’t providing substantial value and could increase the complexity of the system. Using a Managed Information Card can provide more than a pathway for authentication; the claims inside the token can convey the data that the RP requires—and doesn’t have access to otherwise. Like most technologies used on the Internet, an STS doesn’t require complete understanding of the underlying protocols to acquire the software, set it up, and begin using it. After an organization begins to do so, however, there is a strong implicit promise to the users to whom identities are issued that the STS will be available and that the identities may be used any time that is appropriate. Using a bank as an analogue, imagine a ﬁnancial institution that issues ATM cards that don’t meet customers’ expectations for availability or that don’t work in any other ATM machines outside of that institution. It would not be very successful. Applying that to Information Cards, IPs should be willing to provide availability of those identities any time they reasonably could be used. Downstream, too, RPs that are expecting to accept Information Cards from users will ﬁnd

An IP uses an STS to issue tokens

308

Identity Consumers

themselves quite unhappy when users are blocked from using their services because of a failure at the IP. The decision to be a Managed Card IP requires the organization to understand the technology and scenarios at a deeper level than an RP. RPs can use off-the-shelf code available to add support for accepting Information Cards to their sites; IPs have choices in technology and architecture that could ripple changes through their entire enterprises. These technology and architecture choices come with increased costs in software, hardware, and manpower, and should be weighed against the tangible business beneﬁts of the effort.

Proliferation of Cards in My Wallet I’ve noticed over the years that I accumulate cards for my wallet at an ever-increasing rate. Banks, airlines, car rentals companies, grocery stores, lenders, ﬁtness clubs, and governments all seem to have this desire to burden me with an additional piece of plastic. I can’t possibly carry all of these cards; my wallet has ﬁxed dimensions, and it can only hold so much. I’m forced to keep a stack of cards at home that I don’t use—which certainly doesn’t do the issuer any good. They went to the effort to issue, press, and mail me a pretty card with their logo and my name on it. Some organizations try to get around the wallet crunch by giving me a piece of plastic to put on my keychain…I’m running out of room there, too. As it stands, many of these cards can’t be used without an additional piece of identiﬁcation. Car rental companies won’t rent me a car without checking my driver’s license. I can’t board the airplane by showing my airline mileage card. On top of that, companies can often look up my information instantly without the card and provide me with the exact same service, regardless of whether I have in my immediate possession the card they issued to me. Fortunately Personal Cards can be reused across different websites, so it is unlikely a user will create many. The total number of Managed Cards a user has will likely have an upper limit in the number of relationships he has with entities whose business is suitable for issuing cards.

Criteria for Selecting an Identity Provider

Criteria for Selecting an Identity Provider IPs can issue Managed Cards covering a diverse set of scenarios. Each of these card proﬁles describes a scenario that can use CardSpace to achieve a different goal, yet each relies on the same protocols and technology to achieve different results. By examining the purpose for which the identity serves, an organization can better understand what types of IPs are appropriate. After understanding what type of an identity is needed, the selection criteria is narrowed by the qualiﬁcations of the IP to provide that data to the RP.

There is a wide variety of IPs

Managed Cards Proﬁles

The card metaphor, as an example of describing how an Information Card can be used, is quite valuable. Looking into the common types of cards available in a person’s wallet, it is easy to identify similar Information Cards:

Wholesale club card. Cards providing an authenticated identity, but do not necessarily offer additional claims about the individual. When doing this in real life, a cardholder presents the card at the checkout, the clerk authenticates the person by matching the photo of her face on the card with her actual face. Because the claims on the card (ﬁrst name and last name) were originally given to the issuer by the cardholder—and not necessarily veriﬁed—the card is used only to authenticate that the holder is the same person to whom the card was issued. This card can be considered cosmetic in nature, as the same purpose can be achieved by presenting a different card that conveys the same data (a driver’s license), and the clerk could simply look up the account. The tangible beneﬁt the issuers receive with this type of card is placing their corporate logos into the wallet of the holder. An Information Card in this model can be used to simply identify that the user is the same user who presented this

There are many real-life IPs

309

310

Identity Consumers

card before—much in the same way that a Personal Card does.

Governments provide identity cards that have veriﬁed claims

Auto club card. Cards providing proof of membership in a group. These organizations issue a card to their members, who can simply show the card at a merchant and receive a discount. This demonstrates a primitive form of federation, where the merchant is just giving preferential treatment to a customer who is a customer of a partner. The auto club itself uses this card for authentication for the services it provides to the cardholder in much the same way that the wholesale club card issuer does but often provides the service provider with additional claims that the merchant doesn’t receive. Information Cards used this way could operate with complete parity to their real-world counterparts, providing simple proof that the user is a customer of a partner to receive a beneﬁt.

Driver’s license or other government-issued ID. Cards that provide validated identity information to a third party. Because the government or agency that issues these identities (the department of motor vehicles) has a fairly reliable standard for validating the claims (crosschecking with birth certiﬁcates and other identiﬁcation documents), third parties can examine the claims when the card is provided and base their business decisions on them. The classic example of this is the ability to purchase alcohol being restricted to a certain age. Merchants use the driver’s license to validate that the age requirement is met, allowing the cardholder to proceed with the transaction. The merchant’s acceptance of the card is subject to the validation of the issuer. In the event the merchant suspects tampering, or the card is from an unrecognized issuer, the merchant will likely reject the transaction. With Information Cards, this process is enhanced by the use of Secure Sockets Layer (SSL) certiﬁcates to ensure the RP that the card issuer is

Criteria for Selecting an Identity Provider

who he claims to be and that the data is presented in an unaltered state.

Credit cards. Cards that permit the manipulation of an account on behalf of the user. Credit cards are presented to merchants as a method of communicating account information, where once the merchant has it, they communicate with the card issuer and perform limited transactions with the account (charges or refunds). The merchant doesn’t receive unrestricted access to the account—they can’t detail all the transactions that have occurred, and they can’t query the credit balance or perform other such transactions on behalf of the user. Although the infrastructure for these types of transactions with Information Cards isn’t in place, it would be possible to issue cards that provide access to account data via an authenticated connection.

Airline mileage cards. Many airlines issue frequent-ﬂyer cards to customers, enabling users to accumulate points for ﬂights taken, which can then be redeemed for rewards. Because not every airline can cover every territory across the globe, airlines have then done the next best thing; they have created a federation, a partnership of airlines that allows customers to accumulate points on a plan held with any one of the federated airlines when they ﬂy any other airline in the partnership. When customers achieve a certain level of points in the program, all the airlines in the federation begin to provide them with additional beneﬁts, even if a customer had never ﬂown that speciﬁc airline before. Using Information Cards, a user could obtain services from a website without having to create an account with that particular website, as long as it accepted an identity that the user held. An early experiment in identity federation was the Microsoft Passport service—see the sidebar “Freeing the ‘Hostage Identity’” in Chapter 2, “Hints Toward a Solution.”

311

312

Identity Consumers

Payment Cards—Ready for Prime Time? Perhaps the most obvious—and requested—use of Information Cards is as a secure method of performing payment transactions on the Internet. Looking at the situation from a high level, CardSpace clearly brings cryptography into the hands of users, which could provide banks, credit card companies, and other ﬁnancial institutions the infrastructure to create secure tokens that can only be viewed by the appropriate recipient. Of course, coming up with a brand new system for processing payments is not simple. CardSpace doesn’t support sending data from the RP to the IP, which is necessary to communicate information, such as transaction amounts. However, nothing prevents devising a payment solution that works with these limitations. There are already examples of such initiatives in the market.

Identity Provider Qualiﬁcations Many organizations won’t need to be an IP

As part of the decision to choose an IP, an organization should carefully review other qualiﬁcations of the IP. In some cases there will be a natural choice, due to the business constraints of the service offered by the RP. For example an immigration attorney may need to rely on tokens issued by government authorities because they are the only recognized source for the required information. Issues to consider include the reputation of the IP, the type of identities they provide, what kind of information that includes, and how they acquired that information. Customers may also view the RP in a particular light merely because of the types of identities they choose to accept. When selecting an IP that is used to provide information about an individual, an organization can understand the value a particular IP brings by asking the questions, “What does this IP know?” and “How do they know that?” Let’s look at some examples of real-world IPs:

Criteria for Selecting an Identity Provider

313

Department of motor vehicles. What does this IP know? The DMV collects data of several types. First is information that is asserted by the cardholders: their physical data (height, weight, hair color, eye color, and gender) and their current address. Second, they collect copies of some pieces of data, namely the cardholder’s date of birth and a photograph. Finally, there is data that the DMV is the authority for: what classes of vehicle the cardholder is permitted to drive, the record of driving infractions, and an optional ﬂag to be an organ donor. How do they know that? The ﬁrst category of information, that asserted by the cardholder, is not strictly veriﬁed (although it is mandated by law to be accurate and current). The second category of data often relies on another piece of identiﬁcation (birth record or passport), and as long as the DMV trusts the issuer of the original document (or that the person whose picture is being taken is legitimate), this information can be considered fairly validated. The ﬁnal category is information that the DMV collects or generates based on testing and police and court records—which an organization could consider strongly validated. Credit-reporting agencies (CRAs). What does this IP know? CRAs collect information about individuals and their credit history, along with personal information such as current and previous addresses. As well, they take that information and distill it into a standardized “score.” How do they know that? Primarily, the agencies collect this data from creditors, public records, and other reliable sources. Some of the information is generated by the agency itself when a customer grants access to a potential creditor to examine the credit record; that request becomes part of the record. Although the processes around the credit-reporting systems aren’t perfect, they are quite predictable, which allows business to rely heavily on this information.

CRAs provide data to a wide variety of relying parties

314

Identity Consumers

Retail stores share data with their suppliers

Grocery stores. What does this IP know? Grocery stores have tremendous data on the purchasing habits of shoppers: what they buy, how often they come to the store, and what brands they prefer. They combine this information with self-asserted details of the customer: income, area of residence, age group, and family composition. How do they know that? To gather demographic data about purchasing habits, grocery stores have customers sign up for loyalty cards, which customers can scan when they make purchases. In exchange for the data customers volunteer, they are granted rewards or lower prices on the goods they buy. Because no customer’s personal data is validated when they collect the card, it has little value on an individual basis. However, customers generally don’t lie about the information given—if they did, at some point the data would be useless, and likely the grocery stores would increase the validation of the cardholder’s data. The product-purchase information is very accurate, and at the very least, the stores know that a particular card was scanned when these purchases were made.

Some situations require a particular IP

Of course, in some situations, the choice for an IP is predetermined. For example, a site to manage a user’s 401(k) retirement savings account could require a token from his employer’s STS to sign in. This allows the website to ofﬂoad the authentication effort onto the companies that employ the customers.

CardSpace supports four types of authentication to the STS

A ﬁnal factor to consider when selecting an IP is their choice of authentication level. Because all Managed Cards require the user to authenticate to the STS, the IP chooses to support one or more of these: Personal Information Card, X.509 certiﬁcate (including smartcards), Kerberos tokens (from a domain controller), or just a username and password. An IP that chooses to support authentication via a smartcard, for example, is providing strong cryptographic proof about who that user is. On the other end of the spectrum, a user authenticated via username and password

Relying on an IP

315

could be someone who has acquired the credentials of the user either by deliberate sharing or by phraud. Potentially. By choosing an IP that already employs strong authentication (such as smartcards), an organization can get a higher assurance level, with less cost and effort.

Relying on an IP Shifting a business from a model where it stores all the information of a customer itself into one where it can comfortably rely on data provided by another party is a signiﬁcant paradigm shift. On one hand, an organization can enjoy the beneﬁts of having access to important data about an individual when they are interacting with that person, perhaps even pieces of data the organization never had the opportunity to have before, and with possibly greater conﬁdence. Add to that the reduced resources required and lower liability involved when not storing that information, and relying on an IP becomes very attractive. Making the business connection with the IP is the price to pay for these beneﬁts. The agreement between the IP and the RP range from casual in nature (the RP accepts identities from any IP who supports the claims required, validated or not) to a preselected IP or set of IPs that provides validated claims for a speciﬁc purpose. Reaching an agreement with the IP involves more than just terms of service. Potentially it could include the involvement (or creation) of an industry standards association or committee to standardize claims and token formats. On the other hand, in the event that the IP is using a nonauditing STS, and the content and format of the token it produces are acceptable, there might be no need for an agreement at all, provided that the terms of service of the IP are acceptable and adhered to.

An IP can opt to provide tokens to anonymous RPs

316

Identity Consumers

Beneﬁts of Using an IP

As mentioned in the sidebar “What About the Attacks in the Information-Storing Phase?” in Chapter 2, an organization can lower its potential liability by not storing data that it doesn’t need to store. A particularly compelling case for this is the use of credit history data. In some areas of the United States, potential renters of a house or apartment give their prospective landlord their Social Security Number, which the landlord uses to conduct a credit check on the individual. The landlord makes the decision to rent, in part, based on the contents of the credit report. However, the landlord often doesn’t securely dispose of the Social Security Number; instead, it sits in a ﬁle in the possession of the landlord. If the landlord loses the ﬁle physically due to theft, carelessness, or neglect, or electronically because of poor security measures, the result is the same—the attacker has secured one of the most fundamentally powerful identiﬁers that exists in the United States. Potentially, all the rest of the data in the ﬁle could be of telephone-book-quality data, but with the leak of just nine little digits, a nightmare begins for the renter, and possibly for the landlord, too. If instead, the landlord received a signed security token from a credit reporting agency, not with the Social Security Number in it—which isn’t the information the landlord really wanted anyway—but with the contents of the credit report that were necessary to make the same decision to rent the apartment or not, the landlord could avoid the liability of caring for that data. Even if the landlord’s ﬁles were stolen, they wouldn’t contain any information that leads to the renter’s identity being stolen. On top of reducing liability by storing less data, a secondary beneﬁt emerges: using fewer resources to store, back up, and secure the data. Whereas a few columns here or there in a database could hardly lead to a ﬁnancial windfall, an organization can cascade this concept throughout their entire system. Less data to manage permits a more agile system. This agility can facilitate an organization’s capacity to adapt to new business

Relying on an IP

317

challenges while balancing this against operational needs—it would still be necessary to store users’ email addresses in their proﬁles to send them a notiﬁcation when they aren’t signed in.

Quit Storing My Social Security Number! On any given day, a search of the daily news on the Internet will turn up anywhere from a few to literally dozens of articles of either a careless worker in government, education, or business losing a database with Social Security Numbers in it. Ignoring for a moment that there is apparently a disturbing lack of physical security for this type of data and that it is constantly in jeopardy, I wonder what possible legitimate purpose most of these organizations have for storing my SSN. Essentially, there are three potential uses for the SSN, outside of the government’s use for managing social security and taxation:

Credit history check. Credit agencies use the SSN as the unique identiﬁer to identify individuals. When an organization needs to perform a credit check, they get the SSN from the individual, and the individual must give his permission for the credit history check. You could argue that the agencies shouldn’t use the SSN for this purpose, but then they’d just use another unique identiﬁer for the same purpose, and that wouldn’t change anything. The fault here is that the recipient of the check nearly always retains the SSN.

Credit reporting. A creditor or service provider needs to report information back to the CRA and uses the SSN as an identiﬁer.

Common identiﬁer. Every other use of the SSN comes down to using it as a common, cross-industry identiﬁer. And every use of the SSN in this fashion just weakens my ability to protect my assets from assault by thieves intent on stealing my identity.

So, considering the level of security of all the places that contain my SSN is worrisome at best. At the very least, the simplest solution for these organizations is to store a one-way hash (a hash function takes data of any length as input and produces a ﬁxed-length output, with no way to recover the original data from

318

Identity Consumers

the output) of the information. Then, when the organization loses my data, it doesn’t contain the one thing the thief needs to access my credit: the SSN. This same technique can work for the reporting case, too. Giving the one-way hash to the agency along with my name and the data to add to the credit history would enable them to perform the same operation to ﬁnd my account and update my record. Again, there is no loss of functionality from not storing my SSN. Finally, after the original request for my credit history information, the organization should delete that value—not just to protect me individually, but to limit the liability that the organization is under by simply storing the information. Given the danger in sharing this very valuable piece of data, what is my defense? Every time I encounter an organization asking for my SSN, I leave it out. If they persist, I could give them an arbitrary value that is not my SSN—which might work well enough if I’m not granting them access to check my credit. If I am, I have little choice. Even if I am as careful as I can be, however, the solution clearly lies in organizations not storing my SSN and moving to a claims-based system for accessing my credit data.

Reaching an Agreement with the Identity Provider

When negotiating the agreement between an RP and an IP, many different metrics should be considered: service levels (uptime, responsiveness, failure contingencies), data accuracy and ownership, and privacy concerns. The content of the claims should provide the RP the data it needs, and we would be well served if the claims were standardized in the industry. Although an IP might want to deﬁne the claims and maintain control, this would lead to lock-in with that particular IP. This is unlikely to be successful in a system when other standardized choices become available.

Relying on an IP

319

The 24-hour-a-day nature of the Internet already encourages service providers to maintain exceptionally high availability. Identity providers are held to the highest standard when it comes to this; the failure to authenticate due to an ofﬂine IP could potentially prohibit millions of users from accessing sites and services that depend on them. Although Microsoft Passport is used mostly for Microsoft properties, the service handles a billion authentications a day, and going ofﬂine for an hour would see over 40 million authentication requests unanswered. It is a certainty that at least some of those users wanted to do something they believed was important.

The Internet encourages high availability

The quoted accuracy of the data the IP exposes to the RP is important to discuss. Whereas a real estate website that accepts identities from an IP that fails to validate the date-of-birth claim in their tokens is not likely to suffer, the same cannot be said for social networking sites, where there is the constant desire to keep children out of the hands of online predators. When an organization considers the importance of data accuracy, each claim must be evaluated, and both parties should agree about the level of accuracy required and the repercussions of errors in accuracy.

IPs should be clear about their claims for accuracy

In some situations, the IP, as the owner of the data they provide, declares certain data to be not stored or republished by the RP. Again, this should be handled on a claim-by-claim basis; if the RP even records the user’s name in a log, and the agreement prohibits it in a blanket fashion, the RP could unintentionally ﬁnd itself in violation of contract very quickly. Negotiating rational and acceptable levels of respect for intellectual property is critical. Privacy comes in many forms. People are always looking to keep as much of information about themselves private as possible. The IP has its own ideas about what data they want to share about their users and often spells out these terms in its privacy policy. The RP has the added burden of worrying about

320

Identity Consumers

their privacy with the IP and that of the user. These details should be agreed upon and each party be allowed to set their level of comfort with what data is shared and under what conditions. The relationship between the IP and the RP is affected by the decision of the IP about whether to require the RP to identify itself. See the section “Auditing and Nonauditing IPs” in Chapter 4, “CardSpace Implementation.”

Migration Issues When an organization has found the IP or IPs that fulﬁll its needs, the migration to the new identity model begins. Beyond the broad implementation details (which are detailed in Part II of this book), some conceptual changes are occurring and should be considered:

Proﬁles and tokens. Not all data relating to the user will be sent to the RP via the security token. Although current systems tend to allow unrestricted access to the identity store by the application—they often share a common database and service layer—some information about the user is better off left out of the token. In a scenario where an online retailer issues Managed Cards for their users, the retailer wouldn’t embed information such as the purchase history, search preferences, or shipping information selections into the token.

Maintaining a consistent user experience. If the organization is adding breadth to its user base by accepting Information Cards from providers via federation—in addition to their own—their own users would be issued Information Cards, too, and once authenticated via their own STS, all users would experience the site the same.

Changing certiﬁcates. When an IP issues security tokens,

each token is signed with the private key of the certiﬁcate that identiﬁes the IP. The RP will need to have the

Summary

certiﬁcates of the IPs whose tokens it accepts. To handle the event where an IP gets a new certiﬁcate, a communication channel should exist between the IP and RP that notiﬁes the RP of changes to the certiﬁcates. If this is not done, an IP may catch an unsuspecting RP off guard when the change occurs, and the user could be refused access accidentally.

Summary Nearly every website on the Internet deals with identities. From the simple guestbook on a one-page site to the largest commercial retailers, users are constantly prompted to provide some details to perform tasks. Although an organization’s desire to manage its users gives the website some measure of control, it might prove valuable to relinquish that control into the hands of an IP. Today’s IPs are real-world entities that are used on a daily basis, often without even thinking. Banks, governments, and businesses have successfully sewn together a system that provides the means to do business, whether that is shopping, traveling between countries, checking out a book from a library, or even boarding a bus. The real-world model that exists offers a path to accomplish the same in the online world. It’s fair to say that the right IP can assist the RP in making a smooth and reliable connection with the user; however, diligence and care should be exercised when seeking them out.

321

This page intentionally left blank

7

Identity Providers Managed Cards, unlike Personal Cards, are created by an identity provider (IP) and given to a person. The cardholder, when visiting a site and wanting to use the card, must ﬁrst authenticate himself to the IP, who creates the token with the appropriate data and passes it back to the user, who may in turn pass it to a relying party (RP). The card itself contains nothing more than the metadata of the information it represents. The card is stored on the user’s computer in an encrypted data ﬁle but can only be used to request the data from the security token service that the IP has encoded into the card. Rationalizing the decision to become an IP is more than just declaring to do so. An IP can issue cards for any purpose that it sees ﬁt, and it should do so to fulﬁll valid business requirements. Issuing the card does come with a measure of responsibility, both to the cardholder to whom it issues identities and to the RPs who would use them.

Users expect a great deal from an IP

323

324

Identity Providers

When the decision to issue cards has been made, an organization needs to make a few important architectural choices regarding card provisioning, claims, and expressing the organization’s own identity.

Uncovering the Rationale for Becoming an Identity Provider There are clear business reasons for becoming an IP

Organizations that choose to become an IP do so to fulﬁll a wide variety of different purposes. Chapter 6, “Identity Consumers,” examined IPs as a reﬂection of real-life IPs, which is helpful in selecting a provider. This section is an examination of the business reasons why an organization should choose to manage identities, regardless of whether the organization is satisfying their own needs or enlisting external RPs to accept their identities.

■ Perspective: Crossing a Trust Boundary and Assuming

Consent Customers building enterprise applications that are available only inside of a corporate network often inquire as to how they should use CardSpace in the construction of these programs. Although this type of software can leverage the same beneﬁts from claims-based programming as applications used on the Internet, they generally don’t cross a trust boundary—they are used exclusively in the same environment where users are already trusted. Generally, inside the corporate network, users have already authenticated to gain access to internal resources, and by adding an additional layer of authentication, users are just having their frustration increased. An application can still be built to validate access by getting claims from a token via a Security Token Service (STS), but that doesn’t require explicit user consent—one can assume that users have granted consent to validating their roles or memberships by logging in to the corporate domain.

Uncovering the Rationale for Becoming an Identity Provider

325

Sometimes, consent is not simply releasing information to the application, but actively deciding something—users may be asked to explicitly authorize a particular operation as an ofﬁcial of the company. Examples include authorizing the release of funds for a project, issuing a press release, or approving a new hire. Users inside a company could have several Information Cards that represent them in different capacities in their jobs. Different cards could have different levels of authentication backing them—a card used to authorize the purchase of ofﬁce supplies could sensibly be backed with a Kerberos token gained from authenticating with the domain, whereas a card that is used to authorize a billion-dollar trade may require the use of a smartcard and PIN. In this way, CardSpace enhances the business application by deﬁning the moment of consent, granting the user an understanding of the gravity of the operation. Architects are best serving their customers by asking, “What trust boundary is crossed?” and “When did the user give consent?” These types of questions often reveal insight into how to use Information Cards to interact with the user when inside an enterprise. Properly balanced, users won’t be bombarded the nextgeneration equivalent of “Are you sure?” and will instead appreciate the clarity of knowing what they have consented to and when. Early adoption of CardSpace is focusing on situations where users are crossing a trust boundary and/or when users have multiple identities within an organization and need to make an explicit choice as to which identity they want to use. This chapter generally speaks to applications where the user is crossing a trust boundary, and when referring to identities for your organization, is speciﬁcally identifying users who are not employees, but customers.

Managing Identities for Your Organization The STS that an organization uses to create security tokens effectively isolates the identity store completely from the rest of the system. Instead of the application having to access the data in the identity store, the STS creates a token containing the information the application needs and can encode that token in any format. This leads to several valuable beneﬁts that can then be taken advantage of:

The STS provides several beneﬁts to an organization’s efforts to manage identities

326

Identity Providers

Identities are passed in lightweight tokens rather than accessed through APIs. Internet applications can become increasingly complex when the code that is written to handle the business of the application is written in a way that it depends on the infrastructure around it. To change the technology that the identity store is built on, signiﬁcant changes in the business logic occur because the API (application programming interface) for one system is not the same for another. When the application uses a token created by the STS to carry the identity information, the application is no longer tightly coupled to that speciﬁc identity store or to its APIs. And, as a bonus, application developers are freed from the complexity of understanding the identity store and can use the tokens with much less effort.

Identity information may be consolidated from multiple sources. In some situations, the information that a system needs about an individual is not in one database or even hosted in the same facility. As an alternative to creating an identity store (which may involve replicating the data from other sources), an STS can accumulate the data and consolidate it all into a single token that the application can consume. The STS may even communicate outside the organization, streamlining the process for accessing external databases.

It insulates developers from complex systems. When an application’s access to identity data is abstracted out into an STS, the application developers can be freed from having to address the factors of trust, attribution, and examination of the identity information because that can be factored out and kept in the STS. The application itself need only be concerned with the business at hand.

Uncovering the Rationale for Becoming an Identity Provider

Decoupling of the systems provides options for hosting and limits exposure.

With the identity store completely decoupled from the application, an organization can make better choices in the hosting of the application. Scaling of the application may take place separately from the STS—perhaps the application needs to be replicated globally and having it connected to the identity store complicates that. Certain components may also be outsourced where appropriate, without exposing the entire system to the external organization. Finally, with the authentication and identity store no longer connected with the application, a compromise of one system need not affect the other. Managing Identities Used by Other Organizations

Historically, identity management solutions concentrated user identity information into a centralized store that can be accessed by different systems—inside the same domain. This gave administrators a single system to manage, yet users were able to access the resources they needed, without the need to duplicate their identities across the many systems. As the Internet grew, users found themselves needing to access resources outside the control of the domain they were in—and as a result, they are creating accounts on many different systems. Identity federation is the response to the challenge of managing

identities across domains, companies, and networks. Users of one domain can be granted access to resources in another domain, without duplicating accounts across systems. Active Directory Federation Services (ADFS) solves this—it enables enterprises to use Active Directory and federate identities from one domain to another across the Internet. With ADFS, the domains negotiate the details and set up their systems to share negotiated identity information.

327

328

Identity Providers

Microsoft Passport was another attempt to assist organizations in sharing identities but really only tried to federate one way: Passport expected RPs to use its identities, but there was no facility to have Passport accept identities from other parties. CardSpace introduces user-centric federation

CardSpace introduces a different model, one called user-centric federation. RPs can request a token with speciﬁc kinds of claims, and any Information Card the user has that satisﬁes those claims can be used. The RP requires no prior knowledge of the IP (however, to trust anything in the token, the RP should know the IP’s identity, such as the IP’s public key), and the IP doesn’t have to conﬁgure anything else to work with another RP. User-centric federation changes the story somewhat; instead of having the IP and the RP make all the decisions as to what identity a user uses in a particular context, it allows the user to make the choice of which identity to use. Exactly what kind of information is provided, and under what circumstances, depends entirely on the situation. Let’s look at some examples of where user-centric federation using CardSpace could be used:

Connecting to sites in partner programs. Airlines already create alliances between them where customers can use their frequent-ﬂyer accounts with other airlines in the alliance and collect points in a single account. Taking this to the next logical step, an airline website could allow a customer to sign in with an Information Card provided by any other airline in the alliance and receive all the relevant information needed to book a trip from a security token. Not only would this reduce the number of duplicate accounts created for the same user, it would also enable a signiﬁcantly accelerated login with the partners, without any aggravation to the user. Taking it a step further, when signing in to a partner site, the customer’s meal choices, seating preferences, and even whether he is eligible for a ﬂight up-

Uncovering the Rationale for Becoming an Identity Provider

grade that day could be in the token. In this type of federation, partners come together to build a formal set of claim deﬁnitions that they all support.

Making an ad hoc connection to services. When visiting different sites and services on the Internet, users are constantly bombarded with requests to authenticate—or create a new account if they don’t already have one. The majority of these websites are just looking for the bare essentials, hoping to begin a relationship with the user that encourages him to return time and time again. Using CardSpace, these websites could certainly use Personal Information Cards for sign in, but given that there is no validation of the user information, many sites insist upon at least conﬁrming the user’s email address. This causes just as much hassle for the user, and it still isn’t as quick as not requiring conﬁrmation. The solution is to be able to use a Managed Card from an organization that they already have a validated relationship with, and have the new website accept the card and allow them to use the services instantly.

Commenting on blogging sites. Blogging has certainly changed the way information is disseminated across the world. Everyone can voice his or her own opinion, regardless of where they live and what software they run. Interested in commenting on a blogger’s post? Due to the rash of comment spam, nearly every blogging site that allows comments requires users to sign in, or at the very least ﬁgure out a Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA; for more about this, see the sidebar “Perspective: Is CardSpace an Effective Tool for CAPTCHA?” in Chapter 5, “Guidance for a Relying Party”). Allowing users to use their previously validated identity to identify themselves would give bloggers what they want—proof that the commenter is a person—without having to decode garbled text.

329

330

Identity Providers

Connecting to a retirement portfolio manager. Employees with a retirement savings plan (known as a 401(k) in the United States) need to be able to interact with their portfolio management company. Because these portfolio management companies often handle thousands of companies’ employees, there is a strong desire to have the employer authenticate the employee and pass those credentials to the portfolio manager. Currently, some companies do use identity federation to allow employees to get to their accounts without authenticating to the portfolio manager again, but this lacks the capability for the user to know what data is shared between the parties and requires a great deal of effort to initially set up. A Managed Information Card provided by the employer could be used to gain access, and thus employees are always in control of their identities.

Connecting to an application a business partner provides. In many industries, employees in a company need to connect to vendor applications across the Internet. A good example of this is the natural gas market. Natural gas is piped up from wells and moved through natural gas pipelines and stations to its ﬁnal destination. A particular geographic area is usually serviced by a single pipeline company, but many gas producers have wells. The pipeline company has an application that the individual gas producers log in to and use to buy space in the pipeline to move their gas. Currently, the pipeline company creates an account for each employee that each gas producer wants to allow access to the system. This, as one would expect, is a heavily inefﬁcient

Uncovering the Rationale for Becoming an Identity Provider

331

system. In addition, with people coming and going from the gas producers all the time, the pipeline company incurs a great deal of manual work. Worse yet, although standard practice inside each of the gas producers is to disable the accounts of employees when they leave, it takes weeks often to inform the gas pipeline company. In oil/gas economy cities such as Calgary and Houston, where these gas producers are concentrated, people will move around between them all the time. Whereas their employment contracts surely prohibit them from accessing the pipeline system using their old credentials, the system doesn’t—until the pipeline company is notiﬁed. This gaping hole in security could be closed by switching to a federated identity model. Each of the gas producers could issue their employees an Information Card, and the gas producer’s STS would emit claims into the security token that the employee was able to perform certain tasks in the pipeline system on behalf of the gas producer. When that employee was no longer authorized to do that, the gas producer could simply update their own systems and not have to worry about communicating anything to the pipeline company, and the pipeline company could remove a whole layer of complexity from their application because they wouldn’t need to deal with authentication or account information any longer. Providing Claims-Based Services

When claims-based programming is used across organizations, new possibilities open up, and applications of identity information that were simply impossible years ago are now not only possible, but fairly easy to build. As we’ve touched upon earlier, claims-based programming is the capability to use claims about a subject, regardless of the source of those claims. Let’s look at some examples of where a claims-based approach could be valuable:

Claims-based programming can be used to provide or enhance several types of valuable services.

332

Identity Providers

Reputation and validated-claim services Social networking sites are drawing members by the millions and are very heavily populated by the younger generations. As they do use these sites, they might become targets of online predators. Services that offer reputation and validated claims are already beginning to appear on the Internet in an effort to provide stronger assurance for individuals. Connecting these reputation services with the social networks is proving to be difﬁcult and is happening on a purely volunteer basis. By using Information Cards and placing the validated details into claims, these reputation services can enable social networks to easily integrate strong checks into their networks.

Credit-reporting services As discussed in the section “Beneﬁts of Using an IP” in Chapter 6, a credit-reporting service that doesn’t release the individual’s Social Security Number can easily be designed. In addition to improving the security around an individual’s identity (by avoiding the unnecessary propagation of the Social Security Number), CardSpace displays the report data to the user, enabling the individual to examine the credit report before sending it to the potential creditor. In the event of a ﬂawed credit entry, the person can easily decline to send the token along to the creditor and contact the credit agency to resolve the issue.

Protecting age-restricted markets In many parts of the world, purchasing alcohol is restricted to customers of a certain age. Selling alcohol on the Internet is not a common practice, partially due to the lack of capability to validate the age of the customer—which is a bit odd, given how common alcohol sales are outside the Internet. Again, an Information Card that contains a validated age claim could easily satisfy these conditions.

Uncovering the Rationale for Becoming an Identity Provider

333

Internet Commerce

As mentioned in the sidebar “Payment Cards—Ready for Prime Time?” in Chapter 6, using CardSpace to manage payments isn’t fully supported in the current generation. (Although an implementation isn’t impossible, it would be nontrivial and require signiﬁcant testing.) That doesn’t rule out the ability of ﬁnancial institutions to use Information Cards to transmit credit card details right now. The rest of the system for processing payments wouldn’t have to change at all—just how the merchant receives the credit card information. This would provide the ﬁnancial institution the opportunity to authenticate the user before releasing the account details, cutting down on fraud. In addition, the ﬁnancial institution could give out one-time-use account numbers, eliminating the possibility of the account information leaking out after the current transaction.

Although CardSpace cannot yet manage payments directly, cards can be used to transmit credit card information and utilize the current credit card processing system

Providing Strong Authentication to Relying Parties

An IP that issues Managed Information Cards with a strong authentication factor (such as a smartcard) grants the beneﬁts of the strong authentication to the RP, without the RP having to have the resources to manage such strong authentication. Imagine a company-issued, smartcard-backed Information Card that a merchant website could accept—using the token from the company’s STS, the merchant gains the conﬁdence that the user is a legitimate representative from the company but doesn’t have to issue smartcard readers and cards to all the users accessing its system. It is worth noting that when the Managed Card ﬁle (a .crd ﬁle) is created, the card contains a user credential element, which is used to describe how the user can authenticate to the STS. In the case of cards using X.509 certiﬁcates (smartcards) or a Personal Card for authentication, the card ﬁle must have data embedded into it at creation time (some metadata that references the certiﬁcate or Personal Card), which means the credential must be available at the time the card is provisioned.

RPs can have the beneﬁts of strong authentication without having to provide the resources to manage it when they use an IP that issues Managed Information Cards based on strong authentication

334

Identity Providers

■ Perspective: Do Information Cards Demonstrate

Multifactor Authentication? Organizations can attempt to increase the security (or their conﬁdence that the users are who they say they are) by using additional authentication elements— referred to as multifactor authentication. This can range from requesting more information from the user (in hopes that the sum of the answers is something only the user will know), to requiring the user to provide proof of the possession of tamper-resistant hardware (like a smartcard), or even provide a piece of biometric data (a ﬁngerprint or retina scan). It can be argued that Information Cards can be used in a similar fashion to provide multifactor authentication, and they don’t require specialized hardware or drivers to operate. The user is given a managed Information Card (something you have), and then they are required to use that with their existing authentication (something you know or have). When providing a token using CardSpace, the user is asserting possession of the Information Card. However, it is important to understand the limits to the strength of this second factor of authentication. The .crd ﬁle can be saved on the user’s desktop without any encryption or moved from one machine to another. Furthermore, the uniqueness of a card is based on its card ID. If the possession of a card is being used as part of an authentication mechanism, card IDs must be generated in a way that makes it unpredictable and hard to guess. That said, CardSpace supports multiple factor authentication without resorting to the card itself as a factor. If a Managed Card is backed by a smartcard, and the usage of smartcard itself is constrained by a PIN, succesfully employing the card entails leveraging something you have (the smartcard) and something you know (the PIN).

What Does an Identity Provider Have to Offer? An IP has to think carefully about the information that they possess

In Chapter 6, the section “Criteria for Selecting an Identity Provider” examined the elements that an RP is looking for when selecting an IP. This section expands upon those concepts, pivoting over to the IP’s perspective.

What Does an Identity Provider Have to Offer?

Understanding Your Data

A key factor for any IP is to build around the identity information to which they have access. An IP should consider the data it has in its possession and answer a few questions:

What do I know? An IP looking to discover value in their database of users may ﬁnd several types of information can provide value. The easy ones are validated claims—data that you have previously veriﬁed in one way or another—ﬁrst and last names, email addresses, home addresses, birthdates, and so forth. However, the unique value that an IP can provide is that it certiﬁes information about the business relationship that ties it to its users. A government can certify the nationality of its citizens, a credit agency can issue claims about the credit situation of its customers, and so on.

What is the value of this information? For some claims, such as the validated email address just mentioned, it’s easy to see the value—any site accepting such a token can have a higher conﬁdence that the user is a real person, not some automated bot. Other claims, however, may not be so evident, but the IP’s relationship to the RP might help put this in perspective. As an RP, an online candy retailer might not ﬁnd much value in a user’s color selections but could certainly beneﬁt from knowing factors that will affect a purchasing decision— perhaps the user is diabetic and would be interested in sugar-free snacks. Purchasing habits, gathered over the course of years of business with a client, could also provide potential partners with a heads up as to the signiﬁcance or value of a particular customer.

How can I maximize the value of my data? Not all the data an IP knows about a user is suitable for exposure as a claim. The information might be valuable for the IP to protect, might compromise user privacy, or

335

336

Identity Providers

might not be of value to any RP. The information also might not be distilled to an easily consumable format for the RP and might be transformed to a more usable claim set before being exposed.

How will the customer feel about sharing this information? Even if an RP and an IP work out a collection of claims that would be valuable to share, the user is still in control—when users present a card, they have the opportunity to inspect the data before sending the token along to the RP. If your users are not comfortable sending along information that is of a personal or private nature and would balk at using such a card, perhaps including them is not the best use of time and resources.

Industry standardization may play a large role in the card schema, too—there could be an opportunity for a collation of IPs or partners to get together to build a common declaration of cards for their speciﬁc industry.

Both users and RPs will have strong expectations of the IP regarding the privacy and accuracy of the information it provides about them

Identity Provider Reputation As an IP, an organization builds on the strength of its own identity and begins to service two distinctive sets of customers: the users and the RPs. Yet their reputation is a fundamental quality that both customers will be sensitive to. Users typically migrate to the services they prefer, and when an IP is well respected and valued, users will follow. RPs that consume identities have a different perspective, and it is just as important—the RP has the option to accept or reject any identity, and an IP that is respected by RPs may be just as important. Common issues that all customers of the IP share include the following:

Privacy Users are very concerned about where their data is being sent, who sees it, and what it says about them. In addition, many users are also quite sensitive about what behaviors are being tracked about them and how that data

What Does an Identity Provider Have to Offer?

337

Are There Standard Claims That My Cards Must Contain? CardSpace doesn’t dictate which claims should be found in a token—to allow for uses of Information Cards that can’t be envisioned yet, the designers opted to enforce no minimum set. Each claim that appears in your card is under your direct control There is, however, a set of claims that have already gained momentum in the industry—the claims found in a Personal Card, which can be found in Chapter 3, “Windows CardSpace,” Table 3-1. Because the Personal Card claims are already deﬁned, it’s a good idea to use those claims when representing those particular elements. Choose only the claims that you ﬁnd valuable—you are not forced to include them all. If your Managed Cards are intended to uniquely identify an individual, it is recommended that you include the Private Personal Identiﬁer (PPID) claim in your Managed Card. The PPID claim enables you to deﬁne a unique, site-speciﬁc value that you can pass to the RP so that the RP can recognize the same user returning each time, regardless of the uniqueness of other claims.

is protected. Furthermore, tracking where users are using their identity, although quite valuable to the IP, is very worrisome to many users because many ﬁnd their privacy and anonymity quickly slipping away. For some additional background, see the sidebar “There Is No Such Thing as a Free Search.” RPs, on the other hand, have an interest in ﬁnding out more and more about a user. A good RP will respect the user’s desire for privacy, but after a security token has been delivered into the hands of the RP, the IP has no control over that copy of the data. RPs may also be concerned with their own privacy—is the RP being tracked? These factors affect the IP’s decision to implement an auditing or nonauditing STS.

338

Identity Providers

Reliability When users and RPs begin to rely upon the presence of Information Cards, it is critical that access to them remain available. Whereas a user blocked temporarily from accessing a service due to a failed STS would impair business continuity, a whole organization knocked ofﬂine because of the same problem could be a disaster.

Walking a Mile in the User’s Shoes CardSpace makes you aware of the data that will be sent to the IP

When the IP chooses what claims are present in a card, each of the claims in the token would ideally present a logical piece of data to which the user can relate. Because the IP dictates the format of the token (or adopts a format supported by the industry), it is possible that the data in the claims is somewhat obfuscated or collated into a few big claims stored in binary large objects (BLOBs) or Extensible Markup Language (XML) fragments. To ensure that the users are given the opportunity to inspect the value of the claims asserted about them in a meaningful way, CardSpace includes a display token—a copy of the claims in the token to be expressed in a way that is readable to the user. The display token is embedded in the RSTR (Request for a Security Token Response) along with the token intended for the RP. When the user gets the token from the IP, CardSpace uses the values in the display token to display the data to the user. Figure 7-1 shows an example. Although it is not possible to force the IP to construct the display token in such a way that guarantees that the data shown to the user is the same as the contents of the token provided to the RP, the IP should always ensure that the contents of the token are accurately represented in the display token because users are approving the release of the token to the RP based on what they can see. Failure to ensure this is a violation of the ﬁrst law (“User Control and Consent”).

Walking a Mile in the User’s Shoes

339

■ Perspective: There Is No Such Thing as a Free Search IPs are a lot like any other service provider on the Internet, except that they deal in data that is quite often very sensitive. An IP’s responsibility to protect the privacy of their customers’ data should be taken very seriously, as it’s easier to damage your reputation than it is to repair it. In the summer of 2006, a large Internet search provider released the web searches of approximately 650,000 users—every search query that the users made from March to May. As a courtesy, the company removed the names from the search and substituted in numbers instead. Looks good on the surface, right? Not so much. Within minutes of the data being posted, it was downloaded, mirrored, and shared across the Internet. To this day, a quick search will reveal cached copies of the database. The trouble—as the company found out—is that you could personally identify many individuals by what they searched for—the New York Times proved precisely that by tracking down an individual from the data. Armed with credit card numbers, Social Security Numbers, addresses, names, and a virtually an unlimited supply of contextual data, both researchers and the less-virtuous identity thieves went to work on the data, delving into the deep dark secrets of those users. Aside from the rather disturbing queries—which shocked many columnists and spurred a web contest to ﬁnd the scariest search—users began to fear the power search engines hold. How can a user trust these companies with the sheer magnitude of data they control? A quick tapping on a keyboard in an ofﬁce somewhere in Silicon Valley, and suddenly every search you ever performed is released to the world. That wasn’t part of the deal! The trick is that the privacy policy only tells us what the company is promising, not necessarily what they will do. Letting the cat out of the bag turns out to be a whole lot easier than putting it back in. Once released, this data is virtually indestructible—copies can be made in seconds, and the only recourse the customer has is through the courts. Customers vote with their pocketbooks and may seek out your competitor if they feel their privacy is at risk.

340

Identity Providers

Figure 7-1 user.

CardSpace shows the contents of the display token to the

Roaming with Information Cards

A signiﬁcant percentage of users use more than one computer— often one at work and another at home. While a user can import the same Managed Information Card on multiple computers and use it in multiple places, there is one side effect when doing so: a Managed Information Card that is used with a nonauditing STS (where the IP doesn’t request the identity of the RP). CardSpace generates a new master key for that card when it is imported. The master key is used to generate a unique identiﬁer (per the RP site) that can be passed to the RP, so that the RP identiﬁes a return visitor. Because the master key is generated at import time, each computer passes a different unique identiﬁer to the RP, making the RP believe the user is not the same as one using the same card imported on another computer. To allow users to

An Organization’s Identity

341

roam, CardSpace enables them to export their cards (Personal and Managed Cards) to a PIN-protected archive (a CRDS ﬁle), which they can then copy to another computer and import into CardSpace and have the cards work the same as on the original computer.

An Organization’s Identity As an IP, an organization must maintain their identity, too. The identity of the IP is asserted by the details in the SSL certiﬁcate that is used to sign the tokens generated by the STS. In a standard SSL certiﬁcate, usually only ownership of the site domain is checked; other information, such as company name and location, is not veriﬁed by the Certiﬁcate Authority (CA). In 2007, the CAs began to provide Extended Validation (EV) SSL certiﬁcates, which are issued to organizations that meet certain criteria for proving their identity to the CA, including veriﬁcation of the physical ofﬁce where the organization can be reached. These certiﬁcates come at a premium price. Because the CA is providing veriﬁed information about the IP in the certiﬁcate, the RP should use the validated ﬁelds to track the identity of the IP. In an EV certiﬁcate, the subject name contains OLSC ﬁelds— Organization, Location, State, and Country. Relying on these ﬁelds to recognize the certiﬁcate allows the organization to renew or replace the EV SSL certiﬁcate with one from any CA, without having to explicitly notify the RPs. The IP also has the opportunity to express their identity (and provide brand recognition) by embedding an image into the Managed Card, which is displayed in the CardSpace Identity Selector. Figure 7-2 shows an example of a branded Managed Card.

The certiﬁcate path is the chain of certiﬁcates back to the root

342

Identity Providers

Figure 7-2

Importing a Managed Card branded with a corporate logo

Summary The role of the identity provider is pivotal for the entire Identity Metasystem model. Many businesses and authorities are suitable to expand their online operations and become identity providers. In this chapter we enumerated some of the considerations and requirements that should be taken into account while planning an IP.

Index A accepting Managed Cards at websites, 244-246 Personal Cards at websites, 243-244 Access Denied errors, 236 accessibility, 283 accounts associating Information Cards with, 288 creating, 288-291 maintenance, 297 recovering, 291-293 Active Directory Federation Services (ADFS), 327 ad hoc connections to services, 329 addresses MEX addresses, 201 WS-Addressing, 144 ADFS (Active Directory Federation Services), 327 age-restricted markets, 332 airline mileage cards, 311 algorithms, asymmetric key, 39-41 applications, connecting to, 330 AreCardsSupported() function, 279-282

Argument Error, 236 asset virtualization, 10-16 associating Information Cards with accounts, 288 assuming consent, 324-325 asymmetric key algorithms, 39-41 attacks brute-force attacks, 39 information-entering phase, 17-20 information-processing phase, 24-26 information-storing phase, 24-26, 131 information-transfer phase, 21-24 man-in-the-middle attacks, 22-24 phishing CardSpace and, 180 deﬁnition, 18 growth of, 19-20 step-by-step process, 18-19 targeted phishing, 19 SQL injection, 26 AudienceRestrictionCondition (SAML), 241, 246-247 auditing IPs, 246-247

authentication alternative security measures, 293-294 authentication levels (IPs), 314-315 brokered trust, 134-136, 161 canonical scenario, 132-134, 159-161 CardSpace AreCardsSupported() function, 279-283 CardsNotSupported class, 281-282 CardsSupported class, 281-282 Don’t Have Your Card? link, 283 overview, 277-278 Remember Me Next Time check box, 283 Sign In with Your Information Card button, 283 training users to look for Information Card sign-in, 285 What Is This? link, 283

343

344

Index

certiﬁcate-based client authentication corporate smartcards and intranet certiﬁcates, 60-62 eIDs (electronic IDs), 65-69 overview, 60 SSL (secure sockets layer), 62-65 challenges of transporting credentials, 79-84 extended authentication, 272 HTTPS, 52-57 hybrid authentication, 275 issued token-based authentication deﬁnition, 70 Kerberos, 72-76 overview, 69-71 SAML (Security Assertion Markup Language), 76-79 Managed Cards, 197-198 multifactor authentication, 334 overview, 57-59 password authentication, 31, 289 providing strong authentication to RPs, 333 server authentication challenges, 35-36 overview, 38 simple authentication, 272 AuthenticationContext WCF object, 260 authorization. See authentication auto club cards, 310

B Baker, Caleb, biographical information, xxvii-xxviii Bertocci, Vittorio, biographical information, xxvi-xxvii binding types wsFederationHttpBinding binding type, 257 wsHttpBinding binding type, 256 blind credentials, 10, 31

blogs commenting on, 329 identityblog.com, 92 branded Managed Cards, 341 brokered trust, 134-136, 161 brokering trusted interactions, 181-184 browser extension (Information Card) HTML syntax, 226 issuer property, 228-229 IssuerPolicy property, 229 OptionalClaims property, 230 overview, 224-225 PrivacyUrl property, 231 PrivacyVersion property, 231 RequiredClaims property, 229-230 TokenType property, 230-231 within Web forms, 227-228 XHTML syntax, 227 browser tokens, getting from CardSpace, 267 browsers, 162 brute-force attacks, 39 business reasons for becoming IPs Internet commerce, 333 managing identities for your organization, 325-327 managing identities used by other organizations, 327-331 providing claims-based services, 331-332 providing strong authentication to RPs, 333 buttons, Sign In with Your Information Card, 283

C calculating site-speciﬁc card IDs, 195 calling CardSpace from WCF (Windows Communication Foundation), 256-258 Cameron, Kim, 92-93. See also seven laws of identity

canonical scenario (authentication), 132-134, 159-161 CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), 273 Card Security Code (CSC), 293 CardsNotSupported class, 281-282 CardSpace implementation account maintenance, 297 advantages brokered trusted interactions, 181-184 consistent user experience, 177-181 overview, 177 associating Information Cards with accounts, 288 authentication accessibility, 283 AreCardsSupported() function, 279-282 CardsNotSupported class, 281-282 CardsSupported class, 281-282 Don’t Have Your Card? link, 283 overview, 277-278 Remember Me Next Time check box, 283 Sign In with Your Information Card button, 283 What Is This? link, 283 CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), 273 certiﬁcates, 192 creating accounts, 288-291 database changes, 276-277 deployment scenarios. See deployment scenarios (CardSpace) Disable CardSpace option, 204-207 disabling, 206-207 Firefox, 177

Index handling unknown cards, 286-287 HTTPS login page, 173 Information Cards. See Information Cards limitations, 205 Managed Card Import page, 204, 208-209 management tasks creating and editing Personal Cards, 212-214 Management mode, 211 moving cards between computers, 214-215, 218 overview, 210 .NET Framework 3.5, 218-220 overview, 161-164, 169, 274 passive user notiﬁcation, 296-297 phishing and, 180 preparation, 275-276 private desktop, 204-206 prompting users for Information Cards, 294-295 recovering accounts, 291-293 Relying Party Identiﬁcation page, 204, 207-208 server synchronization, 275 sign-in process, 285-286 supported applications, 175 system requirements, 176 training users to look for Information Card sign-in, 285 walkthroughs, 169 from user’s perspective, 170-172 from web developer’s perspective, 173-175 CardsSupported class, 281-282 CAs (certiﬁcation authorities), 44 Cascading Style Sheets, 281-282 certiﬁcate-based client authentication corporate smartcards and intranet certiﬁcates, 60-62 digital certiﬁcates deﬁnition, 45 Extended Validation (EV) SSL certiﬁcates, 209, 271, 276, 341

intranet certiﬁcates, 60-62 migration issues, 320 root certiﬁcates, 45 soft certiﬁcates, 62 X.509 certiﬁcates, 45, 192, 197 eIDs (electronic IDs), 65-69 overview, 60 SSL (secure sockets layer), 62-65 certiﬁcation authorities (CAs), 44 character mapping table, 195 ciphertext, 39 claim transformers, 126-129, 158 claims claim-based identities, 124, 157 claim-based programming, 272 claim-based services, providing, 331-332 deﬁnition, 114 Managed Cards, 202-203 WCF (Windows Communication Foundation), 260-261 classes CardsNotSupported, 281-282 CardsSupported, 281-282 client authentication. See authentication commenting on blogging sites, 329 Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA), 273 consent assuming, 324-325 user control and consent, 94-96 consistent experience across contexts CardSpace, 177-181 law of identity, 108-110, 129-130 consumers. See RPs (relying parties) contexts, consistent experience across (law of identity), 108-110, 119, 129-130

345

control, user control and consent, 94-96 corporate smartcards, 60-62 crackers goals of, 6 overview, 5 script kiddies, 8 CRAs (credit-reporting agencies), 313, 317, 332 creating accounts, 288-291 credentials blind credentials, 10, 31 transporting, 79-84 credit cards, 293-294, 311 credit histories, 28-29, 317 credit-reporting agencies (CRAs), 313, 317, 332 crime. See cybercrime crossing trust boundaries, 324-325 cryptography ciphertext, 39 deﬁnition, 36 digital signatures, 42-44 encryption deﬁnition, 36 public key encryption, 39-41 symmetric encryption, 38-39 HTTP (HyperText Transfer Protocol), 47-49 HTTPS authentication and digital identity, 52-57 overview, 49-52 identity propagation, 37 keys asymmetric key algorithms, 39-41 deﬁnition, 36 private keys, 41 PKI (Public Key Infrastructure), 44-45 public keys, 41 overview, 36-38, 271 plaintext, 39 public key cryptography, 39-41

346

Index

server authentication, 38 symmetrical key cryptography, 38-39 CSC (Card Security Code), 293 CSS (Cascading Style Sheets), 281-282 cybercrime brute-force attacks, 39 crackers, 5-6 identity crime, 16 identity theft credit histories, 28-29 deﬁnition, 16 dumpster divers, 29 The Identity Theft Protection Guide, 29 information-entering phase, 17-20 information-processing phase, 24-26 information-storing phase, 24-26, 131 information-transfer phase, 21-24 man-in-the-middle attacks, 22-24 Social Security Numbers, 28 law enforcement, 8 malware, 16-17 overview, 4-5 phishing deﬁnition, 18 growth of, 19-20 step-by-step process, 18-19 targeted phishing, 19 piracy, 5 script kiddies, 8 spam, 14 SQL injection, 26 Trojan horses, 8 value of information available online, 10-16 viruses, 7-9 worms deﬁnition, 7 ILOVEYOU, 7-8 importance of, 9 motivation behind worm creation, 9

D databases, modifying to support Information Cards, 276-277, 335-336 decoupling, 113 decrypting tokens WCF (Windows Communication Foundation), 258-259 in websites, 238 department of motor vehicles (DMV), 313 deployment scenarios (CardSpace) federation, 248-251 multiplayer games getting browser tokens from CardSpace, 267 getting CardSpace tokens, 264-267 importing CardSpace ﬁles, 264 opening CardSpace, 264 overview, 262-263 WCF (Windows Communication Foundation) adding CardSpace to, 255-256 calling CardSpace from, 256-258 claims processing, 260-261 overview, 252-255 policy options, 261-262 token decryption, 258-259 token veriﬁcation, 260 websites auditing and nonauditing IPs, 246-247 dynamically setting site requirements, 232 Information Card browser extension, 224-231 logon process, 224 Managed Cards, accepting, 244-246 Personal Cards, accepting, 243-244 scripts, 232-243

digital certiﬁcates certiﬁcate-based client authentication corporate smartcards and intranet certiﬁcates, 60-62 eIDs (electronic IDs), 65-69 overview, 60 SSL (secure sockets layer), 62-65 deﬁnition, 45 EV (Extended Validation) certiﬁcate, 209, 271, 276, 341 intranet certiﬁcates, 60-62 migration issues, 320 root certiﬁcates, 45 soft certiﬁcates, 62 X.509 certiﬁcates, 45, 192, 197 digital crime. See cybercrime digital identity, 114-115 digital signatures, 42-44 DigitalMe Identity Selector, 178 directed identity (law of identity), 102-104 Disable CardSpace option (CardSpace), 204-207 disabling CardSpace, 206-207 disclosure, minimal disclosure for constrained use, 96-98 display credential hint (Managed Cards), 201 display tokens, 338 DMV (department of motor vehicles), 313 Don’t Have Your Card? link, 283 dotcom bubble, 12 driver’s license cards, 310 dumpster divers, 29 dynamically setting site requirements, 232

E e-commerce, 12, 333 early adopters, 270-271 early majority consumers, 270 editing Personal Cards, 212, 214 eGovernment, 90 eIDs (electronic IDs), 65-69

Index email increasing prevalence of, 12 phishing deﬁnition, 18 growth of, 19-20 overview, 18 step-by-step process, 18-19 targeted phishing, 19 spam, 14 encapsulating protocol (Identity Metasystem), 126, 158 encryption. See cryptography EncryptionAlgorithm policy option, 262 encryptWith policy option, 262 endpoint reference (Managed Cards), 200-201 error handling Access Denied error, 236 Argument Error, 236 Identity Validation error, 235 Not Installed error, 235 overview, 233-234 Policy Error, 236 Service Busy error, 235 Service Failure error, 235 Trust Exchange error, 236 Unsupported Error, 237 Untrusted Recipient error, 236 User Cancelled error, 235 EV (Extended Validation) SSL certiﬁcates, 209, 271, 276, 341 Event Viewer, 237 extended authentication, 272 Extensible Markup Language (XML), 141-142

F federations ADFS (Active Directory Federation Services), 327 airlines, 311 deployments, 248-251 overview, 273 user-centric federation, 328 WS-Federation, 154-156, 162 Firefox, 177 forms, 227-228, 272

four tenets of service orientation, 94 freeing hostage identity, 121-122 functions. See speciﬁc functions

G games, deploying CardSpace in getting browser tokens from CardSpace, 267 getting CardSpace tokens, 264-267 importing CardSpace ﬁles, 264 opening CardSpace, 264 overview, 262-263 GetBrowserToken() method, 177, 267 GetToken() method, 264-267 government-issued ID cards, 310 grocery stores, 314

H handling unknown cards, 286-287 handshake (SSL), 62-63 hard tokens, 65-69 hostage identity, 121-122 HTML Information Card browser extension, 226 HTTP (HyperText Transfer Protocol), 89 cryptography, 47-49 HTTPS authentication and digital identity, 52-57 CardSpace login page, 173 overview, 49-52 human integration (law of identity), 105-107 hybrid authentication, 275 HyperText Transfer Protocol. See HTTP

I IBalance interface, 253 identity claim-based identities, 124, 157 digital identity, 114-115 hostage identity, 121-122

347

metasystem. See Identity Metasystem omnidirectional identity, 102 seven laws of identity consistent experience across contexts, 108-110, 129-130 directed identity, 102-104 human integration, 105-107 justiﬁable parties, 98-101 minimal disclosure for constrained use, 96-98 overview, 92-93 pluralism of operators and technologies, 104-105 similarity to four tenets of service orientation, 94 user control and consent, 94-96 unidirectional identity, 102 identity consumers. See also RPs (relying parties) deﬁnition, 271 early adopters, 270-271 early majority consumers, 270 innovators, 270-271 laggards, 271 late majority consumers, 271 identity contexts, 119 identity crime, 16 identity federations. See federations Identity Metasystem authentication scenarios brokered trust, 134-136, 161 canonical scenario, 132-134, 159-161 claims, 114 components claim transformers, 126-129, 158 claim-based identities, 124, 157 consistent user experience, 129-130 encapsulating protocol, 126, 158

348

Index

negotiation, 124-126, 157-158 overview, 122-123 as WS-* features, 156-157 decoupling, 113 digital identity, 114-115 identity contexts, 119 overview, 110-114 roles IPs (identity providers), 118-121 overview, 116-117 RPs (relying parties), 117 subjects, 117-118 trust, 115-116 WS-* implementation brokered trust, 161 canonical scenario, 159-161 identity propagation, 37 identity providers. See IPs identity theft attacks in information-entering phase, 17-20 attacks in informationprocessing phase, 24-26 attacks in information-storing phase, 24-26, 131 attacks in information-transfer phase, 21-24 credit histories, 28-29 deﬁnition, 16 dumpster divers, 29 The Identity Theft Protection Guide, 29 man-in-the-middle attacks, 22-24 phishing deﬁnition, 18 growth of, 19-20 step-by-step process, 18-19 targeted phishing, 19 Social Security Numbers, 28 SQL injection, 26 The Identity Theft Protection Guide, 29 Identity Validation errors, 235 identityblog.com, 92

IDs IssuerIDs, 277 PPIDs (private personal identiﬁers), 190-194, 277 SSIDs (site-speciﬁc IDs), 195, 298-299 UniqueIDs, 277 UserIDs, 277 ILOVEYOU worm, 7-8 implementations. See deployment scenarios (CardSpace) ImportInformationCard() function, 264 importing CardSpace ﬁles, 264 Information Cards advantages, 178-181 associating with accounts, 288 browser extension HTML syntax, 226 issuer property, 228-229 IssuerPolicy property, 229 OptionalClaims property, 230 overview, 224-225 PrivacyUrl property, 231 PrivacyVersion property, 231 RequiredClaims property, 229-230 TokenType property, 230-231 within Web forms, 227-228 XHTML syntax, 227 contents, 185-187 deﬁnition, 184 Managed Cards accepting at websites, 244-246 airline mileage cards, 311 authentication, 197-198 auto club cards, 310 branded Managed Cards, 341 card ID, 199 card image, 200 card name, 200 claims, 202-203 credit cards, 311

deﬁnition, 188, 196 driver’s license or government-issued ID cards, 310 endpoint reference, 200-201 issuer, 200 obtaining, 196 payment cards, 312 privacy policy, 200 supported claim type list, 202 supported token type list, 202 time expires, 200 time issued, 200 user credential element, 201-202, 333 username and password authentication, 198 version, 199 when to use, 203 wholesale club cards, 309 metadata, 185, 187 moving between computers, 214-215, 218 multifactor authentication, 334 .NET Framework 3.5, 218-220 number of, 308 object tag, 174 Personal Cards accepting at websites, 243-244 advantages, 189-190 claims supported by, 188-190 creating and editing, 212-214 deﬁnition, 187 PPIDs (private personal identiﬁers), 190-194, 337 when to use, 194 prompting users for, 294-295 roaming with, 340-341 selecting, 186 site-speciﬁc card IDs, 195 supporting multiple platforms/technologies, 270

Index supporting with CardSpace. See CardSpace implementation unknown cards, handling, 286-287 website logon process, 224 information-entering phase, 17-20 information-processing phase, 24-26 information-storing phase, 24-26, 131 information-transfer phase, 21-24 innovators, 270-271 integrity of digital signatures, 44 integrity check (tokens), 238, 241 interfaces, IBalance, 253 Internet commerce, 333 lack of center, 91 lack of identity layer, 90-91 overview, 89-90 user acceptance of online services, 91 value of information available online, 10-16 intranet certiﬁcates, 60-62 IPs (identity providers), 305 auditing IPs, 246-247 authentication levels, 314-315 beneﬁts of using, 316-317 branded Managed Cards, 341 business reasons for becoming IPs Internet commerce, 333 managing identities for your organization, 325-327 managing identities used by other organizations, 327-331 providing claims-based services, 331-332 providing strong authentication to RPs, 333 databases, 335-336 deﬁnition, 118-119 display tokens, 338

Extended Validation (EV) SSL certiﬁcates, 209, 271, 276, 341 migration issues, 320-321 misconceptions about becoming an IP, 306-308 negotiating agreements with, 318-320 nonauditing IPs, 246-247 overview, 119-121, 323-324 qualiﬁcations CRAs (credit-reporting agencies), 313 DMV (department of motor vehicles), 313 grocery stores, 314 overview, 312 reliability, 338 relying on, 315 reputations, 336-339 responsibility to protect privacy, 336, 339 selection criteria airline mileage cards, 311 auto club cards, 310 credit cards, 311 driver’s license or government-issued ID cards, 310 overview, 309 payment cards, 312 wholesale club cards, 309 issued token-based authentication deﬁnition, 70 Kerberos, 72-76 authentication process, 72-74 principals, 72 TGS (ticket granting service), 73-74 tickets, 72 overview, 69-71 SAML (Security Assertion Markup Language), 76-79 issuer property (Information Card browser extension), 228-229

349

IssuerIDs, 277 IssuerPolicy property (Information Card browser extension), 229

J-K justiﬁable parties (law of identity), 98-101 Kerberos, 72-76, 197 authentication process, 72-74 principals, 72 TGS (ticket granting service), 73-74 tickets, 72 V5 credential (Managed Cards), 201 keyloggers, 17 keys asymmetric key algorithms, 39-41 deﬁnition, 36 PKI (Public Key Infrastructure) CAs (certiﬁcation authorities), 44 deﬁnition, 44 digital certiﬁcates, 45 private keys, 41 public key cryptography, 39-41 public keys, 41 keySize policy option, 262 keystrokes, recording, 17 KeyType policy option, 262

L laggards, 271 late majority consumers, 271 law enforcement, 8 laws of identity consistent experience across contexts, 108-110, 129-130 directed identity, 102-104 human integration, 105-107 justiﬁable parties, 98-101 minimal disclosure for constrained use, 96-98 overview, 92-93

350

Index

pluralism of operators and technologies, 104-105 similarity to four tenets of service orientation, 94 user control and consent, 94-96 liability for PII (personally identiﬁable information), 301-302 login page (CardSpace), 173 logon process (websites), 224 LOVE-LETTER-FORYOU.TXT.vbs email attachment, 8 Luhn formula, 293

M maintaining accounts, 297 malware deﬁnition, 16-17 keyloggers, 17 man-in-the-middle attacks, 22-24 Manage() function, 264 ManageCardSpace() function, 264 Managed Card Import page (CardSpace), 204, 208-209 Managed Cards accepting at websites, 244-246 airline mileage cards, 311 authentication, 197-198 auto club cards, 310 branded Managed Cards, 341 card ID, 199 card image, 200 card name, 200 claims, 202-203 credit cards, 311 deﬁnition, 188, 196 driver’s license or government-issued ID cards, 310 endpoint reference, 200-201 issuer, 200 obtaining, 196 payment cards, 312 privacy policy, 200

supported claim type list, 202 supported token type list, 202 time expires, 200 time issued, 200 user credential element, 201-202, 333 username and password authentication, 198 version, 199 when to use, 203 wholesale club cards, 309 managed-code applications, 175 Management mode option (CardSpace), 211 management tasks (CardSpace) creating and editing Personal Cards, 212-214 Management mode, 211 moving cards between computers, 214-215, 218 overview, 210 managing identities for your organization, 325-327 identities used by other organizations, 327-331 metadata Information Cards, 185-187 WS-MetadataExchange, 154 metasystem. See Identity Metasystem methods. See speciﬁc methods MEX addresses, 201 Microsoft Passport, 328 migration issues, 320-321 minimal disclosure for constrained use (law of identity), 96-98 moving cards between computers, 214-215, 218 multifactor authentication, 334 multiplayer games, deploying CardSpace in getting browsers tokens from CardSpace, 267 getting CardSpace tokens, 264-267 importing CardSpace ﬁles, 264 opening CardSpace, 264 overview, 262-263

N native-code applications, 175 natural gas market, 330 negotiation deﬁnition, 124-126 IP agreements, 318-320 WS-* speciﬁcations, 157-158 .NET Framework 3.5, 218-220 nonauditing IPs, 246-247 nonauditing STS (Security Token Service), 340 nonrepudiation, 43 Not Installed errors, 235

O OASIS token proﬁles, 148 object tag, 174 objects, AuthenticationContext, 260 obscurity, security by, 38 OLSC (Organization, Location, State, and Country) ﬁelds, 341 omnidirectional identity, 102 Open-Source Identity System (OSIS) site, 178 opening CardSpace, 264 operators, pluralism of (law of identity), 104-105 Opinity, 102 OptionalClaims property (Information Card browser extension), 230 Organization, Location, State, and Country (OLSC) ﬁelds, 341 OSIS (Open-Source Identity System) site, 178

P parties, justiﬁable (law of identity), 98-101 passive requestor case, 155 passive user notiﬁcation, 296-297 Passport (Microsoft), 328 passwords, 289 advantages, 29-33 disadvantages, 33-36 Managed Cards, 198

Index overview, 29 password authentication, 31 password authorization, 31 password fatigue, 34 remembering, 32 reuse of, 34 payment cards, 312 Personal Cards accepting at websites, 243-244 advantages, 189-190 claims supported by, 188-190 creating and editing, 212-214 deﬁnition, 187 moving between computers, 214-215, 218 .NET Framework 3.5, 218-220 number of, 308 PPIDs (private personal identiﬁers), 190-194, 337 when to use, 194 personally identiﬁable information. See PII phishing CardSpace and, 180 deﬁnition, 18 growth of, 19-20 overview, 18 step-by-step process, 18-19 targeted phishing, 19 PII (personally identiﬁable information) deﬁnition, 299-300 reducing liability for, 301-302 piracy, 5 PKI (Public Key Infrastructure) CAs (certiﬁcation authorities), 44 deﬁnition, 44 digital certiﬁcates, 45 plaintext, 39 pluralism of operators and technologies (law of identity), 104-105 policies Policy Error, 236 WCF (Windows Communication Foundation), 261-262 WS-Policy, 144-145

PPIDs (private personal identiﬁers), 190-194, 277, 337 preparing for CardSpace implementation, 275-276 principals (Kerberos), 72 principles of identity. See laws of identity privacy awareness of, 272 PII (personally identiﬁable information) deﬁnition, 299-300 reducing liability for, 301-302 responsibility of IPs to protect, 336, 339 PrivacyUrl property (Information Card browser extension), 231 PrivacyVersion property (Information Card browser extension), 231 private desktop (CardSpace), 204-206 private keys, 41 private personal identiﬁers (PPIDs), 190-194, 277, 337 processing claims (WCF), 260-261 processing tokens decryption, 2380240 integrity check, 238, 241 retrieval of claim values, 238, 242-243 validation, 238, 241-242 proﬁles migration issues, 320 token proﬁles, 148 prompting users for Information Cards, 294-295 properties of Information Card browser extension issuer, 228-229 IssuerPolicy, 229 OptionalClaims, 230 PrivacyUrl, 231 PrivacyVersion, 231 RequiredClaims, 229-230 TokenType, 230-231

351

protocols HTTP (HyperText Transfer Protocol), 47-49, 89 HTTPS authentication and digital identity, 52-57 CardSpace login page, 173 overview, 49-52 Identity Metasystem encapsulating protocol, 126, 158 Kerberos, 72-76 authentication process, 72-74 principals, 72 TGS (ticket granting service), 73-74 tickets, 72 SAML (Security Assertion Markup Language), 76-79, 95, 153 SOAP (Simple Object Access Protocol), 142-143 SSL (secure sockets layer), 62-65 TCP/IP, 113 Wi-Fi, 113 WSDL (Web Services Description Language), 144 providing claims-based services, 331-332 public key cryptography, 39-41 Public Key Infrastructure. See PKI public keys, 41

R R-STS (Resource STS), 249-251 reasonable, deﬁnition of, 106 recording keystrokes, 17 recovering accounts, 291-293 reliability (IPs), 338 relying on IPs (identity providers), 315 beneﬁts of using IPs, 316-317 migration issues, 320-321 negotiating agreements, 318-320 relying parties. See RPs

352

Index

Relying Party Identiﬁcation page (CardSpace), 204, 207-208 Remember Me Next Time check box, 283 remembering passwords, 32 reputations of IPs (identity providers), 336-339 Request for Security Token (RST), 150 RequiredClaims property (Information Card browser extension), 229-230 Resource STS (R-STS), 249, 251 responsibility of IPs (identity providers) to protect privacy, 336, 339 retirement portfolio managers, connecting to, 330 retrieval of claim values (tokens), 238, 242-243 reuse of passwords, 34 rich applications, 175 roaming with Information Cards, 340-341 root certiﬁcates, 45 RPs (relying parties) advantages of becoming, 270-273 deﬁnition, 117 misconceptions about becoming an IP (identity provider), 306-308 overview, 269, 305 relying on IPs (identity providers), 315 beneﬁts of using IPs, 316-317 migration issues, 320-321 negotiating agreements, 318-320 selection of IPs (identity providers) airline mileage cards, 311 authentication levels, 314-315 auto club cards, 310 credit cards, 311 driver’s license or government-issued ID cards, 310

grocery stores, 314 IP qualiﬁcations, 312-313 overview, 309 payment cards, 312 wholesale club cards, 309 RST (Request for Security Token), 150

S SAML (Security Assertion Markup Language), 76-79, 95, 153 script kiddies, 8 scripting CardSpace error handling Access Denied error, 236 Argument Error, 236 Identity Validation error, 235 Not Installed error, 235 overview, 233-234 Policy Error, 236 Service Busy error, 235 Service Failure error, 235 Trust Exchange error, 236 Unsupported Error, 237 Untrusted Recipient error, 236 User Cancelled error, 235 retrieval of claim values, 238, 242-243 sample script, 232 token decryption, 238, 240 token integrity check, 238, 241 token validation, 238, 241-242 secure sockets layer. See SSL Security Assertion Markup Language (SAML), 76-79, 95, 153 security by obscurity, 38 Security Token Service (STS), 324 beneﬁts, 325-327 nonauditing STS, 340 selection of IPs (identity providers) airline mileage cards, 311 authentication levels, 314-315 auto club cards, 310 credit cards, 311

driver’s license or governmentissued ID cards, 310 IP qualiﬁcations CRAs (credit-reporting agencies), 313 DMV (department of motor vehicles), 313 grocery stores, 314 overview, 312 overview, 309 payment cards, 312 wholesale club cards, 309 self-issued credential (Managed Cards), 202 Serack, Garrett, biographical information, xxvii server authentication challenges, 35-36 overview, 38 servers, synchronizing, 275 service behaviors, 259 Service Busy errors, 235 Service Failure errors, 235 service orientation, four tenets of, 94 services, web. See web services seven laws of identity consistent experience across contexts, 108-110, 129-130 directed identity, 102-104 human integration, 105-107 justiﬁable parties, 98-101 minimal disclosure for constrained use, 96-98 overview, 92-93 pluralism of operators and technologies, 104-105 similarity to four tenets of service orientation, 94 user control and consent, 94-96 Sign In with Your Information Card button, 283 sign-in process (CardSpace), 285-286 signatures, digital, 42-44 signWith policy option, 262 simple authentication, 272 Simple Object Access Protocol (SOAP), 142-143

Index single sign on (SSO), 77-78 site-speciﬁc IDs (SSIDs), 195, 298-299 smartcards, 60-62 sniffers, 23 SOAP (Simple Object Access Protocol), 142-143 social-networking sites, 332 Social Security Numbers (SSNs), 28, 98, 317-318 soft certiﬁcates, 62 spam, 14. See also phishing SQL injection, 26 SSIDs (site-speciﬁc IDs), 195, 298-299 SSL (secure sockets layer) client authentication, 62-65 EV (Extended Validation) SSL certiﬁcates, 209, 271, 276, 341 SSNs (Social Security Numbers), 28, 98, 317-318 SSO (single sign on), 77-78 STS (Security Token Service), 324 beneﬁts, 325-327 nonauditing STS, 340 style sheets, 281-282 subjects, 117-118 supported claim type list (Managed Cards), 202 supported token type list (Managed Cards), 202 symmetrical key cryptography, 38-39 synchronizing servers, 275 system requirements (CardSpace), 176

T tags, 174 TCP/IP, 113 TGS (ticket granting service), 73-74 thumbprints, 43 ticket granting service (TGS), 73-74 tickets (Kerberos), 72 time expires (Managed Cards), 200 time issued (Managed Cards), 200

TokenProcessor page (CardSpace), 174-175 tokens browser tokens, getting from CardSpace, 267 CardSpace Token Processor page, 174-175 decryption, 240 WCF (Windows Communication Foundation), 258-259 in websites, 238 display tokens, 338 hard tokens, 65-69 integrity check, 238, 241 issued token-based authentication deﬁnition, 70 Kerberos, 72-76 overview, 69-71 SAML (Security Assertion Markup Language), 76-79 migration issues, 320 requesting in multiplayer games, 264-267 retrieval of claim values, 238, 242-243 RST (Request for Security Token), 150 token proﬁles, 148 validation WCF (Windows Communication Foundation), 260 in websites, 238, 241-242 TokenType property (Information Card browser extension), 230-231 training users to look for Information Card sign-in, 285 transporting credentials, 79-84 Trojan horses, 8 trust brokered trust, 134-136, 161 overview, 38, 115-116 trust boundaries, crossing, 324-325

353

Trust Exchange errors, 236 trusted interactions, 181-184 WS-Trust, 149-153

U unidirectional identity, 102 UniqueIDs, 277 unknown cards, handling, 286-287 Unsupported Error, 237 Untrusted Recipient errors, 236 user acceptance of online services, 91 user authentication. See authentication User Cancelled errors, 235 user control and consent (law of identity), 94-96 user credential element (Managed Cards), 201-202, 333 user-centric federation, 328 UserIDs, 277 usernames, 198 users acceptance of online services, 91 CardSpace walkthrough from user’s perspective, 170, 172 consistent user experience, 129-130, 177-181 passive user notiﬁcation, 296-297 prompting for Information Cards, 294-295 training to look for Information Card sign-in, 285 user control and consent, 94-96

V validated-claim services, 332 validating tokens WCF (Windows Communication Foundation), 260 in websites, 238, 241-242 Victoria’s Secret, 98 virtualization of assets, 10-16

354

Index

viruses deﬁnition, 7 importance of, 9 motivation behind worm creation, 9

W WCF (Windows Communication Foundation) adding CardSpace to, 255-256 calling CardSpace from, 256-258 claims processing, 260-261 overview, 252-255 policy options, 261-262 token decryption, 258-259 token veriﬁcation, 260 web browsers, 162 web developers, CardSpace walkthrough from web developer’s perspective HTTPS login page, 173 Information Card object tag, 174 TokenProcessor page, 174-175 Web pages, 175 web services deﬁnition, 137 overview, 137-138 SOAP (Simple Object Access Protocol), 142 web browsers, 162 WS-* speciﬁcations history and development, 138-141 Identity Metasystem components as WS-* features, 156-157 Identity Metasystem implementation, 159-161 token proﬁles, 148 WS-Addressing, 144 WS-Federation, 154-156, 162 WS-MetadataExchange, 154 WS-Policy, 144-145 WS-Security, 145-148 WS-SecurityPolicy, 154 WS-Trust, 149-153

WSDL (Web Services Description Language), 144 XML (Extensible Markup Language), 141-142 Web Services Description Language (WSDL), 144 websites, deploying CardSpace in auditing and nonauditing IPs, 246-247 dynamically setting site requirements, 232 Information Card browser extension HTML syntax, 226 issuer property, 228-229 IssuerPolicy property, 229 OptionalClaims property, 230 overview, 224-225 PrivacyUrl property, 231 PrivacyVersion property, 231 RequiredClaims property, 229-230 TokenType property, 230-231 within Web forms, 227-228 XHTML syntax, 227 logon process, 224 Managed Cards, accepting, 244-246 Personal Cards, accepting, 243-244 scripts error handling, 233-237 example, 232 retrieval of claim values, 238, 242-243 token decryption, 238-240 token integrity check, 238, 241 token validation, 238, 241-242 Welsh, Amanda, 29 What Is This? link, 283 wholesale club cards, 309 Wi-Fi, 113 Windows Event Viewer, 237 Windows CardSpace. See CardSpace implementation

Windows Communication Foundation Unleashed, 252 Windows Communication Foundation. See WCF Windows Server 2003, 176 Windows Vista, 176 Windows XP SP2, 176 worms deﬁnition, 7 ILOVEYOU, 7-8 importance of, 9 motivation behind worm creation, 9 WS-* speciﬁcations, 271 history and development, 138-141 Identity Metasystem components as WS-* features, 156-157 Identity Metasystem implementation brokered trust, 161 canonical scenario, 159-161 overview, 136-138 token proﬁles, 148 WS-Addressing, 144 WS-Federation, 154-156, 162 WS-MetadataExchange, 154 WS-Policy, 144-145 WS-Security, 145-148 WS-SecurityPolicy, 154 WS-Trust, 149-153 WSDL (Web Services Description Language), 144 wsFederationHttpBinding binding type, 257 wsHttpBinding binding type, 256

X-Y-Z X.509, 45 certiﬁcates, 192, 197 V3 credential (Managed Cards), 201 XHTML Information Card browser extension, 227 XML (Extensible Markup Language), 141-142