Identity Federation in Web Services

Identity Federation in Web Services
Securely Exchanging Identity across Domains
Layer 7 Technologies
White Paper
Contents
Introduction ................................................................
................................................................................................
.................................................. 3
The Identity Problem ................................
................................................................................................................................
.................................... 3
Integration and Isolation................................
................................................................................................
........................................................... 3
Identity Silos................................
................................................................................................................................
.............................................. 3
Cross-Departmental
Departmental Application Integration ............................................................................................
............................ 4
Legacy System Access ................................
...............................................................................................................................
............................... 5
Corporate Mergers and Acquisitions ................................................................................................
........................................ 5
External Trading Partners ................................
................................................................................................
......................................................... 5
Approaches to Bridging Identity Silos ................................................................................................
........................................... 5
Custom Hard-Coding ................................
................................................................................................................................
................................. 5
Identity Consolidation ................................
...............................................................................................................................
............................... 6
Directory Synchronization................................
................................................................................................
......................................................... 6
Single Sign-On Approaches ................................
................................................................................................
....................................................... 6
The Role of Standards ................................
................................................................................................................................
................................... 7
Addressing Identity Isolation ................................
................................................................................................
........................................................ 8
Simple and Effective................................
................................................................................................................................
.................................. 8
Flexible ................................................................
................................................................................................
...................................................... 8
Standards-Based ................................
................................................................................................................................
....................................... 9
Turnkey Solution ................................
................................................................................................................................
....................................... 9
Local Control ................................
................................................................................................................................
............................................. 9
Secure ................................................................
................................................................................................
....................................................... 9
Conclusion ................................................................
................................................................................................
..................................................... 9
About Layer 7 Technologies ................................
................................................................................................
........................................................ 10
Contact Layer 7 Technologies ................................
................................................................................................
..................................................... 10
Legal Information ................................
................................................................................................................................
........................................ 10
Copyright © 2010 Layer 7 Technologies

ogies Inc. All rights reserved. SecureSpan and the Layer 7 Technologies design mark are
trademarks of Layer 7 Technologies Inc. All other trademarks and copyrights
yrights are the property of their respective owners. 2
Introduction
XML-based
based Web services are a powerful vehicle for reusing shared application logic across diverse business
processes. These processes often need to traverse multiple departments, business units, and partners residing in
separate security domains with independent preferences, capabilities, and requirements. As a consequence,
serious communication, propagation and processing problems arise as each independent security domain
do
attempts to share Web services and applications. This problem, known as a “federation” problem, complicates and
restricts the wide-spread
spread implementation of Web services.
The fundamental challenge in the federation problem is a two

two-fold communication issue. First, how does an
application in one security domain determine access rights for the identities coming from another security
domain? Secondly, with application to application communication, how does one application determine those
access rights without
hout first knowing which identities are entitled to access the originating application? Several
technologies and standards have been proposed to address the identity federation problem for the World Wide
Web, but
ut until now, the problem for Web services has been unresolved. In order to reach their potential in the
modern extended enterprise, Web services must be able to effectively bridge application identities across diverse
security domains. This paper presents a solution to the Web services identity feder
federation
ation problem that fulfills this
requirement, and allows the technology of Web services to be fully utilized as the powerful tool that it is.
is
The Identity Problem

Integration and Isolation
In today’s business climate, most organizations have a variety of specialized applications that serve functional
areas critical to day-to-day
day business operati
operations. From general ledger, to order management, to resource
management, many of these applications were developed in isolation at different points in time. This can happen
organically as new applications are introduced gradually over time, or abruptly as
Applications residing neww applications are added suddenly due to mergers or acquisitions. These
applications are often associated with the core business processes that drive
in different security
revenues. The term “application silo” is frequently used to describe the negative
domains often spawn effects of these isolate
isolated monolithic applications, one-off
off interfaces, and disparate
identity silos, posing data schemas.
a significant hurdle to
any integration Critical application functions do not live in a vacuum. Since varying degrees of
technology, including interaction between applications is essential, well understood integration
technologies
technologies—like CORBA, RMI, COM/DCOM, and RPC—have have evolved to help
Web Services integrate applications into business processes. Web services are simply the most
recent effort for making integration technology responsive to business needs. Unlike
past efforts, Web services enable the interop
interoperable
erable sharing of reusable application components across any number
of diverse applications or platforms. But Web services has not overcome one of the principal problems associated
with all prior integration technologies: namely that application silos often spawnwn corresponding identity silos,
where identity silos are significant hurdles to the successful integration of applications residing in different security
domains.
Identity Silos
Before applications can interact with h other applications or end
end-users,
users, some form of access control is usually
applied. At a minimum, access control consists of both authentication and authorization. Authentication involves
the presentation and validation of credentials, and authorization involves
olves granting access, rights, or entitlements
based on the interpretation of the authentication results. In short, applications take the presented credentials,
initiate a validation of the credentials by contacting an appropriate identity store or provide
provider,r, and receive back a
success or failure result, as well as other related information. This information is then subjected to some form of
access control policy or business logic, and the identity is granted or denied rights accordingly. When integrating
applications via Web services, identical mechanisms for authentication and authorization are used.
For consistent management, identities are typically stored in the same security domain as the application. An
identity may represent another application, a hu
human user, or a group of users, and consist of elements such as
common name, fully qualified name, group, role, certificate, and security clearance. During the authentication and
authorization process, the exact elements in an identity are matched to the fu
functional
nctional requirements of the
applications or Web services served by the identity provider.
Implementing disparate identity providers within an enterprise (or between partners)

For Web services, the complicates the authentication and authorization process, but ut there are several
reasons why it would be unusual to have one common identity provider for all
identity silo problem
applications. First, different applications may require identity providers with different
is compounded identity elements, formats, or protocols. Second, applications and their associated
because most identity providers may need to be kept in separate security domains due to internal
interactions happen privacy conc
concerns
erns or regulatory requirements. Third, many enterprises will naturally
between applications divide into multiple departments and business units with separate IT administration
and identity providers. Fourth, partners cannot expose their identity provider(s) to
where no practical
each other with
without
out risking unauthorized access to their core applications and business
user intervention is processes. For these reasons, identities created locally rarely have the same or any
possible relevance outside of their local security domain, indirectly leading to the identity silo
problem.
If a legitimate user, application, or Web service authenticates against a corresponding identity provider in one
identity silo, their identity (or any evidence of the authentication) may have no relevance when requesting access
to another application or Web eb service in another identity silo. In this case, the integration is broken,
broken and the
authorization in one silo will fail even though the authentication succeeded in another silo. For Web services, this
problem is compounded by the fact that most interacti
interactions
ons happen between applications, meaning that no
practical user intervention is possible.
As the following examples illustrate, identity silos are the root cause of integration issues in many
ma common
integration scenarios:
Cross-Departmental Application Integration

For operational and regulatory reasons, financial institutions ty
typically keep functional systems and departments
separate. Many of their customers, however, may make use of both the banking and the investment branches of a
single institution.
stitution. The credentials and authorization processes required to access these systems are often as
unique as the applications themselves. This “Chinese Wall” makes it difficult for customer service representatives,

who often need access to two or more se separate applications and corresponding databases to provide a positive
service experience to clients. Further complicating matters is the fact that, while protecting the customer’s
personal data, financial institutions must also provide an audit trail to he
help support non-repudiation
repudiation procedures
and ensure regulatory compliance.
Legacy System Access

Most large organizations have a variety of entrenched legacy systems that support core business processes and
profit centers. This is even true for companies that have grown organically rather than through mergers or
acquisitions. These legacy systems may be based on credential stores and authorization processes that create
internal barriers to integration with newer Web
Web- or Web services-based
services
applications. Removing these barriers can be difficult, requiring either substantial
Typically, substantial
coding, or middleware, or the cost
cost-prohibitive
itive migration of the applications to
investments in coding newer platforms
platforms.
and/or expensive
middleware are Corporate Mergers and Acquisitions
required to help Many industry sectors have experienced a sharp increase in merger and acquisition
manage cross- activities, often in the form of a merger of peers. Two large organizations with
sizeable client bases and business systems may choose to selectively maintain
boundary authorization
parallel sets of application infrastructure, either for brand separation or simply due
and authentication to the complexity of migrating to a common system. Ensuring that core operational
applicati
applications like Treasury, GL, ERP, and HR systems have access across both sets of
systems is challenging, and often has to be completed quickly to meet b business
usiness or regulatory deadlines.
deadlines
External Trading Partners

Competitive contractors or technology providers are often partners in large civilian or government contracts. To
exchange project information, each of them may need to provide secure, fine-grained access to selected systems.
systems
For security reasons, granting access to each other’s identity management systems is usually a complex task
involving the development of custom bridging applications to provide secure, on-demand
demand access.
Other examples undoubtedly exist, but the these four scenarios illustrate some of the real impact associated with
application identity silos. Despite being a common problem for a number of years, little has been done to directly
address the issue. Most proposed solutions have had limited success, and as Web services usage expands, the
problem becomes more acute as the human options for bri bridging identity silos disappears.
Approaches to Bridging Identity Silos

Attempts to integrate disparate identity systems have traditionally used one or more of the technical approaches
outlined below. While each approach provides part of the solution, each also
While a number of has fundamental shortcomings that result in expe
expensive
nsive and/or risky side effects.
effects
solutions have been tried,
Custom Hard
Hard-Coding
including brute force
Custom built solutions take a brute force approach to bridging identity
ident silos on
hard-coding, identity
an integration
integration-by-integration
integration basis. Rules and translators are created that map,
consolidation, directory transform, or otherwise manipulate identities exchanged between two silos.
synchronization and Custom solutions, though not necessarily elegant, are effective, but
leveraging Single Sign On considerable upfro
upfront
nt work is required to define rules and use cases, and
systems, none have developers must be familiar with the identity and processing models for both
systems involved in the integration. Once in place, the brittle nature of the
proven to be a silver
approach requires frequent updating of the cuscustom
tom code in lock-step
lock with any
bullet for solving the identity
identity-related
related changes on either side of the integration. This leads to
identity bridging problem unpredictable ongoing costs and administrative issues.

Occasionally used, this is an inefficient and inflexible approach that deals with a pervasive p
problem
roblem one instance at
a time. Little or no re-use
use is likely, as each integration requires the development of a new bridging application with
the potential for subsequent implementation errors and security compromises
compromises.
Identity Consolidation
Identity consolidation
lidation maps identities associated with one authentication source to a single consolidated identity
for authorization purposes. For example, staff members that have access rights to a retail banking application
might be identified as the single identity ““EMP_RETL”
EMP_RETL” when accessing the foreign exchange and treasury
applications. This provides a bridging mechanism between distinct identity silos, but obscures potentially
important differences between members of the consolidated identity, thus eliminating the aability
bility to make fine-
fine
grained authorization decisions. This simple bridging approach also produces some fundamental management
issues.
Auditing use of services and ensuring non

non-repudiation is a particular challenge if all external accesses are mapped
to a single
ingle identity. Tracking down individual actions taken when several entities are simultaneously accessing a
system becomes extremely time consuming and difficult. The overall effect is a “loss of consequences” of any
interactions, and a potential impedimen
impediment to security policies or regulatory compliance.
Updating the authentication and authorization processes when an individual identity account is inevitably removed
from the group is both critical and tedious. Hours or even days might elapse before changes are propagated. The
end result is often deactivation of the original consolidated account, followed by reassignment of “survivor”
identities to a new account. This administrative nightmare can be difficult to automate, and any associated
problems can break the integration or worse, create lapses in security.
Directory Synchronization
Directory synchronization addresses some of the shortcomings of consolidation by replicating some or all remote
identities into a separate store. This replicated store is effectively an exact copy of the identity store used by
remote entities residing in another security domain. The challenges associated with maintaining granularity are
effectively overcome since all accessing entities retain a distinct identity, facilitati
facilitating
ng local authentication and fine-
fine
grained identity-based
based authorization while ensuring a detailed audit trail. Despite these improvements, directory
synchronization also introduces some significant administrative challenges.
The initial synchronization process

ess may require the transfer of a significant amount of data if the data store is
large. Firewalls or routers may need to be reconfigured to provide a secure channel between the two silos if they
are in different security or network realms. The format of tthe
he identity data may need to be transformed during
synchronization due to incompatible formats between an application provider and requestor, or simply different
identity contexts.
Once the replicated store of identities has been created on the provider
provider-side, an ongoing mechanism must be
established to keep the two copies synchronized. In addition to ensuring connectivity, synchronization tools need
to update the replicated copy either on a periodic basis, or in real
real-time
time as changes occur to the original store.
s In
some cases, this can lead to race conditions as updates occur asynchronously with additions and/or changes. The
latency associated with updates can result in inadvertent access for revoked identities and/or denied access for
new identities.
Single Sign-On
On Approaches
Single Sign-On
On (SSO) systems are an effective mechanism for providing single login access to a variety of back-end
back
systems through Web portals and other gateway applications. A given entity signs on once and is granted the
correct accesss and entitlements on multiple systems through some form of opaque cookie or token. Scaling SSO
systems to encompass a broader spectrum of integration scenari
scenarios,
os, however, can be challenging.
challenging

The SSO model does not eliminate the proliferation of disparate user IDs and passwords, but instead, simply masks
this issue for some pre-defined
defined processes. Local applications are still responsible for authorizing users and
determining what to do with the authentication token. This requires pre pre-negotiation
negotiation of roles and
an entitlements, as
well as considerable amounts of custom code to process or map the incoming identities.
In the Web environment, most SSO products use cookies as evidence of authentication. This works well for human
users signing into a Web browser page, but does not translate well between applications, or in Web services
integrations where there is no equivalent to a browser application. In both of these situations, the deployment of
custom code or platform-specific agents is required to properly interpr
interpret
et and verify the cookies.
SAML-enabled SSO To address this, several SSO products also support Security Assertion Markup Language
products provide the (SAML) tokens that offer more flexibility than proprietary cookies. SAML is standards-
standards
based, has no dependency on a Web browser, and has growing cross-vendor
cross
best promise for interoperability (see The Role of Standards below for more information). Typically, the
cross-boundary originating identity and some form of evidence of that identity’s successful
exchange of identity authentication are contained in a SAML assertion. Systems can pass these SAML tokens
and authentication both behind and across firewalls to a corresponding SAML “receiver” to receive,
receive
by securely process, and verify the token. This approach is sometimes referred to as “Federated
SSO” or “Federated Identity
Identity,” and requires that the implementation team define exact
transferring security protocols for the token. If not protected in some manner, the same token can
credentials between be used for subsequent replay attacks
attacks.
systems
An important part of the solution, SSO systems still require considerable pre-
pre
negotiation of identity context between silos, as well as the code to support proper authorization within this
context. The introduction of SAML does provide a potentially powerful mechanism for exchanging both identity
and evidence of authentication, butut it still requires significant infrastructure to securely exchange tokens, validate
their authenticity, and correctly authorize users. This can lead to an expensive and time-consuming
consuming Web services
implementation process even if an SSO system is already in place for an existing Web portal application.
The Role of Standards

Several groups are assessing identity-related
related standards in the hopes o
off addressing some of the issues associated
with identity silos. Most of this work is focused on a much broader vision of federated identity, specifically,
securely establishing a person’s or application’s identity and sharing that identity globally across any domain or
enterprise.
One of the first standards to become available from multiple vendors was SAML, created by the Organization for
the Advancement of Structured Information Standards (OASIS). Designed to deliver much-needed
needed interoperability
between compliant Web access management and security products, the SAML specification itself does not define
any new authentication technologies or approaches, nor does it address how to create privacy or security policies.
Rather, SAML makes it possible to transf
transfer security credentials between systems with one-time
time authentication.
SAML forms the basis for many Web-based
based SSO systems, and has proven interoperability between major vendors.
Other standards activities are focused on strategically extending applications and Web services beyond security
domain firewalls to facilitate Web services
services-based integration.
The Liberty Alliance is composed of a diverse group of companies spearheaded by Sun Microsystems. The
collaboration claims that it is the only open body worki
working
ng on federated identity, but a group spearheaded by
Microsoft, IBM, BEA, and others has presented the WSWS-Federation standard to accomplish similar tasks. From the
beginning, IBM and Microsoft have been major forces behind the advancement of Web services, and both have
helped develop a series of standards in addition to the WS
WS-Federation standard.

Standards work continues, sometimes yielding results that overlap with OASIS and the Liberty Alliance. To
complicate matters further, the recent Liberty Alliance specification attempts to subsume the current SAML
standard, while the next version of SAML attempts to do the same with the Liberty Alliance standard.
The multitude of standards and standards bodies merely provides alternate methods for solving a similar problem
set. The eventual convergence of these efforts, possibly after the introduction of the WS-Federation
Federation standard,
does little to solve today’s pressing identity bridging problems.
Addressing Identity Isolation

The difficult integration challenges
enges resulting from identity isolation in today’s IT environments require a multi-
multi
faceted solution. This solution must address the broadest possible range of integration scenarios while possessing
the attributes explained below.
Simple and Effective

The majority of today’s identity-related
related integration issues are due to integrations of a moderate number of
applications or users to address the specific business needs of an organization. The goal of these integrations is to
bridge identity silos, not to deploy
oy a complex infrastructure designed to federate identity to thousands of possible
applications. To make the greatest impact, a solution must be pragmatic. It must yield an immediate return on
investment by completely solving a specific set of identity bridging issues.
Flexible
Identities and related management policies are constantly in flux due to both ordinary and extraordinary changes
in operational, business, and regulatory needs. Any solution must be able to adapt to these changes in near real
time without
thout uncontrollable delays or escalating costs. To achieve this, the solution should be capable of
leveraging existing
ing infrastructure investments
investments.

Standards-Based
Identity- and integration-related
related standards are evolving rapidly in various standards bodies.. Any solution must take
advantage of existing work, as well as be able to adapt to new standards as they become ubiquitous in order to
ensure maximum flexibility when interoperating with other systems.
Turnkey Solution
A solution adds little value if it requires
equires the development of new code, or a significant integration effort to become
operational. To ensure consistency, reliability, and rapid deployment without placing unnecessary dependencies
on third-party
party systems, all required attributes and technologi
technologies should be present in a tightly integrated, turnkey
solution.
Local Control
In order to allow local administrators to manage the policies relevant to their respective security domains, the
solution must permit independent control over the authentication and
The problem remains one authorization processes. Authentication should occurur close to the requestor to
ensure maximum reliability in the identity assertion. Authorization of the
of cost-effectively
requestor should occur close to the provider to maintain strict localized access
managing cross- control.
boundary authentication
and authorization in the Secure
face of changing industry Identity information often provides access to sensitive data and must be
standards, business protected during an exchange. Security tokens should be shielded from
expropriation and not reused through placement in a new message or replay in
policies and government
the same message. To provide a thorough twotwo-sided
sided audit trail, all actions
regulations performed by a rrequestor
equestor should be securely logged by the requestor’s
authentication provider, as well as the authorizing provider
provider.
Conclusion
Securely exchanging identity is critical to the successful integration of applications across identity silos. As
information technology
nology rationalization and productivity pressures move more companies towards Web services,
more applications will be delivered as XML
XML-based Web services to enable their reuse across diverse business
processes. Since business processes often impact systems across multiple departments, business units, or partners,
these Web services will require identity federation to ensure that authentication and authorization occur in the
appropriate security domains. Although various disparate technologies have attempted to address these
requirements, they fail to deliver a practical, flexible, and cost
cost-effective solution for Web services.
The Layer 7 SecureSpan™ XML Firewall is the first turnkey solution to bridge identities in federated Web services
environments while ensuring the confidentiality, flexibility, and consistent security required in an enterprise-class
enterprise
solution. For more information, please visit the Layer 7 web site: www.layer7tech.com
www.layer7tech.com.

About Layer 7 Technologies

With offices in San Mateo, California; New York, New York; and Vancouver, British Columbia, Canada; Layer 7
Technologies helps enterprises accomplish secure and cost
cost-effective
effective business integration using XML and Web
services. Layer 7 Technologies’ SecureSpan™ Solution is the first technology that aaddresses
ddresses security and
governance across a Web services integration without expensive and inflexible programming. With the
SecureSpan™ Solution, customers realize lowered integration costs, increased security reliability, and the ability to
future-proof their
ir Web services investments. Contact Layer 7 Technologies or visit www.layer7tech.com for more
information.
Contact Layer 7 Technologies

Layer 7 Technologies welcomes your questions, comments, and general feedback.
Email:
info@layer7tech.com
Web Site:
www.layer7tech.com
Phone:
604-681-9377
1-800-681-9377 (toll free)
Fax:
604-681-9387
Address:
US Office
1200 G Street, NW, Suite 800
Washington, DC 20005
Canada Office
Suite 405-1100 Melville Street
Vancouver, BC
V6E 4A6 Canada
Legal Information
Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
trademarks are the property of their respective owners.


Identity Federation in Web Services

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Identity Federation in Web Services

Transféré par

Droits d'auteur :

Formats disponibles

Identity Federation in Web Services

Securely Exchanging Identity across Domains

Copyright © 2010 Layer 7 Technologies

The fundamental challenge in the federation problem is a two

The Identity Problem

Implementing disparate identity providers within an enterprise (or between partners)

Cross-Departmental Application Integration

Copyright © 2010 Layer 7 Technologies

Legacy System Access

External Trading Partners

Approaches to Bridging Identity Silos

Copyright © 2010 Layer 7 Technologies

Auditing use of services and ensuring non

The initial synchronization process

Copyright © 2010 Layer 7 Technologies

The Role of Standards

Copyright © 2010 Layer 7 Technologies

Addressing Identity Isolation

Simple and Effective

Copyright © 2010 Layer 7 Technologies

Copyright © 2010 Layer 7 Technologies

About Layer 7 Technologies

Contact Layer 7 Technologies

Copyright © 2010 Layer 7 Technologies

Vous aimerez peut-être aussi