The Future Of Identity For Secure Business

The Future of Identity For Secure Business Enablement

The Future of IT Conference October 29-31, 2008 Centro Banamex Mexico City, Mexico

For more information about our research policies, processes and methodologies, please visit Gartner Research Methodology on gartner.com. These materials can be reproduced only with written approval from Gartner. Such approvals must be requested via e-mail: [email protected].

Gregg Kreizman

The Future of Identity For Secure Business Enablement

Key Issues 1. What does "success" mean for an identity federation project? 2. How are the emerging user-centric identity frameworks progressing toward maturity and mainstream adoption? 3. How will software-as-a-service be affected by of federation and personal identity frameworks?

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 1

The Future of Identity For Secure Business Enablement Background: Identity federations provide a limited set of benefits to participants and users. Key Issue: What are the business drivers for federated identity management?

Who Needs Federated Identity, and What Are the Benefits? • Who? Enterprises that: - Would otherwise have to manage identity for many external users. - Want to aggregate services on behalf of others or want to decouple authentication from services

• Why? - Reduce the identity administration burden - Provide the user with Web SSO - Be architecturally more flexible - For the service aggregator: Potentially upsell other services

Enterprises managing large numbers of external users might see federation as a panacea today, but they will not reap the benefits unless they have malleable and sophisticated partners, or provision those partners with federation technologies themselves. Those organizations being pressured to federate now by a large partner, or suffering from being too distributed to implement centralized identity and access management, have difficult choices to make from a technology standpoint and likely have some manual integration effort to expend. Organizations that want to implement federated user provisioning have few or no technical options for federated provisioning and have few or no off-the-shelf applications ready to federate. Large consumer aggregators find themselves on the "bleeding edge" of federation deployments today, even though the opportunity to aggregate consumers will most likely disappear by 2009. Service providers looking to benefit from federation may have few options for aggregators ready to do so. Many or all of these complexities will be significantly reduced in the near term.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 2

The Future of Identity For Secure Business Enablement Tactical Guideline: User governance agreements to resolve the important business issues associated with federations. Key Issue: What are the business drivers for federated identity management?

Federation Benefits? Yes, but a Dose of Reality Is Needed Business Benefit/ Problem Solved Service provider user registration — Save time and money Service provider help desk — Fewer ID management calls User convenience — SSO

Allows for privacy

Less heavy-duty infrastructure than PKI, for example

Yes, however … Account linking requirements eliminate this benefit. Role passing is great if you can get it Trade ID administration problems for a few potential infrastructure support problems Different use cases must be handled consistently for a good user experience Policy and architecture must support privacy protection Still have same trust, process and legal issues as with PKI — identity proofing, liability and how to handle strong authentication needs

Today's federation capabilities provide benefits and resolve some problems that come with either centralized infrastructures or disconnected silo infrastructures. A relying party in a federation does not have to prove the identities of users in the other trusted organizations because it has already been done. Calls to the help desk or operations for establishing system identities are not required in the relying organization — mostly good news here — although help desks must be able to troubleshoot identity infrastructure failure problems. User convenience is a primary benefit. Federation allows for users to first connect to either the identity provider or the service provider and then be authenticated appropriately. Implementers must ensure that the experience is seamless. It is possible to pass only role information from an identity provider to a service provider. This way, identities can be authenticated in one domain but never passed to the service provider domain. Alternatively, pseudonyms could be managed by the identity provider. User IDs and passwords are the primary forms of ID used in federation, although stronger forms can be used. Allowing stronger forms of authentication, such as public-key credentials to be used for lower-risk applications (that may require only a user ID and password, for example), is complicated and not well-supported by today's technology. Technical federation standards do not resolve legal liability issues. The issues of who is liable and what are the repercussions should an identity credential be used to perpetrate a fraud or improperly access resources of another participating organization must be resolved. Adding third-party credential providers into the mix may exacerbate privacy concerns. Action Item: Use federation governance agreements to resolve concerns regarding identity proofing, provisioning and deprovisioning, legal liability concerns and technical architecture. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 3

The Future of Identity For Secure Business Enablement Key Issue: What does "success" mean for an identity federation project?

What Is Identity Federation Success? Success =

Gartner Case Studies: • 10 "successful" projects • Service providers (SP) and identity providers (IDPs) • Large and midsize • Timeline to Phase 1: 6 to 24 months; average = 14 months; median = 18 months

• SP: Customer ease-of-use; reduce credential confusion and authentication failure rate • IDP: Streamlined B2B interaction • SP: More-efficient provisioning and deprovisioning • IDP: Reduced cost (data point = $1.5 million to $250,000) • Scalability • Standardization of SSO architecture • SSO required; best way to handle it

Gartner interviewed a number of project managers and architects for deployed identity federation projects. The focus of the discussion was around what constitutes "success" in such a project and whether or not the organization would characterize their current state as "successful." Without exception, those interviewed considered their federation projects successful (a rating of 4 or 5 out of 5). The timelines to deployment were longer than expected ― most often due to business, legal and other reasons as opposed to technology deployment complexity. Definitions of success showed some variation among service providers (SPs)/identity consumers and identity providers (IDPs), with SPs more focused on customer ease and convenience and IDPs more focused on reduced cost and increased efficiency of business-to-business (B2B) interactions. Both IDPs and SPs considered scalability and standardization as success factors as well.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 4

The Future of Identity For Secure Business Enablement

Case Study Comments • • • • • • • • •

"It's technically practical now." "Standards for trust needed." "Pricing is an issue." "30% to 40% of partners are ready to talk." "90+% of users report higher satisfaction; 80+% report saved time." "Expect partners to slow you down." "Authentication failure rate from 30% to 0%." "Technology is only a fraction of the project." "Application service providers still getting on the bandwagon."

"It's technically practical now": This comment reflects the common belief among current deployers of identity federation technology that it is mature enough for the "late majority" enterprises to successfully deploy. This was not the case through 2005. "Standards for trust needed": Many organizations spent extra time managing legal trust agreements with partners, especially in cases of serial trust where more than two parties had to agree. "Pricing is an issue": Assessment of true requirements can indicate how to approach pricing. Small numbers of users may suggest per-user pricing while large numbers suggest per-connection or site-license pricing as most efficient. "30-40% of partners are ready to talk": The number of enterprises ready to consider identity federation is rising, as is those technically ready to federate. This is especially prevalent in service provider organizations, which are being pressed by customers to become federation-capable while recognizing the efficiency benefits of doing so. "90+% of users report higher satisfaction/80+% report saved time": Organizations that measured success through user-happiness metrics reported uniformly positive results. "Expect partners to slow you down": Even where partners were enthusiastic about federation, they tended to impede progress. An organization spearheading federation should expect its partners to be less educated and less technically prepared. "Authentication failure rate from 30% to 0%": This is particularly important to service providers, where a user who cannot access the service is a user that will generate little or no revenue. "Technology is only a fraction of the project": This is an indication of both the maturity of the technology and the amount of nontechnical effort required to get internal and external participants on board. Note, however, that the drive is toward more connections ― with or without federation — where simple, scalable, standardized technology can only help. "ASPs still getting on the bandwagon": Even with the incentives for service providers, enterprises often complain that their SPs are not federation-ready. Most larger SPs see federation as a temporary differentiator with efficiency benefits. Smaller SPs may not be as willing to expend scarce resources to provide for federation. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 5

The Future of Identity For Secure Business Enablement

Best Practices and Lessons Learned • Start small • Have infrastructure ready • Involve legal and network guys as soon as possible • Educate the business units/development groups (partner with architecture group) • Partner assessment is key • Be ready to provision your partners • Get it standardized • Measure user satisfaction/time saved

Case study participants reported the following best practices: Start small: To show early success, choose a Phase 1 with few (preferably two) participant organizations that are technologically sophisticated, with trust and partner agreements, mature identity and access management (IAM) infrastructures, and even proprietary single sign-on (SSO) already in place. Have infrastructure ready: Gartner recommends that identity federation only be implemented in organizations with mature IAM infrastructures already in place. Backfilling IAM into an organization as a prelude to federation will be difficult. Involve legal and network guys ASAP: Any legal contract and network architecture that must occur should be considered early. Educate the business units/development groups (partner with architecture group): Identity federation is a topic that business units often consider "just IT" and application developers consider a burden to learn, but significant business unit and application development group support will be necessary to make federation a true success and allow significant benefits to accrue to those groups. Partner assessment is key: Your partners must be ready to federate and have a mature infrastructure and technical competency. Be ready to provision your partners: It is unlikely that all partners will be technically mature enough to federate without help. Vendors offer reduced-price "partner provisioning" solutions for federation for such cases. Get it standardized: Many of the case studies interviewed benefits from an enterprise requirement for SSO to all resources and a willingness to stipulate identity federation technologies as an enterprise standard. This action removed the necessity to convince all internal participants of the benefits of federation to them. Measure user satisfaction/time saved: An excellent measurement of both project success and the benefits of the technology is to survey user satisfaction and whether or not users "save time" using the new technology. Financial measures of the cost of a partner connection also often show obvious benefits. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 6

The Future of Identity For Secure Business Enablement

Characteristics of the Federated Identity Tool You Will Buy or … Build? • A federation gateway or (better) functionality is included with your WAM • It integrates with your identity management systems • It is SAML 2.0, Liberty, Shibboleth and WS-Federation compatible • It has a strong ID mapping capability • It has a partner provisioning capability • It is capable of acting as a security token service

What characteristics make an enterprise federation-ready today and how can an enterprise be federation-ready in the future? Many organizations will look to acquire federation capabilities in the near term. Currently, the likely choices are federation gateways or federation capabilities built into Web access management (WAM) systems, although some organizations may look to Web services security products for federation, or may build their federation capabilities themselves using Shibboleth. In any case, federation capabilities must be fully integrated with the organization's identity management systems to be highly useful. Furthermore, because the protocol for federation with various partners is likely to vary, the product chosen should be compatible with all well-known variants. Identity mapping capabilities will be important ― at least in cases in which a previous identity relationship existed. Partner provisioning capabilities, usually manifested in a low-cost federation responder for organizations looking to federate with a single large partner, will be important in the near term for enterprises partnering with smaller or less-sophisticated organizations. Finally, STSs will become an increasingly regular part of the identity management infrastructure and are a symbiotic fit with "standard" federation tools.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 7

The Future of Identity For Secure Business Enablement Key Issue: How are the emerging user-centric identity frameworks progressing toward maturity and mainstream adoption? Background: PIFs are evolving to help consumers and service providers more easily register for, sign onto and share appropriate identity attributes with service providers in multiple business contexts.

Joseph R. User: One Guy — Many Personas Identity Providers

Service Providers

University

Credit/Debit

$ Bank $

Employer or Prospective Employer Rental Agency Joseph R. User

Government

Healthcare Provider Employer

We each have one body but many personas. We project these different personas depending on the context of our interactions with others. Online service users are increasingly identifying themselves to different online communities. Users and service providers in each of these contexts have different expectations about the amount of personal information provided and the extent to which real identity is verified. Each new service may require users to register and provide some identity attributes to the service provider. Most of the requested attributes are required to provide effective service; however, some services request more identity attributes than are truly required to effect a transaction — perhaps more information than users would like to divulge about themselves. Each new service also comes with a new credential, usually a user ID authenticated with a password, that users must manage. As the number of services and social contexts proliferate, users increasingly find themselves frustrated with repeated registrations and may engage in poor credential management practices. Service providers may also leave themselves and their customers vulnerable to attacks when they unnecessarily collect and store personal information that can be used in identity-related fraud.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 8

The Future of Identity For Secure Business Enablement

Your Online Persona in 10 Years … Scenario Probability Pros Big Brother • One credential • Complete reuse • Complete assurance (Not!) • Very few credentials SaaS World • Lots of reuse • Enough assurance? • Few credentials Like Today … but • Reasonable reuse Good • Better assurance levels • Lots of credentials Still Not Happy • Not much reuse • Hard-to-assess assurance

Cons They are watching … They might be watching ... Not perfect, but maybe achievable Are you happy now?

White shading = greater probability

The future of identity federation ― and, by extension, personal identity frameworks (PIFs) ― is really a story about the credentials one will carry to prove their identity, online and maybe offline. The question is how many credentials ― from whom and acceptable to whom ― will be necessary to allow you access to the resources necessary to live your life. Scenario 1: Governments not only issue standardized credentials to all, they mandate their use for all online transactions. You only have one credential, and everyone has to accept it. A single entity vouches for everyone's identity. Scenario 2: Software-as-a-service (SaaS) takes over the world. Google and "Micro-hoo" (a merged Microsoft and Yahoo) run all of the important applications because they can do it less expensively than you. With the exception of the government, their IDs are your IDs. Scenario 3: Applications are still run by a myriad of parties, but you'll have fewer credentials than today. And, there will be third-party identity providers that are willing to prove and assume some liability for identity assurance. Credentials issued by these IDPs will be accepted by more communities of trust, which are different for standard business contexts: banking, healthcare, government and so on. A war between Web Services (WS) Security followers and Security Assertion Markup Language (SAML) supporters ends with new standards: WS-SAML, WS-XACML and so on. Identity assurance is contextual, and authentication needs are determined in real time and are standardized. Scenario 4: Today's federations grow in number, but we still have many credentials from different providers. User interfaces become standardized, as do identity protocols and authentication types.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 9

The Future of Identity For Secure Business Enablement

User-Centric Identity: Will a Real IDP Please Stand Up? Risk/Usage High-Risk Applications

Real Trust

Financial Healthcare Real Value

"The Dividing Line"

Communities of Trust Internal Federation

Now What Do We Do?

Blogs Social Networks

2004

2006

2008

2012?

User-centric identity is getting a lot of play in the media, and dozens of identity and access management vendors and luminaries are weighing in with claims regarding the futures of these potentially easy-to-use, privacy-protecting identity frameworks. One user-centric personal identity framework, OpenID, has made rapid headway on social networking sites, and some online heavyweights, including Yahoo and AOL, have announced support. Microsoft continues to build its vision of this "identity metasystem" and has developed and acquired technologies to build a more robust ― while technically complex framework ― but so far it has few adopters. Real success for these frameworks will come when they can be used for a wide variety of contexts with different risk profiles ― social, consumer, enterprise and business-tobusiness. Today, however, OpenID lacks functional features and security robustness to make it usable for higher-risk applications. While Microsoft's solution stack looks promising, it will take 12 to 24 months before it delivers an acceptable solution set for higher risk business transactions and begins to witness quantifiable deployments. Microsoft must convince the world to adopt its technology and must convince independent software vendors (ISVs) to develop to its specifications ― even as it opens these specifications to the public. Meanwhile, enterprise usage of standards-based federation technologies continues to grow. While personal identity framework technologists tout new capabilities that resolve some federation shortcomings, today's federations have produced a wealth of experience and have exposed important business practices that engender trust. Technological advancements to improve transactions relative to federations are important, but as usual, identity technologies will play only a supporting role when it comes to establishing trust. We continue to need entities that will vouch for our online identities in higher-risk transactions.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 10

The Future of Identity For Secure Business Enablement Strategic Planning Assumption: Through 2010, OpenID will be the PIF of choice for the majority of low-assurance social networking applications.

OpenID: The Hare Site Hosting User's URL Identity Provider

2. Relying party fetches URL that points to IP

3. Relying party is not already associated with the IP and negotiates with IP for shared secret

Relying Party

6. Redirect consumer to relying party with token

• Support from Yahoo, AOL, Google and OpenID Foundation, including Microsoft • OpenID 2.0 and Attribute Exchange 1.1 released • Security slightly improved:

1. User submits URL Phisher IDP

• 2007-2008: Grew virulently — 10,000 sites

Phisher RP

5. Authenticate to IP if not already authenticated

4. Redirect to IP

Phisher E-Mail

- "Recommends" stronger SHA256 - "Recommends" SSL - Stronger authentication still out of scope - Still subject to phishing and man-in the-middle attacks

OpenID is an evolving, increasingly used, lightweight PIF with open-source implementations. Its supporters aptly describe it as an identity framework for "the long tail." The long tail was notably popularized in a Wired Magazine article by Chris Anderson and espoused the idea that the aggregate of all members in all related small communities outnumbers the members included in very large, related, well-known communities. OpenID is rapidly gaining ground in the widely diffuse Internet social networking spaces, and in 2007, the framework received support from AOL, Yahoo and Google. Microsoft, VeriSign and IBM have also joined the newly created OpenID Foundation to help guide the initiative, although they have no decision-making authority. Despite some security improvements that appeared as recommendations in the 2.0 specification, OpenID still lacks mandatory security features and may render implementations susceptible to some types of phishing attacks and man-in-the-middle (MITM) attacks. OpenID is gaining close to 10,000 implementations at the time of this writing, but these have been limited almost completely to low-assurance social network sites. Through 2009, OpenID usage will remain limited to low-assurance applications until identity providers step up to provide identity assurance, which is acceptable to higher-risk profile relying parties. Action Item: Enterprises should not rely on OpenID for applications, which require high assurance that all parties are who they claim to be, until security concerns are resolved. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 11

The Future of Identity For Secure Business Enablement Strategic Planning Assumption: Through 2010, CardSpace will be implemented for less than 5% of consumer-facing applications and for less than 10% of internal enterprise applications.

Microsoft CardSpace: The Tortoise • Contributors: Microsoft with input from many • Delivered product as part of .NET and with Vista • Support growing: Firefox extension, Higgins compatibility • Early days: But client presence will grow with Vista

Source: Microsoft

To implement CardSpace, a service provider modifies its Web site to return an HTML object tag when a user hits a button that says, for example, "login with my card." This object tag defines the set of claims that the site demands from the user in order to authenticate the user's identity. CardSpace then appears on the user's machine, prompting the user to present a card with the appropriate attributes (referred to as claims). The user selects a card that is a visual representation of an identity persona (the set of claims) and may be protected with a variety of authentication schemes. The claims may be stored locally (self-asserted) or at an identity provider site. The client sends an encrypted token to the service provider, and the service provider decrypts the token and provides a secure cookie to the user's browser, which can be used for subsequent page views. CardSpace clients and service providers communicate using identity protocols on top of standard Internet protocols. CardSpace communicates with identity providers using several WS-X protocols (that is, WS-Security, WS-Trust, WSPolicy, WS-MetadataExchange) for the more complex interactions involved in obtaining an identity. CardSpace authentication to identity providers is based on tokens, and identity providers can choose to support different authentication token types. These are not hardware tokens, but are identity data objects, such as user IDs and passwords, X.509v3 certificates, Kerberos tickets and SAML assertions. Prognosis: Microsoft has delivered a working, full-featured PIF solution along with Vista and as a download for Windows XP and Windows Server 2003. Therefore, over time it will have a growing default presence compared with other frameworks. However, as we have seen with Passport, this does not guarantee adoption ― just an advantage. Also, the CardSpace client is a Windows-only identity selector — a disadvantage for consumers who use other client platforms.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 12

The Future of Identity For Secure Business Enablement

Microsoft Buys Credentica and Their U-Prove Minimal Disclosure Token Technology Identity Provider

Issues one-time "blind" token signed with IDP signature, but is "not seen" by the IDP

Anti-phishing: &

Relying Party

Anti-replay: & Anti-collusion: ~ Proprietary: Yes

Nonce challenge

Open specification: ? Nonce signed with user's private key, verified with public key

Microsoft recently purchased Credentica, the developer of the U-Prove software development kit. This code works with SAML and WS-Trust protocol stacks and provides a variety of security mechanisms that help prevent phishing attacks and replay attacks. Additionally, from a technical perspective, the code helps mitigate against collusion between identity providers and relying parties. The technology uses proprietary cryptographic algorithms that are similar to X.509 certificate-based public key cryptography. It appears that Microsoft will be willing to open the specifications upon which Credentica based its patented technologies; however, nothing formal has been announced. The move by Microsoft will allow it to add these security functions to its products set and thereby continue to fulfill the vision of the identity metasystem. We estimate that it will take Microsoft 12 to 18 months to integrate the U-Prove technology. The U-Prove technology is sophisticated; however, at this early stage in the evolution of user-centric identity systems, it is unclear whether the functions embodied in U-Prove will take hold in the market. There really was no market for the product up to this point. Microsoft will need to convince enterprises that their vision of the identity metasystem is the right one. Other IAM vendors will also need to see the value in this functionality before investing resources to add this functionality into their products and therefore become part of the pluralistic (multivendor) technology environment that Microsoft has espoused for the identity metasystem.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 13

The Future of Identity For Secure Business Enablement Background: Higgins is an open-source "answer" to CardSpace.

Higgins: 1.0 Prototypes Available • Eclipse Foundation • Major contributors: IBM and Novell • A development framework and reference implementation, not a product • Plug-ins, common APIs and data model Client components STS and SAML-based IDPs IDAS linkage between STS and LDAP Source: Eclipse Foundation

Higgins is an identity software development framework. It is an open-source initiative with a home at the Eclipse Foundation. Several organizations are contributing to Higgins. Large IAM vendors include IBM and Novell, and Microsoft is helping, too. The Higgins architectural approach is to develop an application programming interface (API) set and Java-based reference components that provide PIF functionality and plug into, but do not replace, established IAM protocols and services. For example, the architecture is designed to make use of established STSs, identity attribute repositories (such as directories), and standards-based protocols (such as SAML and WS-X). Higgins identity selector components use i-cards and provide an almost identical user experience to CardSpace. Indeed, CardSpace interoperability was an early emphasis. Higgins also includes a data model that abstracts identity attributes from the various sources. For example, name data stored in two different target directories with different schemas and data definitions can be stored and retrieved with pluggable components that transform that data into a common Higgins representation. This architectural purity should be attractive to large enterprises with complex, heterogeneous identity infrastructure and a commitment to open source. However, it is truly early days for Higgins. While Microsoft is shipping productized CardSpace components and OpenID implementations are spreading rapidly — albeit with low-end functionality — the Higgins components predominantly exist as prototypes. Version 1.0 components are now available for client-side identity selector functionality as browser extensions and stand-alone implementations. There are also two identity provider implementations supporting a WS-Trust security token service model and a SAML 2.0 model. In addition, there is a prototype IDAS module that prototypes an LDAP-accessible directory for storing identity attribute data. Action Item: Enterprises that have complex heterogeneous IAM infrastructures, have made a commitment to open source and can afford to wait until year-end 2008 should monitor the Higgins project for delivery of enough useable components to implement a vendor-neutral PIF architecture. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 14

The Future of Identity For Secure Business Enablement Background: OpenID specifications are immature relative to established federation standards, and several vendors are doing beta implementations and are contributing to developing the specifications.

The User-Centric Identity Ecosystem: Who Gets Consumed? OpenID Foundation Concordia

Higgins

OpenID's specifications represent the confluence of work by a number of small industry players. Until recently, the picture of players and technologies coming together to form OpenID would have been analogous to a star being formed from cosmic particulates. No one owns OpenID. It is a set of specifications and open-source implementations. There is interest from some larger players and interactions among players from other established identity communities. Sxip Identity contributed the DIX protocol to OpenID. VeriSign and AOL have put up OpenID identity provider beta sites. Sun has integrated OpenSSO with OpenID. Not to be left out, almost every vendor with an IAM stake in the market is participating in the big PIF ecosystem. There are several interbred identity confederations, including Identity Gang and Open Source Identity Systems (OSIS). OSIS "brings together many identity-related open-source projects and synchronizes and harmonizes the construction of an interoperable identity layer for the Internet from open-source parts. Its first deliverable is interoperability with Microsoft CardSpace, although OSIS also encompasses alternate technologies, such as OpenID and SAML." The Identity Gang's mission is "to support the ongoing conversation about what is needed for a user-centric identity 'metasystem' that supports the whole marketplace ― especially individuals." The Concordia Project is being managed under the auspices of the Liberty Alliance. This project is working toward OpenID and Liberty interoperability, among other PIF convergence use cases.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 15

The Future of Identity For Secure Business Enablement Key Issue: How will today's federation capabilities merge with personal identity frameworks to build tomorrow's business partner and consumer identity architectures?

SaaS and SSO Could Drag PIFs and Federation Into the Enterprise: Options

SaaS - API

SAML

OpenID Provider

OpenID Relying Party

Proprietary SSO

Application

SAML Federation Gateway

Custom Authentication Service

WAM

ESSO - Client Directory Services

Multiprotocol SSO Gateway

There are several methods for accomplishing reduced sign-on (RSO)/SSO to SaaS providers: • Proprietary SSO using the SaaS provider's API and an alternative using the SaaS provider's API plus a custom authentication service • SAML-based federation • OpenID or CardSpace • Enterprise single sign-on (ESSO) • Multiprotocol SSO gateway The choice should be based on a combination of available enterprise and SaaS provider RSO/SSO capabilities. Standards-based SSO methods benefit all participants ― including SaaS providers. Providers have an incentive to support standards; the use of standard technologies should reduce SaaS fees (or keep them neutral), not increase them. Assess your enterprise needs for the midterm (three years), choose a small number of mechanisms for SSO — likely including SAML 2.0-based federation — and push SaaS providers to meet these requirements to conduct business. Include a SaaS vendor's identity administration and authentication architecture in your evaluation criteria before choosing SaaS. Ensure that the SaaS service-level agreement (SLA) includes change management notification regarding SaaS authentication service changes. This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 16

The Future of Identity For Secure Business Enablement Recommendations

Recommendations What to do: 9 Monday: Assess your enterprise's use case for federation. - Will you be a service provider, an identity provider or both? Are your partners ready? Will you provide federated SSO to SaaS for your internal staff? Evaluate deployment options.

9 Next Month: Assess the maturity of your IAM infrastructure and what is technically necessary in order to implement federation.

9 Next Year: Implement first federation with close partner or larger, federation-ready SaaS provider..

9 Next 2 Years: Watch the evolution of user-centric identity; expect convergence with federation standards and products.

9 Next 2 Years: Abstract service-side authentication and client-side user interfaces from other application services and components.

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential, proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.

Gregg Kreizman MEX30L_109, 9/08, AE

Page 17