The Venn of Identity Options and Issues in Federated Identity Management
Total Page：16
File Type：pdf, Size：1020Kb
Identity Management The Venn of Identity Options and Issues in Federated Identity Management Federated identity management lets users dynamically distribute identity information across security domains, increasing the portability of their digital identities. It also raises new architectural challenges and significant security and privacy issues. EVE MALER espite aging and psychological and cosmetic Identity Sun changes, who you are as a person is fairly management Microsystems constant—Eve and Drummond will remain Eve and Drummond over time. The same and single sign-on DRUmmOND Disn’t true of your digital identity. Currently, eve@ Although many objects have digital identities—from Reed xmlgrrl.com is tied to Eve, for example, but might RFID-tagged equipment to software applications to Cordance later be tied to someone else or disappear entirely. companies—digital identities for humans raise the This is just one of the challenges people have with most interesting issues and challenges, whether in an digital identities. enterprise context or on the open Internet. Federated identity management is a set of tech- Large-enterprise IT departments view identities nologies and processes that let computer systems as the user accounts for employees (and others) that dynamically distribute identity information and they manage through a user store (often based on the delegate identity tasks across security domains. Fed- Lightweight Directory Access Protocol). As enterpris- erated identity is the means by which Web appli- es grow, management teams must synchronize their cations can offer users cross-domain single sign-on account stores, both to ensure proper account provi- (SSO), which lets them authenticate once and there- sioning and to govern users’ application access. Due after gain access to protected resources and Web to mergers, acquisitions, and joint ventures, however, sites elsewhere. enterprises often find that managing identities this However attractive its benefits, federated identity way is costly and brittle. imposes costs as well, entailing new and increased Most Web sites and applications view identities as security and privacy risks because it shares valuable the accounts they host on behalf of their users, who information across domains using loosely coupled access email, buy goods, engage in social activities, network protocols. Such risks require mitigation, and so on. While Web applications manage user ac- which can range from preventing message replay to counts much as their enterprise counterparts do, users collecting user consent for data sharing in both on- tend to think of these identities as personal resources line and offline scenarios. under their own control. And, unlike in enterprise Here, we describe the federated identity model and scenarios, the biggest problems with Web identity are discuss its security and privacy risks and architectural borne by users: they must create and remember their challenges. We also profile three popular federated usernames and passwords for each site, populate each identity protocols for implementing the model: the profile with the same data, and remember each site’s Security Assertion Markup Language (SAML),1 the arcane rules. OpenID specification,2,3 and the InfoCard specifica- Federated identity offers solutions to many prob- tion underlying Microsoft’s Windows Cardspace.4 lems shared by both environments, and SSO is often 16 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/08/$25.00 © 2008 IEEE ■ IEEE SECURITY & PRIVACY Identity Management the first federated identity capability that organiza- SSO, in which an IdP, such as a health insurance site, tions add. SSO offers Web users a friendlier experience acts as a portal through which Alice accesses various through a more consistent and less frequent login proc- SPs, such as online pharmacies and billing statement ess, and gives employees more time to make products aggregators. In either case, if Alice’s relationship with or provide services. Further, combining SSO with ac- an SP predates her IdP relationship, the IdP and the count linking lets Web portals unify diverse online SP accounts must be linked (with her permission) to interactions—a popular feature that can, for example, make SSO successful. let e-government initiatives present many different When the architecture separates the identity infor- agency sites as a unified whole. Finally, SSO can sim- mation’s source from its usage, everyone benefits: plify the architecture of each participating site. SSO involves sharing information about when • Alice can log in once—with one set of credentials— and how users authenticate using a particular iden- and access multiple Web sites without revealing her tity. It can also involve sharing user attributes such as credentials to all of them. employee roles and shipping addresses. With all this • SPs can delegate many account-management tasks information in hand, receiving sites can make sophis- (such as password resets) and receive accurate just- ticated authorization decisions, such as ensuring that in-time user data. managers see only their direct reports’ salaries, and • IdPs can focus on improving authentication meth- present customized user interfaces, such as automati- ods and adding attractive features to account- cally calculating shipping costs and schedules based on management interfaces. the user’s address. But this loose coupling of identity tasks also introduces Overview: Federated identity model several security, privacy, and architectural challenges. Whenever a human is involved in an identity interaction, the federated model involves four logical components: Security considerations Like all outsourcing, federated identity can offer bet- • The user is a person who assumes a particular digi- ter service at a lower cost, but it also entails new risks. tal identity to interact with an online network First, federated identity involves crossing security application. domains. Ideally, all parties should secure their com- • The user agent is a browser or other software applica- munication channels against replay attacks, man-in- tion that runs on anything from a PC to a mobile the-middle attacks, session hijacking, and other threats phone to a medical device. A user’s online interac- that allow malicious use of user information or Web tions always take place through an agent, which can resources. In an HTTP context, security architects passively allow identity information flow or actively consider Secure Sockets Layer/Transport Layer Secu- mediate it. rity (SSL/TLS) with mutual authentication as a secu- • The service provider (SP) site is a Web application— rity baseline. Still, application deployers often avoid, such as an expense-reporting application or an open overlook, or only partially implement this step. source community—that offloads authentication to User authentication is another weak link in the a third party, which might also send the SP some Web identity chain. Currently, most sites rely on user attributes. Because the SP relies on external in- username/password pairs because this method poses formation, it’s often called a relying party (RP). the smallest initial burden for users and site admin- • The identity provider (IdP) is a Web site that users log istrators. However, it’s notoriously weak and suscep- in to and that sometimes stores attributes of com- tible to phishing attacks. mon interest to share with various SPs. For SPs, federated identity is less expensive than In SSO, data about identification, authentication, Most sites rely on username/password pairs and sometimes attributes flows from the IdP to the SP. However, SSO has several variants, each of which because this method poses the smallest initial dictates different flows and data choices. To illustrate this, we’ll offer examples with a user named Alice. In burden for users and site administrators. It’s one common variant, Alice begins her browsing at an SP, such as an investment management site, which she notoriously weak to phishing attacks. might visit frequently by using a browser bookmark. If Alice wants to access protected resources there, implementing a high-quality authentication infra- the SP must send an explicit authentication request structure because it offloads the authentication task to Alice’s bank (the IdP). This pattern is known as to an IdP. However, IdP-based SSO can magnify the SP-initiated SSO. An alternative pattern is IdP-initiated costs of a stolen password because it expands the scope www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 17 Identity Management of malicious activity. Most SSO protocols offer ways she’s of legal drinking age. To achieve similar “un- to mitigate this risk. For example, they might limit to linkability,” federated identity protocols must apply a minute or less the valid lifetime of the security to- special data flows and careful encryption to prevent ken that an IdP sends to SPs; some protocols also offer IdP visibility into a user’s SP relationships.5 a single logout (SLO) feature that offers users near- simultaneous sign-out of all SSO-accessed Web sites. Architectural challenges Also, while most protocols let the parties to federated Federated identity’s loosely coupled nature presents identity interactions choose the authentication meth- interesting design challenges. od used, they usually offer a way for IdPs to describe the method they applied in each instance so that SPs IdP discovery. To provide portal-style IdP-initiated can consider it when making authorization decisions.