FEDERATED IDENTITY MANAGEMENT
Federated identity
management is a relatively new concept dealing
with the use
of a common identity
management scheme across multiple enterprises and numerous applications and supporting many thousands, even millions, of users. We begin
our overview with a discussion of the concept
of identity management and then examine federated identity management.
Identity Management
Identity management is a centralized,
automated approach to provide enterprise- wide
access to resources
by employees and other authorized individuals. The focus
of identity management is defining an identity for each user (human or
process), associating attributes with the identity,
and enforcing a means by which a user
can verify identity. The central concept
of an identity management system
is the use of single sign-on
(SSO). SSO enables
a user to access all network resources
after a sin- gle authentication.
[PELT07] lists the following as the principal elements of an
identity manage- ment system.
•
Authentication: Confirmation that a user corresponds to
the user
name provided.
•
Authorization: Granting access to specific services
and/or resources based
on the authentication.
•
Accounting: A process for
logging access and
authorization.
•
Provisioning: The enrollment of users in the system.
•
Workflow automation: Movement of data in a business process.
•
Delegated administration: The use of role-based access control to grant permissions.
•
Password synchronization: Creating a process for single sign-on (SSO) or reduced
sign-on (RSO). Single sign-on enables a user to access all network resources after
a single authentication. RSO may involve
multiple sign-ons but requires less user effort than if
each resource and service maintained its own authentication facility.
•
Self-service password reset: Enables the user to modify his or her password.
•
Federation: A process where
authentication and permission will be passed
on from one system
to another—usually across multiple enterprises, thereby reducing the number
of authentications needed
by the user.
Note that Kerberos contains a number of the
elements of an identity manage- ment system.
Figure 15.3 [LINN06] illustrates entities
and data flows in a generic identity management architecture. A principal is an identity holder.
Typically, this is a human
user that seeks
access to resources and services on the network.
User devices, agent
processes, and server
systems may also
function as principals. Principals authenticate
themselves to an identity provider. The identity provider
associates authentication
information with a principal, as well as attributes and one or more identifiers.
Increasingly, digital identities incorporate attributes other
than simply an identi-
fier and authentication information (such
as passwords and biometric information). An attribute service manages the creation
and maintenance of such attributes. For example,
a user needs to provide
a shipping address
each time an order is placed at a
new Web merchant, and this information needs to be revised when the user moves. Identity management enables the user to provide this information once, so that it is
maintained in a single place
and released to data consumers in accordance with
autho- rization and privacy
policies. Users
may create some of the attributes to be associated with their digital identity, such
as an address. Administrators may also
assign attrib- utes to users,
such as roles, access
permissions, and employee information.
Data consumers are entities
that obtain and employ data maintained and provided by identity
and attribute providers, which are often
used to support
autho- rization decisions and to collect audit information. For example, a database server or file server is a data consumer that needs a client’s credentials so as to know what access to provide to that client.
Identity Federation
Identity federation is, in essence, an extension of identity management to multiple
security domains. Such domains include
autonomous internal business
units, exter- nal business
partners, and other
third-party applications and services. The goal is to
provide the sharing of digital identities so that a user can be authenticated a
single time and then access applications and resources across multiple domains. Because these domains are relatively
autonomous or independent, no centralized control is possible. Rather, the
cooperating organizations must form a federation based on agreed standards and mutual levels
of trust to securely share
digital identities.
Federated
identity management refers to the agreements, standards, and tech- nologies that enable the portability of identities, identity
attributes, and entitlements across multiple enterprises
and numerous applications and supporting many thou- sands, even millions, of users. When
multiple organizations implement interoperable federated identity schemes,
an employee in one organization can use a single sign- on to access services across the
federation with trust relationships associated with the identity. For example,
an employee may log onto her corporate intranet and be authenticated to perform
authorized functions and access authorized services on that intranet. The employee could
then access their
health benefits from an outside health-care provider
without having to reauthenticate.
Beyond SSO, federated identity
management provides other capabilities. One is a standardized means of
representing attributes. Increasingly, digital identities incorporate attributes
other than simply an identifier and authentication informa- tion (such
as passwords and biometric information). Examples of attributes include account numbers, organizational roles, physical location,
and file ownership. A user may have multiple identifiers; for example, each
identifier may be associated with a
unique role with its own access permissions.
Another key function of federated identity
management is identity mapping. Different
security domains may represent identities and attributes
differently. Further, the
amount of information associated with an individual in one domain may be more than is necessary in
another domain. The federated
identity manage- ment protocols map identities and attributes of a user in one domain to the require- ments of another domain.
Figure 15.4 illustrates entities and data
flows in a generic federated identity management architecture.
The identity provider
acquires attribute information through dialogue and pro-
tocol exchanges with users and administrators. For example,
a user needs to provide a shipping address each time an
order is placed at a new Web merchant,
and this information needs to be revised
when the user moves.
Identity management enables the user to provide
this information once, so that it is maintained in a single
place and released to data consumers in accordance with
authorization and privacy
policies.
Service providers are entities that obtain
and employ data maintained and provided by identity providers, often to support
authorization decisions and to collect audit information. For example, a
database server or file server is a data consumer that needs a client’s
credentials so as to know what access to provide to
that client. A service provider
can be in the same domain as the user and the identity
provider. The power of this approach
is for federated identity management, in which the service
provider is in a different domain (e.g., a vendor
or supplier network).
STANDARDS Federated identity management uses a number of standards as the building blocks for secure identity exchange across different
domains or hetero- geneous systems. In essence, organizations issue some form of security
tickets for their users that can be processed by cooperating partners. Identity federation standards are thus concerned with
defining these tickets, in terms of content and format, providing protocols for exchanging
tickets and performing a number of
management tasks. These tasks include configuring systems to perform
attribute transfers and identity
mapping, and performing logging and auditing
functions.
The principal
underlying standard for federated identity is the Security
Assertion Markup Language
(SAML), which defines
the exchange of security infor- mation between online business
partners. SAML conveys authentication informa- tion in the form of assertions
about subjects. Assertions are statements about the subject issued by an authoritative entity.
SAML is part of a broader collection of standards being issued by OASIS
(Organization for the Advancement of Structured Information Standards) for feder- ated
identity management. For example,
WS-Federation enables browser-based federation; it relies on a security
token service to broker trust of identities, attributes, and authentication between
participating Web services.
The challenge with federated identity
management is to integrate multiple technologies, standards, and services
to provide a secure, user-friendly utility. The key, as in most areas of security and
networking, is the reliance on a few mature standards widely accepted by
industry. Federated identity management seems to have reached this level of maturity.
EXAMPLES To
get some feel for the functionality of identity federation, we look at three
scenarios, taken from [COMP06].
In the first
scenario (Figure 15.5a),
Workplace.com contracts with Health.com to provide
employee health benefits. An employee uses a Web interface to sign on to Workplace.com
and goes through an authentication procedure there. This enables the employee
to access authorized services and resources at Workplace.com. When the employee clicks on a link to access health benefits, her browser is redirected to Health.com. At the same time, the Workplace.com software
passes the user’s identi- fier to Health.com in a secure
manner. The two organizations are part of a federation that cooperatively exchanges user identifiers. Health.com maintains user identities for
every employee at Workplace.com and associates with each identity health- benefits information and access rights. In this example,
the linkage between
the two companies is based on account information and user participation is browser based.
Figure 15.5b shows a second type
of browser-based scheme.
PartsSupplier.com is a regular supplier of parts to Workplace.com. In this
case, a role-based access- control (RBAC)
scheme is used for access to information. An engineer of Workplace.com authenticates at the employee portal
at Workplace.com and clicks
on a link to access information at PartsSupplier.com. Because
the user is authenticated
in the role of an engineer, he is taken to the technical
documentation and trou- bleshooting portion of PartsSupplier.com’s Web site without having to
sign on.
Similarly, an employee in a purchasing role
signs on at Workplace.com and is authorized,
in that role, to place purchases at
PartsSupplier.com without having to authenticate to PartsSupplier.com. For this scenario, PartsSupplier.com does not have identity information for individual
employees at Workplace.com. Rather, the
linkage between the two federated
partners is in terms of roles.
The scenario illustrated in Figure
15.5c can be referred to as document
based rather than browser based. In this third example, Workplace.com has a purchasing agreement with PinSupplies.com, and PinSupplies.com has a business
relationship with E-Ship.com. An employee of WorkPlace.com signs on and is authenticated to make purchases. The employee goes to a procurement application that provides a list
of WorkPlace.com’s suppliers and the
parts that can be ordered. The user
clicks on the PinSupplies button
and is presented with a purchase order Web page
(HTML page). The employee fills
out the form and clicks
the submit button.The procurement application generates an XML/SOAP document that it
inserts into the envelope body of an XML-based message. The procurement application then inserts
the user’s credentials in
the envelope header of the message, together with Workplace.com’s organizational
identity. The procurement application
posts the message to the PinSupplies.com’s purchasing Web service.
This service authenticates the incoming
message and processes the request. The
purchasing Web service then sends a
SOAP message to its shipping partner
to fulfill the order. The message
includes a PinSupplies.com security token in the envelope header and the list
of items to be shipped as well
as the end
user’s shipping information in the envelope body. The ship- ping Web service
authenticates the request
and processes the shipment order.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.