the future of identity for secure business

8/14/2019 The Future of Identity for Secure Business

http://slidepdf.com/reader/full/the-future-of-identity-for-secure-business 1/18

The Future of Identity For Secure BusinessEnablement

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].

The Future of IT Conference

October 29-31, 2008

Centro Banamex

Mexico City, Mexico

Gregg Kreizman



The Future of Identity For Secure Business Enablement

Page 1Gregg KreizmanMEX30L_109, 9/08, AE

This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of theintended 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 expresswritten permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates.Al l rights reserved.

Key Issues

1. What does "success" mean for an identityfederation project?

2. How are the emerging user-centric identityframeworks progressing toward maturity andmainstream adoption?

3. How will software-as-a-service be affected by offederation and personal identity frameworks?






Who Needs Federated Identity, and WhatAre the Benefits?

• Who? Enterprises that:

- Would otherwise have to manage identity for manyexternal users.

- Want to aggregate services on behalf of others or wantto 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 upsellother 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 benefitfrom 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.

Background: Identity federations provide a limited set of benefits to participants and users.

Key Issue: What are the business drivers for federated identity management?






Federation Benefits? Yes, but a Dose ofReality Is NeededBusiness Benefit/Problem Solved Yes, however …

Allows for privacy Policy and architecture mustsupport privacy protection

Service provider userregistration — Save timeand money

Account linking requirements eliminatethis benefit. Role passing is great if youcan get it

Less heavy-dutyinfrastructure than PKI,for example

Still have same trust, process and legalissues as with PKI —identity proofing, liability and howto handle strong authentication needs

User convenience — SSO Different use cases must be handledconsistently for a good userexperience

Service provider help desk — Fewer IDmanagement calls

Trade ID administration problems fora few potential infrastructure supportproblems

Today's federation capabilities provide benefits and resolve some problems that come with either centralizedinfrastructures or disconnected silo infrastructures. A relying party in a federation does not have to prove theidentities 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 newshere — 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 isseamless. 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 notresolve legal liability issues. The issues of who is liable and what are the repercussions should an identitycredential be used to perpetrate a fraud or improperly access resources of another participating organizationmust 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.

Tactical Guideline: User governance agreements to resolve the important business issuesassociated with federations.

Key Issue: What are the business drivers for federated identity management?






What Is Identity Federation Success?

Success =

• SP: Customer ease-of-use; reducecredential confusion andauthentication 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 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

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 SPsconsidered scalability and standardization as success factors as well.

Key Issue: What does "success" mean for an identity federation project?






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 thebandwagon."

"It's technically practical now": This comment reflects the common belief among current deployers of identityfederation technology that it is mature enough for the "late majority" enterprises to successfully deploy. This was not thecase through 2005. "Standards for trust needed": Many organizations spent extra time managing legal trust agreementswith 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 areready to talk": The number of enterprises ready to consider identity federation is rising, as is those technically ready tofederate. This is especially prevalent in service provider organizations, which are being pressed by customers to becomefederation-capable while recognizing the efficiency benefits of doing so. "90+% of users report highersatisfaction/80+% report saved time": Organizations that measured success through user-happiness metrics reporteduniformly 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 lesseducated and less technically prepared. "Authentication failure rate from 30% to 0%": This is particularly importantto 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 theamount of nontechnical effort required to get internal and external participants on board. Note, however, that the drive istoward 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 thattheir 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.






Best Practices and Lessons Learned

• Start small

• Have infrastructure ready

• Involve legal and network guys as soon aspossible

• 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 aretechnologically 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 guysASAP: Any legal contract and network architecture that must occur should be considered early. Educate the businessunits/development groups (partner with architecture group): Identity federation is a topic that business units oftenconsider "just IT" and application developers consider a burden to learn, but significant business unit and applicationdevelopment 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 andtechnical competency. Be ready to provision your partners: It is unlikely that all partners will be technically matureenough to federate without help. Vendors offer reduced-price " partner provisioning" solutions for federation for suchcases. Get it standardized: Many of the case studies interviewed benefits from an enterprise requirement for SSO to allresources and a willingness to stipulate identity federation technologies as an enterprise standard. This action removed thenecessity to convince all internal participants of the benefits of federation to them. Measure user satisfaction/timesaved: An excellent measurement of both project success and the benefits of the technology is to survey user satisfactionand whether or not users "save time" using the new technology. Financial measures of the cost of a partner connectionalso often show obvious benefits.






Characteristics of the Federated IdentityTool You Will Buy or … Build?

• A federation gateway or (better) functionality isincluded with your WAM

• It integrates with your identitymanagement 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 previousidentity 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.






Joseph R. User:One Guy — Many Personas

$ Bank $

Government

Rental Agency

Employer orProspective

Employer

Joseph R. User

Identity Providers Service Providers

Employer

HealthcareProvider

Credit/Debit

University

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 increasinglyfind 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.

Key Issue: How are the emerging user-centric identity frameworks progressing toward maturityand mainstream adoption?

Background: PIFs are evolving to help consumers and service providers more easily registerfor, sign onto and share appropriate identity attributes with service providers in multiplebusiness contexts.






Your Online Persona in 10 Years …

Are you happynow?

• Lots of credentials

• Not much reuse

• Hard-to-assess assurance

Still NotHappy

Not perfect, butmaybeachievable

• Few credentials

• Reasonable reuse

• Better assurance levels

Like Today… butGood

They might bewatching ...

• Very few credentials

• Lots of reuse

• Enough assurance?

SaaSWorld

They arewatching …

• One credential

• Complete reuse

• Complete assurance (Not!)

Big Brother

ConsProsProbabilityScenario

White shading = greater probability

The future of identity federation― and, by extension, personal identity frameworks (PIFs) ― is really a story about thecredentials one will carry to prove their identity, online and maybe offline. The question is how many credentials ― fromwhom 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 thegovernment, 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. Credentialsissued 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 AssertionMarkup Language (SAML) supporters ends with new standards: WS-SAML, WS-XACML and so on. Identity assuranceis 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.






User-Centric Identity:Will a Real IDP Please Stand Up?

2012?20082004 2006

Risk/Usage

Communities ofTrust

InternalFederation

Blogs

Social Networks

High-RiskApplications

Financial

Healthcare

Real Trust

"The Dividing Line" Real Value

Now What Do We Do?

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 itsvision 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-to- business. 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.






OpenID:The Hare• 2007-2008: Grew virulently —

10,000 sites

• Support from Yahoo, AOL,Google and OpenID Foundation,including Microsoft

• OpenID 2.0 and AttributeExchange 1.1 released

• Security slightly improved:- "Recommends" stronger

SHA256

- "Recommends" SSL

- Stronger authentication stillout of scope

- Still subject to phishing andman-in the-middle attacks

IdentityIdentityProviderProvider

RelyingParty

3. Relying party is notalready associated withthe IP and negotiateswith IP for shared secret

2. Relying party fetchesURL that points to IP

1. User submits URL

4. Redirect to IP6. Redirectconsumerto relyingpartywith token

PhisherPhisherRPRPPhisherPhisher

IDPIDP

5. Authenticate toIP if not alreadyauthenticated

SiteHostingUser'sURL

PhisherPhisherEE--MailMail

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 phishingattacks 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.

Strategic Planning Assumption: Through 2010, OpenID will be the PIF of choice for the majorityof low-assurance social networking applications.






Microsoft CardSpace:The Tortoise

Source: Microsoft

• Contributors:Microsoft with inputfrom many

• Delivered productas part of .NET andwith Vista

• Support growing:Firefox extension,Higginscompatibility

• Early days: Butclient presence willgrow with Vista

To implement CardSpace, a service provider modifies its Web site to return an HTML object tag when a user hits a buttonthat 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 acard with the appropriate attributes (referred to as claims). The user selects a card that is a visual representation of anidentity persona (the set of claims) and may be protected with a variety of authentication schemes. The claims may bestored 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, WS-

Policy, WS-MetadataExchange) for the more complex interactions involved in obtaining an identity. CardSpaceauthentication to identity providers is based on tokens, and identity providers can choose to support differentauthentication 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 withother 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.

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 Buys Credentica and TheirU-Prove Minimal Disclosure Token Technology

IdentityIdentityProviderProvider

RelyingParty

Noncechallenge

Issues one-time"blind" tokensigned with IDPsignature, but is"not seen" by theIDP

Nonce signedwith user'sprivate key,verified withpublic key

Anti-phishing:

Anti-replay:

Anti-collusion: ~

Proprietary: Yes

Open specification: ?

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, atthis 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.






Higgins: 1.0 Prototypes Available

Source: Eclipse Foundation

• Eclipse Foundation

• Major contributors: IBMand Novell

• A developmentframework and referenceimplementation,not a product

• Plug-ins, common APIs

and data model

Clientcomponents

STS andSAML-basedIDPs

IDAS linkagebetween STSand LDAP

Higgins is an identity software development framework. It is an open-source initiative with a home at the Eclipse FoundatioSeveral organizations are contributing to Higgins. Large IAM vendors include IBM and Novell, and Microsoft is helping, toThe Higgins architectural approach is to develop an application programming interface (API) set and Java-based referencecomponents 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), anstandards-based protocols (such as SAML and WS-X). Higgins identity selector components use i-cards and provide analmost identical user experience to CardSpace. Indeed, CardSpace interoperability was an early emphasis. Higgins alsoincludes a data model that abstracts identity attributes from the various sources. For example, name data stored in twodifferent target directories with different schemas and data definitions can be stored and retrieved with pluggable componenthat transform that data into a common Higgins representation. This architectural purity should be attractive to largeenterprises with complex, heterogeneous identity infrastructure and a commitment to open source. However, it is truly earlydays for Higgins. While Microsoft is shipping productized CardSpace components and OpenID implementations arespreading rapidly — albeit with low-end functionality — the Higgins components predominantly exist as prototypes. Versi1.0 components are now available for client-side identity selector functionality as browser extensions and stand-aloneimplementations. There are also two identity provider implementations supporting a WS-Trust security token service modeland 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 acan afford to wait until year-end 2008 should monitor the Higgins project for delivery of enough useable components toimplement a vendor-neutral PIF architecture.

Background: Higgins is an open-source "answer" to CardSpace.






Concordia

OpenIDFoundation

OpenIDFoundation

The User-Centric Identity Ecosystem:Who Gets Consumed?

HigginsHiggins

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 theconstruction 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.

Background: OpenID specifications are immature relative to established federation standards,and several vendors are doing beta implementations and are contributing to developing thespecifications.






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

ProprietarySSO

Application

OpenIDProvider

SAMLSAML

CustomAuthentication

Service

Directory Services

SAMLFederationGateway

MultiprotocolSSO

Gateway

SaaS - API

ESSO - Client

WAM

OpenIDRelying

Party

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.

Key Issue: How will today's federation capabilities merge with personal identity frameworks tobuild tomorrow's business partner and consumer identity architectures?




Page 17Gregg KreizmanMEX30L 109 9/08 AE


Recommendations

What to do:

Monday: Assess your enterprise's use case for federation.

- Will you be a service provider, an identity provider or both? Are yourpartners ready? Will you provide federated SSO to SaaS for yourinternal staff? Evaluate deployment options.

Next Month: Assess the maturity of your IAM infrastructure and

what is technically necessary in order to implement federation.

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

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

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

Recommendations

the future of identity for secure business

Documents