impossible for ideas to compete in the marketplace if no forum for
Federated Identity Management
Contributed by IBM - Tivoli Group
Identity management has become a hot topic with many organizations. From business-unit executives to CIOs to IT administrators, the focus is on improving the integrity of identity-driven transactions, increasing efficiency and lowering IT costs.
Identities pervade every aspect of e-business. Essential accounts — corporate IT (e-mail, NOS, LDAP, UNIX, Linux, Microsoft Windows, RACF®, desktop), Human Resources, supply-chain, health care, employee retirement, online travel and VPN accounts — all must be provisioned in order for new employees or users to do their jobs. Few of these identities and accounts work together, so they add substantial administrative and customer support costs, and the multiple sign-ons to systems and applications result in a poor end-user experience.
With increased corporate governance and regulatory hurdles, the management of these identities and account data introduces new business compliance issues and security exposures. Taking on identity management means dealing with these privacy, compliance, legal and regulatory issues.
The cost and complexity of identity administration in todayâ€™s environment is primarily due to the process of providing a user with access to a service or an application, which means giving the user an account within the service or application-specific repository. The fundamental practice of creating and managing user accounts leads to various administration, single sign-on and compliance issues.
The Case for Federated Identity Management:
IBM® Federated Identity Management addresses this problem by providing a standardized way to manage the end-to-end user lifecycle management of identities both within and between organizations. Such management can simplify identity administration for third-party users (business and partner identities) and provide an opportunity for businesses to hand off this cost to outside parties who manage identity. It also can simplify access administration for the companyâ€™s employees and customers when they visit third-party sites.
A federated business model (in which services are being federated, or shared, with business partner organizations) enables a company to conditionally share identity information and data about their users with trusted third parties. It enables a company to obtain information about a trusted third-party identity (such as customer, supplier, or client employee) from that userâ€™s home organization without having to create and manage a distinct identity account for the third-party user within the company.
This federation approach spares the user from having to register at the company site and consequently having to remember yet another login and password, and can instead use the identity issued by their home organization to access the business Web site. This can result in improved integration, communication and information exchange among suppliers, business partners and customers — leveraging IT to help lower enterprise costs, improve productivity and maximize efficiency in business operations.
At a fundamental level, the term “federated identity” has various meanings. The term identity, used in a federated context, is composed of shared attributes that can be sourced across multiple federated and authoritative data sources. Many attributes can represent a particular identity. The concept of identity should be thought of as a distributed concept where multiple attributes of an identity are federated across multiple data repositories.
To an individual user, federated identity means the ability to associate oneâ€™s various application and system identities with one another. To an enterprise, federated identity provides a standardized means for enabling businesses to directly provide services for trusted third-party users or users whom they do not manage directly. It refers to the ability of enterprises to associate in a federation, in which the identities from one enterprise domain (or identity provider) are granted access to the services of another enterprise (or service provider).
Federated models enable businesses to deliver solutions that can be more functional and cost-effective. These models also enhance customer acquisition strategies via federated business models, which enable service providers to share data with large, established clients, business partners and customers to which they normally would not have access.
Federated Identity Management refers to the set of business agreements, technical agreements and policies through which companies can partner to lower their overall identity management costs, improve user experience and mitigate security risks for Web Services-based interactions.
Advantages of the IBM approach to Federated Identity Management:
IBM has recognized that Federated Identity Management is a solution that can help companies simplify their user administration and security administration while improving security and corporate compliance. This lifecycle management approach enables company administrators to have the visibility, controls and workflow to engage in federated administration with their business partners.
In our approach to Federated Identity Management, we differ from our competition in very fundamental ways:
he IBM Federated Identity Management capability
integrates with IBM middleware offerings, which include WebSphere® Application
Server, WebSphere Portal, WebSphere Business Integration, IBM Tivoli® Identity
Manager and IBM Tivoli Access Manager.
Although the dot-com craze has cooled, business use of the Web is going strong. Over the past several years, Web applications have evolved from simply rendering Web content to becoming sophisticated business productivity tools capable of supporting dynamic and innovative business models while significantly lowering the costs of business integration.
The current downturn in the worldâ€™s major economies and new focus on corporate governance initiatives has driven customers to focus their e-business strategies on lowering expenses, improving transparency and compliance, and increasing efficiencies in their business process with their customers, suppliers and partners. Yet, these same firms are also trying to drive organic growth and derive new or additional business by increasing customer loyalty and delivering a superior customer experience and satisfaction through better personalization and service delivery. Many companies are also looking at strategic customer-self-service initiatives combined with automation to reduce customer support and ongoing customer care costs.
Executives are looking to fund initiatives that result in:
The Federated Identity Management solution delivers a compelling proposition across all these of initiatives. Organizations need to share data and business process, and federated identity provides this link. It enables businesses to deliver solutions that can be more functional and cost-effective. The federated business model enables service providers to federate data to large established clients, business partners and customers to which they normally would not have access.
Federated Identity Management enables IT to lower enterprise costs, improve productivity and enhance efficiency in business operations by improving integration, communication and federated data information exchange with suppliers, business partners and customers. The return on investment in identity management software can improve the bottom-line savings resulting from user lifecycle management costs. Because identities pervade every aspect of business interaction with customers, partners, suppliers and service providers, the ability to simplify and streamline identity management and administration costs within the business ecosystem has become a strategic focus for executives.
Another important focus for top executives is improving corporate governance. Because identities affect every aspect of e-business, a focus on improved governance directly translates to implementing improved management of the issuance, approval, and termination of identities and access rights. This problem takes on a new dimension when companies allow third-party users to access their internal systems where, in many instances, companies cannot account for these third-party users and do not know who approved their access or for what business purpose.
Identity management challenges:
A typical enterprise deals with at least three major clusters of identities, as shown in Figure 1.
Attaining these goals using IT as a productivity lever has been both problematic and challenging. In the IT world, seemingly simple things such as managing identities and exchanging identity information within a firmâ€™s heterogeneous systems is a challenge, as is trying to deliver data transparently to users from across a network of business partners and affiliates. Fundamental issues such as end-to-end identity propagation are lacking, and they present significant challenges to integrating identities (and identity management techniques) seamlessly into the application and middleware.
A quick survey within a typical large organization reveals many forms of identity accounts that are provisioned by the employer to employees, consultants and contractors.
The unique element in B2C is the scale: Millions of
these identities and accounts must be maintained.
The situation described above is not hypothetical, but reality in many companies. Inefficiencies related to identity management and administration are a major business pain point.
This paper discusses the business and technical drivers for a Federated Identity Management solution from IBM, as well as product and solution capabilities. Built on open security standards such as WS-Security family, Liberty and SAML, and coupled with tight integration of identity management capability with middleware solutions, IBM security solutions enable you increase the reach of your business through applications, building on existing Web security investments to take advantage of Web services and federation standards. This paper is aimed at CIOs, CISOs, e-business and security architects, and other interested technical professionals and early adopters of federated identity management solutions.
The IBM security strategy for Federated Identity Management is a multi-pronged approach:
To put the strategy and product roadmap in context, this paper also highlights the functions and benefits of Web Services and Federation standards, and discusses what Web Services and Federation cannot do.
Customer Pain Points
One of the biggest challenges customers currently face is cost and complexity of user lifecycle management, which is also referred to as the multiple identity account problem, as users in most large companies have to deal with more than 50 accounts. Customer pain points can include:
The fundamental issue pervading identity management is that every time a user requests access to an application or a system, an IT administrator ends up creating an account for the user in the target system or application. A company takes on a significant cost of user administration and management when creating accounts for users.
User provisioning and account management costs:
The cost of provisioning users with account data is one of the more expensive manual activities in terms of people, time and IT budget. While tools can automate (synchronize) many aspects of user provisioning, the fundamental issue remains: A company takes on user-ownership costs when provisioning account data. While a company may need to take on this cost for employees, this approach may not be correct when dealing with external identities that are being provisioned in the companyâ€™s internal systems.
Various provisioning activities that a company can undertake to provision access rights include:
Every time an account is created, an IT infrastructure provider buys into a set of management pain points. The key question for an IT provider becomes, “Do I have to create and manage this account, or is there a better way to manage access for this user?”
The company can reduce the cost of provisioning suppliers, business partners, consultants, brokers and other third-party users: By federating user access to these third-party users, companies can effectively offload related user-administration costs back to the provider who has direct responsibility for managing the user.
User Registration and Enrollment Costs:
There are costs associated with registering and enrolling a new user in the systems. These costs accrue from the administrative processes that must be deployed across multiple customer care channels including the Interactive Voice Response (IVR), Web and sales channels. These administrative processes require vetting the user registration data, collecting approvals and integrating customer care processes to handle provisioning of user access rights and entitlements. Many service providers, such as managed health care providers, incur significant customer care costs (for their “client” employees) every year during plan enrollment. These managed health care or financial providers deliver services to their clientsâ€™ employees. As a result, in todayâ€™s business model, these providers end up with the responsibility of identity management, password management and customer care for their client employees. Users call into the service provider support desk when they cannot remember their online user name or ID or PIN number or are having difficulties with registration.
This cost of user administration can be significant
for most service providers and presents recurring overhead costs. If a provider
has 500 Fortune 1000 clients (a client here refers to a company) and each client
has on average 20,000 employees whose health care must be managed, the provider
is now supporting and servicing 10 million accounts. A federated model in which
the service provider trusts its clients to provide the user information
considerably simplifies user administration costs because user service costs are
being handled by the clients, not the provider. In this model, when an employee
cannot access the health care enrollment page (for whatever reason, such as
forgotten user ID or password) they call their local help desk for assistance.
According to Earl Perkins, Vice President of the META Group, “Studies by META Group and others have shown that costs for help desk calls related to passwords can range upward to $30 US per call, depending on the nature of the identity-related problem, thus rendering alternatives that automate or relieve such calls attractive to IT organizations.”
Therefore, most providers have an incentive to lower password management costs by either automating password resets or avoiding this password management problem altogether. Federated Identity Management presents an opportunity to avoid this problem by enabling organizations to leverage their business partner to manage these passwords and credentials.
A causal analysis of these pain points shows that this behavior of creating and managing accounts has been around for a long time, perpetuated by technology gaps in dealing with identities:
Federated Identity is a solution for creating a globally interoperable online business identity for driving relationship- or affinity-driven business models between companies. The concept is nothing new, as we have real-world models for federated identities of individuals: a passport is a global identity credential that vouches for oneâ€™s identity in a country; an ATM card is a credential that vouches for oneâ€™s bank account; a driverâ€™s license vouches for oneâ€™s ability to operate a motor vehicle and is also frequently used as a proof of identity in many business transactions.
Federated Identity Management is the set of business agreements, technical agreements and policy agreements that help companies lower their overall identity management costs and improve user experience. It leverages the concept of a portable identity to simplify the administration of users in a federated business relationship. The simplification of the administration and the lifecycle management of users in a federation leads to the following value proposition:
Business models for Federated Identity Management:
Seldom is there a process whereby the company is notified that a business partnerâ€™s employee is no longer employed; hence the company has an orphan account problem. Federated Identity Management improves compliance by offloading user administration costs to partners, thereby addressing the orphan-account problem created by third-party access. Because the company does not own the user account management accountability, approvals and recertification are offloaded to partners. The company relies on its partners to authenticate and issue credentials that vouch for its users. The burden of proof now belongs to the partner for vouching for its own access rights. Federated identity provides a strategic alternative for companies to simplify their administration and improve governance by offloading third-party user management to their clients.
Trust and Assurance:
A federated business model mandates a foundation of trust. In a federated model, an organization is willing to provide access to an identity that is not vetted by the organizationâ€™s own internal security processes. Instead, the organization trusts an identity asserted by a third party, a model that introduces risk and uncertainty in the overall confidence of the business transaction.
An organization will not engage in a federated business model if it does not have the ability to understand how partners are managing their users. Organizations must evaluate the risk of conducting business with partners and assess their partnerâ€™s processes and vetting procedures for 1) partner identity proofing, 2) partner accreditation, and 3) partner reputation evaluation. These procedures provide the visibility and the qualitative assessment of how third-party identity In a federated business model, an organization trusts an identity asserted by a third party can be parlayed into business decisions about access control and the rules of engagement around trust that the organization is willing to enter with the partner company.
Business partner identity proofing is the process of verifying the physical identity of a prospective federation business partner both before entering into an online business relationship with that business partner and when engaged in runtime transactions with the business partner. Part of the partner identity proofing process involves verification of the physical identity of the business - but who is the business?
After the physical identity has been verified, some form of online token is issued to the business partner and then bound to the physical identity of the business. Various forms of business partner identity verification techniques and processes can be used, including:
Business partner accreditation addresses the questions “what do we know about the company?” and, more specifically, “what do we expect of this company?” Accreditation is based on a policy that defines the criteria that a company must satisfy. A company that wishes to enter into a federation may publish a policy that defines the criteria that prospective partners must match; likewise, a partner wishing to enter a federation may publish a policy that defines the criteria that IT satisfies (a policy describing its own features). Evaluating the appropriateness of these two policies is an action that is undertaken by a trusted party specializing in business accreditation.
Partner accreditation is
based on a policy that defines the criteria that a company must satisfy.
Reputation is an alternate means of knowing additional qualitative information about a business. The primary difference between a reputation service and accreditation is that reputation typically is measured on an ongoing basis using behavioral information about the business or an individual. Another difference is that reputation is typically measured by an independent entity and typically does not involve the participation of the subject (the business or individual being measured). The reputation service may develop an automated framework for measuring reputation based on transactional visibility. Alternatively, a more explicit feedback based mechanism is used. The reputation service will usually assign a simple score that is derived using a well-defined procedure and is easy to understand.
Organizations face critical challenges in
determining the risk/return relationship in a federated model. Business partner
identity verification, accreditation and reputation are basic tenets that help
companies determine their level of trust and assurance in their partnersâ€™
identity management solution. An alternative to accreditation, a reputation
service uses ongoing behavioral information
A federation is a group of two (or more) trusted business partners with business agreements, including liability restrictions placed on the business partners. Participation in a federation allows a user from one federation business partner (participating company) to seamlessly access resources from another business partner in a secure and trustworthy manner. This enables end users to easily accomplish the tasks they need to complete cross-company business transactions. This in turn promotes cross-company business in a loosely coupled environment.
Federations are entered into to facilitate two major types of functionality:
Both of these functionality types involve the same trust infrastructure to provide the technical representation and implementation of the business agreements between business partners. Thus the implementation of this functionality leverages the same infrastructure. After this, the similarities largely stop.
Currently, federated identity management almost exclusively refers to user-driven, browser-based interaction between organizations. The main inhibitor in this space is the lack of a trust mechanism that allows a user to view this federation space as a single entity; instead, the user is forced to enroll and authenticate to each partner and each partner is forced to manage the associated user lifecycle process. Federated identity management is targeted at this pain point, layering (HTTP) browser-based reduced-sign-on and identity-lifecycle functionality over the federation trust infrastructure.
Web Services security targets the secure interoperability of applications or programs. Web Services provide a flexible and easily adoptable means of integrating applications. Web Services security defines how to do this in a secure manner. This includes securing the message through signatures and encryption. It also includes authenticating and authorizing requests based on the Web services invokerâ€™s claimed identity. This identity is represented with a Web Services security token; this process of authenticating a principalâ€™s identity (be it user or application) is a form of reduced sign-on. However, unlike the federated identity management reduced sign-on described above, this occurs in what is often referred to as an active client environment. This means that the applications that are invoking Web Services can assert their claimed identities in a Web Services request without having to negotiate a separate (dedicated) single sign-on protocol.
IBM provides functionality to implement the trust infrastructure that is used by both of these solutions; this functionality is provided by a trust service. Layered over the trust service functionality are two largely independent yet complementary solutions: IBM Federated Identity Management and on demand Web Services Security. The trust service infrastructure and the Federated Identity Management solution are described in more detail in this paper; on demand Web Services Security will be addressed in a separate paper.
Federation models can be successful only if they enable customers, business partners and end users to navigate easily between federation partners without having to constantly enroll on different Web sites or having to authenticate or identify themselves as part of the completion of a task. Unfortunately, current implementations for authenticating users and getting user attribute information typically force the user to register with each business of interest, constantly require the user to identify and authenticate themselves (typically with a user name and password), and force each business to administer a large and rapidly changing base of identities. Such a model is an impediment to the adoption of federations — and is a major pain point for both users and businesses.
Federations are intended to simplify the adoption and integration of business partner resources. This is accomplished by offloading the expensive part of user lifecycle management across business partners - the cost of account management (including creation, deletion), user enrollment for business partner services, account linking and de-linking, password and attribute management, and user care issues - to one partner (an identity provider).
Federations provide a simple mechanism to identify and validate users from business partner organizations and provide them with seamless access to Web sites within that trusted federation: Users are not required to re-authenticate at each federation business partner site, and federation business partner sites are Federations facilitate an integrated approach to business not required to manage large sets of user data, including the cost of managing authentication credentials for large numbers of users. And those federation business partners that have the ability and infrastructure to manage these users can maintain and control the customer relationship by providing a user with a single point of entry into a federation.
Federations also simplify user access to third-party service providers. Using federated identity technologies, the company portal can be extended seamlessly to third-party Web sites, software-as-service providers and application services that are not locally hosted.
In either type of federation, the end user wants to
be able to have a seamless online experience while accessing resources within a
Federated Identity Management refers to the set of business agreements, technical agreements and policies between two or more companies in an effort to lower their overall identity management costs, improve user experience, reduce company pain points and mitigate security risks for transactions.
This table defines the IBM Federated Identity User Lifecycle Management capabilities to implement a complete federated identity management solution.
Federated Identity Management solutions layer browser-based single sign-on and identity life cycle functionality over a federation trust infrastructure. The functionality of single sign-on, with which a user can authenticate once to an authoritative site and then gain access to other related sites with minimal interaction, is just one aspect of a fully functional Federated Identity Management solution.
To provide a user with a seamless federation experience, an identity provider and a service provider must cooperate to provide several housekeeping activities that address user account creation and provisioning, account linking, single sign-on, identity and attribute mapping, single logoff, and account de-linking and de-provisioning. All of these capabilities, when implemented together, provide the user with a seamless online experience, from account creation to account deletion or inactivation.
In the following sections, we introduce these additional requirements and describe one implementation of them in an example using myemployerx.com and benefitsx.com.
An organization typically will be willing to pursue a federation model when it can rationalize the benefits of such a solution against the risks of supporting a business model that is based on third-party trust. However, a federated model is less desirable when it does not have the same visibility of lifecycle management of third-party users as it does with its direct users. Federated identity lifecycle management is an approach to delivering the same kind of visibility around an identity-related business process when organizations begin to loosely couple disparate identity management systems across trust domains.
One of the most pressing issues for IT administrators is to have the control that is needed to implement technical policies and operational best practices, implement and enforce security and identity agreements, and audit agreements and privacy agreements so that the federated relationship looks like an extension of their existing identity management procedures.
Identity Provider and Service Provider Roles:
Within a federation, Federated Identity Management business partners play one of two roles: identity provider or service provider. The identity provider (IdP) is the authoritative site that is responsible for authenticating an end user and asserting an identity for that user in a trusted way to trusted partners. Business partners who offer services but do not act as identity providers are known as service providers (SP). The identity provider takes on the bulk of the userâ€™s life cycle management issues. The service provider relies on the identity provider to assert information about a user, leaving the service provider to manage only those user attributes that are relevant to its services.
The identity provider is responsible for account creation, provisioning, password management, and general account management and acts as a collection point or client to trusted identity providers. Having one federation business partner act as a userâ€™s identity provider relieves the remaining business partners of the burden of managing equivalent data for a user. These other business partners act as service providers who leverage their trust relationships with an identity provider to accept information that is provided on behalf of a user, without the userâ€™s direct involvement. This enables service Identity providers to offload identity and access management costs to business partners within the federation.
In the example that follows, myemployerx.com acts as an identity provider that is responsible for authenticating its users (employees) and for managing their userâ€™s life cycle (account creation, deletion, attribute management, authentication credential management). On the other side of the relationship, benefitsx.com acts as a service provider. benefitsx.com does not directly authenticate users; it relies on information asserted by myemployerx.com to identify a user (John Doe) and build Johnâ€™s local session without his direct involvement.
A service provider may still manage local
information for a user, even within the context of a federation. For example,
entering into a Federated Identity Management relationship may enable a service
provider to hand account management (including password management) to an
identity provider while the service provider focuses on the management of its
user-specific data (such as information related to service-specific attributes
and personalization). In general, a service provider will offload identity
management to an identity provider to minimize its own identity management
requirements while maintaining full service-provider functionality.
The potential benefits of federation and Federated Identity Management are best described by a simple example. Consider a scenario with three entities:
myemployerx.com is the anchor of this federation relationship. It owns a user registry containing information about all of its employees and is responsible for managing the lifecycle of its employees, from account creation to account deletion and inactivation.
myemployerx.com enters into a business federation with a benefits provider, benefitsx.com. benefitsx.com will offer a set of benefits for myemployerx.com employees and thus will handle information about these employees that is relevant to day-to-day management of their benefits.
John Doe has an account at myemployerx.com, contingent on his employment, that he uses to access the myemployerx.com resources that he needs for his job. If John takes a leave of absence, this account may be suspended. If he seeks employment elsewhere, this account may be terminated.
John also has a sponsored account with benefitsx.com, the third-party benefits provider to myemployerx.com. Johnâ€™s account with benefitsx.com is considered sponsored because it was created as a direct result of his status as an myemployerx.com employee. John can access his benefits information through the myemployerx.com employee portal, which redirects John from myemployerx.com to benefitsx.com in order to access his benefits information.
Without federation, John has to authenticate to the benefitsx.com site to access his benefits account, even though he has already authenticated to myemployerx.com and has accessed the Benfits.com services through his employee portal.
By entering into a federation relationship, benefitsx.com can reduce its overall cost of managing users mainly by participating in single sign-on with myemployerx.com and no longer directly managing Johnâ€™s authentication credentials, which is often an expensive part of user lifecycle management.
From Johnâ€™s point of view, having benefitsx.com and myemployerx.com participate in a federation relationship with reduced sign-on enables him to authenticate only once, to myemployerx.com, and then access his benefit plan information without having to explicitly re-authenticate.
This is achieved with federated reduced sign-on.
Federated reduced sign-on between an issuing domain (myemployerx.com) and a relying domain (the federated service provider benefitsx.com) facilitates the secure and trusted transfer of user identifiers and other attribute-related information (such as authorization roles, group memberships, user entitlements and user attributes such as employee ID and Social Security number).
All that is required is that benefitsx.com be able to participate in a runtime exchange of information with myemployerx.com that results in an assertion from myemployerx.com. (This information exchange requires no interaction with John.) The assertion is trusted by benefitsx.com and used to uniquely identify John based on an myemployerx.com asserted unique identifier. Using this information, benefitsx.com can locally identify and provide John with access to his benefits account information.
Note that both myemployerx.com and benefitsx.com
must maintain information about John. Some attributes about John are best
managed by myemployerx.com, such as his home address and telephone number.
Likewise, there will be information about Johnâ€™s benefits that are clearly not
appropriate for myemployerx.com to manage on behalf of benefitsx.com. Thus it is
possible for benefitsx.com to personalize a userâ€™s experience based on
User identity provisioning plays a fundamental role in a federated business model. In a federated model, two companies engage in a business partnership to simplify identity administration and access to resources by using a common identity framework. The result is that users can navigate between Web sites inside a federation without having to enroll or re-authenticate at each site.
In a federated model, an identity provider and service provider must agree on what user identity information they can share and what information must be managed independently. This information is composed of classes of data that concern an identity:
or each class of identity data, we can allow for a shared or distinct identity data management solution. When sharing credentials for higher-assurance applications, strong credentials should be used where possible. Organizations that need to trust third-party credentials will place higher assurance, and therefore lower liability, on a stronger credential. Thus, when examining the provisioning requirements for a federated model, we evaluate the shared/distinct nature of each of the classes of identity data as in the following table.
Distinct Versus Shared Identity Models:
Distinct and shared identity models refer to the nature of the identity data management. Distinct identity data management solutions imply that information is replicated across partners and managed separately across partners. A shared identity data management solution implies that information can be managed by one partner (the identity provider).
A “distinct identity” approach to federated business interactions may be appropriate when the two organizations cannot share identity information. This may happen because of anti-competitive practices, separation of data, disintermediation (companies unwilling to share customer data with partners for competitive reasons), political reasons, or because the user has an independent relationship with both providers.
With a distinct identity data management model, identity data may be initially provisioned across partners as part of account setup, although it will be managed independently (outside the scope of a provisioning solution) after this.
A shared identity approach to federated business interactions may be appropriate when one partner can trust and rely on the assertion of a userâ€™s identity data by an identity provider. In this model, federation enables the user (and the federation partners) to establish a common unique identifier to use to refer to the user. Based on this common identifier, an identity provider can manage a userâ€™s identity data, acting as the authoritative source of this information to trusted service providers.
The fundamental question with respect to identity and attribute provisioning between business partners is what information can they share and what benefits can be gained by sharing. In an optimistic scenario, an identity provider and service provider share every piece of information about the user.
Provisioning plays an important role in enabling identity providers and services providers to share a common identity framework without the need to share identity information about their users. In the following sections, we describe how these classes of attributes can be managed through various provisioning solutions.
Authentication credentials are the information that is used to authenticate an identity. This information is bound to a userâ€™s identifier (such as a user name or logon identifier). The authentication credentials themselves are represented by data such as a password or a one-time-generated PIN number from a hardware token. These credentials are presented by a user as part of the authentication process and used to prove (authenticate) the userâ€™s claimed identity. This implies that to authenticate a user, a federation partner must have a copy of the userâ€™s authentication credentials or some other means of validating these credentials. Thus current models of authentication require a distinct identity data model, meaning that each business partner has a copy of the userâ€™s authentication credentials.
One goal of a federated model is to move to a shared identity data model. With authentication credentials, this implies that a federation business partner be able to trust a third party (an identity provider) to evaluate the userâ€™s authentication credentials and to assert some form of secure, trusted information that can be used to vouch for the userâ€™s successful authentication at the identity provider. Thus in a federated model, authentication credentials may be extended to include security tokens from an identity provider asserting the userâ€™s identity.
Moving to a shared model for authentication credentials means that federation business partners can act as service providers and no longer have to manage the class of identity data that includes authentication credentials. Provisioning solutions are used to tie the identity account management at an identity provider to that at a service provider.
Provisioning Authentication Credentials:
A shared identity approach to federated business interactions may be appropriate when one business partner can trust and rely on the assertion of a userâ€™s identity by an identity provider without having to independently validate the userâ€™s authentication credentials. In this model, federation enables the user (and the federation partners) to establish a common unique identifier to refer to the user, where this identifier reveals no information about the user at either partner. Based on this common identifier, an identity provider can issue single sign-on information to federation business partners.
In a shared identity model, there is no need to provision authentication credentials, but a common identifier used by the two business partners must be established. To accomplish this, there may also be a need to establish a local identity account to which this common identifier is bound. These requirements can be handled through federated provisioning solutions.
Federated provisioning is generally accomplished with one of two types of provisioning: runtime (also known as just-in-time) and a priori provisioning.
The runtime provisioning solution also refers to enrollment solutions when used within the scope of a single sign-on exchange. Runtime provisioning solutions enable federation business partners to establish a common identifier and update attributes (such as enrolling a user for services) as part of a single-sign-on exchange. Runtime provisioning solutions may also be used to establish an account for a user at a service provider within the scope of a single sign-on exchange. In this case, federated provisioning provides a “silent registration” functionality; the user does not see (or participate in) a separate registration/enrollment step.
A priori provisioning may be used for account management (such as creation, deletion, and modification; status update) as well as attribute management. When used for account management purposes, a priori provisioning provides a process by which a user account creation request can be sent to federation partners outside the scope of a single sign-on request. This enables both the identity provider and service provider to create local accounts and registry records for a user in response to a single action at the identity provider. Note that when used as part of account creation, a priori provisioning, like runtime provisioning, will result in the establishment of a common user identifier at both the identity provider and service provider.
In the case of myemployerx.com, provisioning a new employee within the myemployerx.com system will generally cause account creation of the userâ€™s myemployerx.com required accounts. A federated provisioning solution will also cause the sending of a provisioning trigger request to benefitsx.com. This trigger request is used to trigger a provisioning event by the benefitsx.com provisioning system, allowing benefitsx.com to establish an account for this new user. As this account is created in response to a request from myemployerx.com, the common user identifier information will have been included with the provisioning request and so no account linking step is required by this new user. Note that the result of this process is that the user will have almost immediate access to benefitsx.com resources, and may not even know that benefitsx.com exists as a separate provider.
Runtime, or just-in-time, provisioning allows a service provider to create a user account and record in its local registry in response to a single sign-on request from a trusted identity provider. This may happen when a service provider receives a single sign-on request from a trusted identity provider but does not have any record of the user claimed in the request. Instead of rejecting the request, the service provider may chose to create a user record based on the claimed common unique identifier (CUID). The CUID-local identity mapping is therefore established at this time — in fact, the service provider is not required to ever establish its own, non-CUID local identity for this user.
In general, a distinct identity account data model does not involve a provisioning solution. The user in this federation model has distinct identity accounts at both of these business partners, maintained and administered independently at both the identity provider and service provider. With a distinct identity data management model, identity data may be initially provisioned across partners as part of the initial account setup, although it will be managed independently (outside the scope of a provisioning solution) after this.
There may be some cases where this is not true, such as when the user does not already have a distinct, authenticable account at both the identity provider and the service provider. In this case, the identity provider may trigger a provisioning event at a business partner to create a local identity account and identity account data for a user. Part of this action may include establishing a common identifier that will be used by the two partners. As with the shared data approach, provisioning solutions when invoked within a distinct identity model may come either runtime (just-in-time) or a priori provisioning, as described previously.
Transactional attributes include information that describes a user and the userâ€™s affiliations and entitlements. This information is bound to a userâ€™s identifier. This may include groups that the user belongs to or roles that the user can assume. This data may also include additional identifiers (such as customer ID number, 401(k) account number, frequent-flier status level, health care number, supplier ID, or billing or credit card number), specific organizational roles (such as HR manager, stock broker, benefits administrator, primary care physician, executive or supervisor, or travel exception approver).
This information is often used as part of authorization/access control decisions at a transactional level (for example, whether this HR manager can update this employeeâ€™s personnel evaluation). This information about a user is not normally managed by the user. In general, a userâ€™s transaction attributes are not common across all identity and service providers — not all of these attributes are relevant to all identity/service providers.
Provisioning Transactional Attributes:
Sharing of transactional attributes enables one of the parties (usually the identity provider) to act as the authoritative source of transactional attribute information about a user. This attribute information can then be provisioned to a service provider in an a priori manner, meaning that whenever this information is updated at the identity provider, an a priori provisioning request will attempt to update this information at the service provider. This attribute information can also be provisioned in a dynamic, or just-in-time, manner, meaning that new or updated information is included as part of a single sign-on response to the service provider, or in response to a direct request from the service provider.
Provisioning solutions enable the identity provider to create or update a userâ€™s transactional attributes such as entitlements to service providers as required. These attributes are typically managed by the end userâ€™s identity provider. In the case of myemployerx.com, John may have a corporate credit card that he uses for travel purposes. If this credit card number changes, myemployerx.com may be required to provision this transactional attribute to myemployerx.comâ€™s travel agency. Similarly, Johnâ€™s salary may be considered a transactional attribute as it will be used by benefits providers to determine Johnâ€™s eligibility for services. As such, it must be provisioned to myemployerx.comâ€™s benefits providers if it changes.
When transactional attributes are distinctly managed within a federation, each federation business partner is responsible for the day-to-day management of these attributes. This means that a provisioning solution is not implemented as part of the day-to-day management of these attributes.
With a distinct identity data management model, transactional attributes may be initially provisioned across partners as part of the initial account setup, although they will be managed independently (outside the scope of a provisioning solution) after this. Note that because transactional attributes typically are not managed by the end user, this day-to-day management must be handled by the service providerâ€™s administrators.
Profile attributes represent auxiliary information that is not primarily tied to authentication or authorization decisions. Profile attributes may be information that is specific to the user identity, such as e-mail address, home address, birth date, and telephone number. Identity profile attributes also include preference or personalization attributes such as a userâ€™s frequent flier number, location information, and preferences and subscription information (for example, user subscribes to The New York Times). This information may be used as part of secondary user-identity validation (as part of a lost-password recovery process).
This information may be used as part of an access control decision in scenarios where access is controlled by (for example) a userâ€™s age or state of residence. This information about a user normally is managed by a user. In general, a userâ€™s profile attributes are consistent across identity and service providers.
Provider-specific attributes represent auxiliary information that is relevant only to the service provider in question. This information will never have to be shared with other business partners. This information is not relevant to a provisioning or enrollment solution.
To put this into a familiar context, consider a user, Jane, who participates in a frequent flier program with her airline of choice. Jane has an online account that she uses to check her airline activity; this account is bound to her identity, JaneD. Associated with this user name is Janeâ€™s password (authentication credentials) that is used to authenticate to the airline system. Associated with Janeâ€™s airline account are Janeâ€™s profile attributes (her home address, e-mail, telephone number). Based on Janeâ€™s frequent flier account, the airline will assign (and manage) Janeâ€™s frequent flier status (a transactional attribute). When attempting to access the account status resource to check her frequent flier miles balance, Jane is required to authenticate with her authentication credentials. If Jane attempts to book rewards travel based on her airline points, the decision about which inventory to display will be made by the airline based on Janeâ€™s status as a premier flier. After Jane has selected her desired travel and is about to book it, secondary vetting of Janeâ€™s identity will be accomplished as part of the specification of Janeâ€™s home address (to which the ticket confirmation information is to be sent).
Provisioning Profile Attributes:
Sharing of profile attributes enables one of the parties (usually the identity provider) to act as the authoritative source of profile attribute information about a user. This attribute information can then be provisioned to a service provider in an a priori manner, meaning that whenever this information is updated at the identity provider, an a priori provisioning request will attempt to update this information at the service provider. This attribute information can also be provisioned in a dynamic, or just-in-time, manner, meaning that new and updated information is included as part of a single sign-on response to the service provider, or in response to a direct request from the service provider.
Provisioning solutions enable the identity provider to create or update user profile attribute information such as e-mail, person information, address, membership or subscriber information, and service-specific attributes about a user to service providers. These attributes are typically managed by the end user as part of their profile information at their identity provider.
When profile attributes are distinctly managed within a federation, each federation business partner is responsible for the day-to-day management of these attributes. This means that a provisioning solution is not implemented as part of the day-to-day management of these attributes.
With a distinct identity data management model, profile attributes may be initially provisioned across partners as part of the account setup, although they will be managed independently (outside the scope of a provisioning solution) after this. Because profile attributes are often managed by the end user (as part of their profile information, for example), it is the end userâ€™s responsibility to ensure that all instances of a particular profile attribute are consistent across all business partners within a distinct identity data management model.
Provider-specific attributes include both
transactional and profile attributes that are relevant for a given user at a
given service provider; these attributes have not shared with other service
providers. Examples of provider-specific
A userâ€™s provider-specific attributes are just that; they are distinct attributes that are not shared across federation business partners and are not required to be managed through a provisioning solution across partners.
When organizations are initially provisioning attributes, sharing them or updating them, the attributes should be signed by the sending organization to ensure that there are steps in place for non-repudiation and basic authentication between the Web services. As with any Web services deployment, there should always be safeguards in place to ensure for audit capabilities because the involved parties now span multiple organizations.
Federated Reduced Sign-On:
Reduced sign-on is the process by which a user authenticates to a federation business partner (an identity provider) and has the identity provider assert a relevant identity and attributes to any or all required (and trusted partner) service providers as part of the userâ€™s online federation experience. Reduced sign-on itself is provided by a federated single sign-on protocol. (See “Federated Identity Management standards and efforts”) These protocols provide standard, interoperable means for multiple federation business partners to negotiate the presentation of credentials about a user from an identity provider to a (trusted) federation service provider.myemployerx.com acts as the identity provider in our example. This means that it can validate authentication credentials (typically, a user name and password) that John presents in his attempt to access the company portal. This enables myemployerx.com to set up a valid session for John and to provide a personalized “portal” for John. This company portal may well include general company information, news clips, stock quotes, and links to myemployerx.comâ€™s many benefits providers.
At some point during the day, John wishes to check his benefits allocation with benefitsx.com. Clicking the benefitsx.com link at the company portal will cause John to be redirected to benefitsx.com. With a federated single sign-on solution in place, myemployerx.com can implement a “push-based” single sign-on protocol such that John will be redirected to benefitsx.com with a (trusted) security token that identifies John to benefitsx.com.
This security token is used by benefitsx.com to validate that John came from myemployerx.com and to determine Johnâ€™s local benefitsx.com identity based on the common user identity asserted by myemployerx.com. As a result of this validation of the security token, benefitsx.com will be able to establish a local session for John and appropriately manage Johnâ€™s experience at benefitsx.com.
At some point later that evening, after John has gone home, he again wishes to check his benefits allotment. Because John is not attempting to access benefitsx.com through his company portal, he uses a bookmarked reference to attempt to directly access benefitsx.com. In this case, John is not redirected from myemployerx.com and so is not participating in a push-based SSO (single sign-on) protocol. Instead, benefitsx.com must determine who Johnâ€™s identity provider is (myemployerx.com). Based on this information, benefitsx.com initiates an SSO request from myemployerx.com, which may need to authenticate John to determine his local identity. Having done this myemployerx.com will be able to complete the SSO request from benefitsx.com. This is a pull-based SSO protocol. Single sign-on follows because John authenticates once (to myemployerx.com) and is granted access to benefitsx.com without additional authentication requirements.
Note that a fully functional federated SSO solution should not preclude behavior by John that requires both push-based and pull-based SSO protocols.
When a user has multiple login accounts at various
sites or companies, navigating among these Web sites can be a cumbersome
activity and can create a poor user experience. The user has to remember
multiple site identity account names and passwords to access services on these
Web sites. Account linking provides a simple mechanism for the user to link
these distinct identity accounts with different Web sites if the various
companies or Web sites agree to this concept. The purpose of account linking is
to deliver single sign-on user experience with the various providers who are
part of this agreement. After accounts are linked, the user can authenticate to
one provider and then navigate seamlessly to various service providers with whom
they have linked accounts without having to re-authenticate or enroll.
Consider “A simple federation example” (shown earlier), where John has distinct (can be authenticated) identity accounts at each company. When the two companies agree to join a federation, they must enable myemployerx.comâ€™s employees for SSO to benefitsx.com. In general, this will happen based on functionality at benefitsx.com. This happens through a two-step process, which in this case is initiated from the myemployerx.com site. myemployerx.com changes the functionality at the company portal, so that instead of a simple redirection to benefitsx.com, the clicking of a link to benefitsx.com initiates single sign-on to benefitsx.com. benefitsx.com receives this single sign-on request but is not able to map the user to locally known user. This causes benefitsx.com to prompt John for his benefitsx.com authentication credentials. Successful authentication by John now gives benefitsx.com the myemployerx.com asserted CUID (from the SSO request) and its own local representation of the user (from Johnâ€™s direct authentication). benefitsx.com can now establish the account linking that enables this user to SSO from myemployerx.com.
If users access benefitsx.com directly during the
roll-over period, they can be authenticated by benefitsx.com as usual. After
this, benefitsx.com will request SSO from myemployerx.com (for the already
authenticated user). The corresponding SSO response contains the common user
identifier (CUID) so that benefitsx.com has the myemployerx.com asserted CUID
(from the SSO request) and its own local representation of the user (from Johnâ€™s
direct authentication). benefitsx.com is now able to establish the account
linking that will allow this user to SSO from myemployerx.com. benefitsx.com may
choose to disable the userâ€™s local password, so that direct authentication to
benefitsx.com is no longer possible while the userâ€™s account is linked with
myemployerx.com. The next time this user attempts to access benefitsx.com
directly, benefitsx.com will request an SSO from myemployerx.com.
Where are you from?
Some service providers may have trust relationships with multiple identity providers. This means that a user may possibly initiate SSO from one of many identity providers. For the service provider, the process of determining which identity provider to request SSO from is referred to as Where are you from? and is a process by which a user may specify a preference for a given identity provider for SSO purposes. This information is maintained by the service provider so that it can easily determine, without user interaction, which identity provider to request SSO from for future requests.
Note that in the benefitsx.com scenario, the Where are you from? information is established during the roll-over period. During this time, benefitsx.com acts as both a service provider (for already federated users) and an identity provider (for not-yet-federated users).
After benefitsx.com has turned off direct authentication of a user, it must rely on some form of persistent information that is associated with a user (such as an HTTP cookie) to identify to which identity provider an SSO request is to be directed. If this cookie is absent, then benefitsx.com must engage in some form of user-interactive Where are you from? processing. benefitsx.com may choose to prompt John to select such an identity provider from a list of known/trusted identity providers (such as all of the employers for whom benefitsx.com acts as a benefits provider). In some cases, a service provider may not be willing to expose a list of trusted identity providers, so John might be given instructions by benefitsx.com to directly access his identity provider (myemployerx.com) and initiate an SSO request through an identity provider-based mechanism.
While this does involve a level of interaction with the user, neither situation is as intrusive as requiring that the user remember a benefitsx.com password. Ideally, user-interactive Where are you from? processing should not be required every time John accesses benefitsx.com.
Session Management and Access Rights
After a user has performed a single sign-on to a service provider, the service provider is responsible for managing the userâ€™s local session. This includes authorization decisions about the userâ€™s requested actions and session management itself, such as logout or session timeout.
This implies that the service provider can manage some level of user attributes or credentials, which are used to determine local access privileges. The identity provider may manifest these access privileges in the form of asserted attributes about a user, such as group membership. This information may be used by the service provider as an indication of the types of actions that are allowed by the identity provider (or actions that will be honored by the identity provider on the userâ€™s behalf). The service provider can honor or disregard these attributes as required for its local behavior.
some federation scenarios, the notion of global logout is also required. This enables a user to invoke a logout of all sessions that are asserted by a given identity provider. Global logout can be requested by a user from either the identity provider or a service provider, but the process of global logout is controlled by the identity provider, who is responsible for maintaining a list of all service providers to which the user has been signed onto in a given session by SSO. The identity provider sends a logout request to each of these service providers on behalf of the user.
For example, if John logs out of myemployerx.comâ€™s employee portal, myemployerx.com may no longer be willing to honor any transactions that John may undertake as a result of his myemployerx.com - vouched SSO actions. In this case, myemployerx.com will trigger a logout request to all partners to which an SSO request has been issued within Johnâ€™s current session.
Global logout does not imply that local logout goes away. A user may wish to log out of a session at a service provider without destroying their session at the identity provider. Note that this requires that the user know and understand the nature and workings of the federation. The more likely alternative to a local logout at a service provider is to provide a shorter session lifetime or inactivity timeout than is used in a standard, directly authenticated session. A shorter inactivity timeout for an SSO user may be acceptable, as the user is not forced to explicitly re-authenticate. Instead, the service provider will simply request another SSO from the userâ€™s identity provider.
Credentials Clean Up:
Logout, be it global or local, often implies the destruction of a session at a service provider. This session is often maintained at the edge of a network and may be independent of sessions with back-end applications. Back-end application sessions may be used to maintain state between request/responses of a multi-step transaction. Logout at both the identity provider and service provider should ensure that not only “edge” sessions but back-end application sessions (and session tracking artifacts) are destroyed.
Consider what happens when John logs out of the myemployerx.com portal, which because of SSO automatically logs him out of the benefitsx.com site. If John had started a transaction (to reallocate benefits, for example) and then forgotten about the automatic logout, this transaction must be cleaned up. (This is a form of garbage collection.) If this does not happen, benefitsx.com may be left with orphaned sessions that can tie up resources at its back-end applications.
Global; good-bye deals with de-provisioning of a userâ€™s access rights and entitlements within a federation scenario. When a relationship between an identity provider and a service provider is broken, global good-bye is used to destroy all of the userâ€™s relevant attributes (including attributes that are specific to the transaction, profile, and provider). Note that federation relationships may be terminated in several ways: A user may choose to terminate her binding of an identity provider to a service provider, or an identity provider and service provider may chose to no longer do business together, breaking the binding for all of the identity providerâ€™s users.
For example, consider John as an employee of myemployerx.com. If John changes employers (now working for SmallCo), Johnâ€™s access rights and entitlements to myemployerx.com-sponsored 401(k) must be cleaned up as part of the global good-bye between myemployerx.com and benefitsx.com. Note that global good-bye does not imply that Johnâ€™s account (including provider-specific attributes) at benefitsx.com is removed. It simply implies that all of the myemployerx.com attributes, including myemployerx.com-relevant transactional and profile attributes, are de-provisioned (deleted) from Johnâ€™s account at benefitsx.com.
In general, global good-bye is accomplished together with account de-linking.
Account de-linking is the process by which the common unique identifier is destroyed, removing the ability of an identity provider and service provider to uniquely refer to a given user. One result of account de-linking is that a user will no longer experience SSO from the identity provider to the service provider. Note that account de-linking is independent of how a userâ€™s account or registry record was created at the service provider, meaning that account de-linking is possible whether an account was explicitly created by a user and then linked, or created based on provisioning from the identity provider to the service provider. After de-linking an account, a user or service provider may chose to link an account with a different identity provider, or the service provider may chose to resume direct authentication of the user.
At some point, John may lose his myemployerx.com sponsorship for his benefitsx.com access by moving to a new employer or retiring, for example, and his SSO at benefitsx.com from myemployerx.com will not exist because he is no longer able to sign on to myemployerx.com. In this case, Johnâ€™s information at myemployerx.com and benefitsx.com should be de-linked (sometimes referred to as de-federated). The result of this process will be that the common, unique identifier for John will be destroyed, his SSO ability from myemployerx.com will be lost, and he will be reinstated as a user who can directly authenticate to benefitsx.com (in turn implying some form of self-registration process by benefitsx.com to allow John to reset a password there).
Federated Identity Management Standards and Efforts:
Reduced sign-on techniques and solutions have been in place for many years now. Federated Identity Management has its roots in reduced sign-on technologies. IBM first introduced reduced sign-on support in Tivoli Access Manager as early as 2001. The first standards-based efforts in this space were by Internet2 (Shibboleth) and OASIS (SAML). Since then, federation efforts have been led by the Liberty Alliance (Liberty ID-FF) and through the Web Services work of IBM and Microsoft and business partners (WS-Federation). Each of these efforts is introduced and briefly discussed in the following sections.
Federated Identity Management has roots in reduced sign on technologies.
Security Assertion Markup Language (SAML)
SAML is a specification that was designed to provide cross-vendor single sign-on interoperability. SAML was developed by a consortium of vendors (including IBM), under the auspices of OASIS (Organization for the Advancement of Structured Information Standards), through the OASIS SSTC (Security Services Technical Council). SAML describes:
A SAML assertion is an XML-formatted token that is used to transfer user identity (and attribute) information from a userâ€™s identity provider to trusted service providers as part of the completion of a single-sign-on request. A SAML assertion provides a vendor-neutral means of transferring information between federation partners. As such, SAML assertions have a lot of traction in the overall federation space.
SAML also defines protocols for implementing single sign-on. These protocols are HTTP-redirect-based and involve the userâ€™s browser. SAML defines two profiles for these single sign-on protocols: HTTP-based GET and HTTP-based POST profiles. With the HTTP-based GET profile, the SAML assertion itself is not included in the HTTP-redirect response. Instead, a SAML artifact is sent from the identity provider to the service provider. The service provider then uses an XML/HTTP backchannel to exchange this artifact for the appropriate SAML assertion.
By itself, SAML is not rich enough to support federations. SAML does not address the issues of trust, user management, privacy, and so forth. SAML assertions are rich enough to provide a vouch-for token for use within cross-domain single-sign-on scenarios and across federations.
SAML specifications released to date are SAML 1.0
and SAML 1.1 (approved September 2003). More about the SAML specification is
Shibboleth uses some of the SAML protocols but includes additional features that are specific to the higher-education community. For example, within the higher education community, there are very strict rules regarding the release of information about an institutionâ€™s students, even to other higher-education institutions.
Shibboleth introduces the notion of Where are you from? processing, enabling a service provider to implement both push-based and pull-based SSO protocols.
Shibboleth work is being rolled into the OASIS SSTC and will be incorporated with future versions of SAML.
The Liberty Alliance Project was formed to deliver and support a federated network identity solution for the Internet that enables single sign-on for consumers and business users in an open, federated way. The Liberty Identify Framework, ID-FF, describes federation functionality that goes beyond single sign-on. Initially released as Liberty Alliance ID-FF 1.0 in July 2002, the latest release of the Liberty specification is Version 1.2, released November 2003.Liberty ID-FF describes profiles for B2C-based single sign-on and additional functionality. Liberty ID-FF profiles include: Single Sign-On (SSO), Single Logout (SLO), Register Name Identifier (RNI), Federation Termination Notification (FTN), and Identity Provider Introduction (IPI). The Liberty-specified common user identifier (CUID) is referred to as a Name Identifier. It is an opaque reference to a user that acts as an alias, meaning that it cannot be used to infer information about the user such as their identity. A Liberty Name Identifier is used to establish (and maintain) the account linking between an identity provider and a service provider. The RNI profile is used to allow a reset of a userâ€™s Name Identifier, replacing a current value with a new Name Identifier value. The FTN process is used to remove all references to a Name Identifier, thus achieving account de-linking. Taken together, these profiles are intended to provide richer user management functionality within a federation than simple single sign-on.
The Liberty approach is based on business affiliates forming circles of trust. The Liberty circle of trust is defined as a group of service providers that share linked identities and have pertinent business agreements in place regarding how to do business and interact with identities.
The OASIS Security Services Technical Council, together with the OASIS Web Services Security Technical Council, has defined a Web Services Security SAML Token Profile. This describes how to bind an SAML assertion “in the context of WSS: SOAP Message Security, for securing SOAP message exchanges.”The OASIS WSS-TC issued OASIS Web Services Security as a specification in April 2004. Included in this specification are SOAP message security, a user name token profile, and an X.509 token profile.
WS-Federation describes how to use the existing Web Services Security building blocks to provide federation functionality, including trust, single sign-on (and single sign-off), and attribute management, across a federation. WS-Federation is really a family of three specifications: WS-Federation, WS-Federation Passive Client, and WS-Federation Active Client.
WS-Federation itself describes how to implement a federation in a Web Services world. In particular, WS-Federation focuses on the relationships between parties and the high-level architecture that supports these relationships. The two individual documents, WS-Federation Active and WS-Federation Passive, describe how to implement individual federation solutions.
WS-Federation Active describes how to implement federation functionality in the active client environment. Active clients are Web Services-enabled (that is, able to issue Web Services requests and react to a Web Services response).
Leveraging the Web services security stack, WS-Fed Active describes how to implement the advantages of a federation relationship, including single sign-on, in an active client environment.
WS-Federation Passive describes how to implement federation functionality in a passive client environment. A passive client is one that is not Web Services-enabled. The most commonly encountered example is a basic HTTP browser. WS-Federation Passive describes how to leverage the advantages of a federation relationship such as single sign-on in a passive client environment. Because this solution involves the WS-Security foundation of the infrastructure support, the same components that are used to provide a passive client solution may be used for an active client solution.
The three WS-Federation specifications are available for download at:
The logical architecture described in WS-Federation,
together with the functionality described in the Web Services Security Stack,
supports both the active and passive client scenarios. The complete family of
WS-Security specifications provides companies with a standards-based
interoperable secure digital identity and trust platform for Web Services-based
architecture. Further, these specifications promote reusability of existing IT
security investments, enabling companies to work with multiple security token
types and multiple scenarios including basic browsers, enhanced browsers, active
clients, and application-to-application connectivity.
The following tables highlight some of the characteristics of each protocol: SAML 1.0 and 1.1 (OASIS standards), Liberty ID-FF 1.0 and 1.1 (Liberty Alliance published specifications), and WS-Federation Passive (IBM, Microsoft, RSA, VeriSign published specification).
Services Views of Federation:
The previous section described the capabilities of a broad Federated Identity Management solution. These capabilities are treated as individual logical functions that may be leveraged in a Federated Identity Management solution. The capabilities are logical in that they are not implemented by one-to-one corresponding functional components. Instead, federation functionality is provided a set of services that are composable in order to create the functional capabilities described above.
Federated Identity Management provides a standardized mechanism for simplifying identity transformation and identity management across company boundaries. Federated Identity Management solutions leverage federation services, where federation services in turn provide the building blocks on which federation capabilities are implemented.
Federation management facilitates a standardized means for enabling businesses to:
Exchange, in a secure and trusted manner, tokens
(referring to a principal, their attributes, privileges, and so on). These
tokens are used to communicate information that is used for the authentication
and authorization of a principal to a business partner.
Federation relationships require a trust-relationship-based federation between business partners. A trust relationship is represented at a technical level by cryptographic keys that are used to sign and encrypt messages. The trust service provides a means of managing oneâ€™s own keys and certificates, and of binding a business partnerâ€™s certificates (validated by a third-party certificate authority) to the local, business-agreement-validated, partner identity. These keys and certificates are used to sign/validate and encrypt/decrypt messages between partners, independent of any transport layer security. These services provide the trust infrastructure over which other federation services are layered.
Trust management services require more than just the management of cryptographic elements. This is because trust relationships are also bound to security tokens that are exchanged between partners. Security tokens are managed by a security token service, often implemented as a logical service contained within the trust management service. We call out the notion of a security token service as a separate service to highlight the difference in management required for cryptographic elements and security tokens.
Security tokens may be included in a message to convey security-specific information (used for authentication, authorization purposes, or both, for example) about a requestor. These tokens are common to at least one other business partner and contain prearranged security-relevant information. These tokens are themselves protected through signing and encryption, often using the same keying material as used at the message layer. This information is part of the trust infrastructure in the same way that keys used for signing/encryption purposes: The proper use of these tokens conveys information about the holder of these tokens. The trust service provides a means of managing these security tokens and the trust relationships that are bound to these security tokens.
The interface to the trust service is described by the WS-Trust specification [WS-Trust]. Requests to the trust service are issued as <RequestSecurityToken> requests where the request is itself is to issue or validate a security token. In either case, there is some form of base evidence provided: either an indicator of the identity for whom a token is to be issued or an already-issued token that must be validated. Token exchange is accomplished by a request to issue a token where the base evidence is the token that is to be exchanged.
Token management is based on information such as the issuer of a token, the intended destination of the token, and the intended use of the token. This enables the trust service to manage a partnerâ€™s token metadata together with the partnerâ€™s cryptographic material.
Key services are leveraged to provide access to external key stores as used by a trust service. This enables a trust service to plug in or access different key stores as required. It also provides a single point through which key management may be accomplished. Key services are often implemented as logical components within a trust service.
Session Management Services:
The purpose of a session management service is to manage a userâ€™s session life cycle, from session creation to session access to session deletion (in response to session logout services). Session management services are provided by components such as Tivoli Access Manager (through the WebSEAL reverse proxy or the Tivoli Access Manager plugin). The services sit at the edge of a network where they guide a userâ€™s access requests and access experience within an enterprise.
Sessions are created at a session management service in response to a successful authentication or a successful security token validation. Current implementations of session management services often include authentication services, which provide the ability to validate authentication credentials provided by a user. This functionality is often built into a session management service because the protocol that is used to collect these credentials from a user requires a simple challenge/response interaction with the user. The SMS internal authentication service functionality will be used to validate the user-presented credentials. In response to this validation, the SMS will be presented with some form of user credentials or user privileges from which it can build a session for the user.
Within a federated single sign-on environment, the challenge/response protocol to collect authentication credentials is not negotiated with the end user but with a third party acting on behalf of the user. In fact, instead of presenting a set of authentication credentials in the form of a user name and password, a third party will usually assert some form of security token or assertion about the user. This security token acts as the equivalent of the user-presented credentials and must be validated before a user can be identified and have a session established.
This in turn implies that federated single sign-on is not as simple and not easily contained (in a modular and maintainable fashion) within a session management service. Instead of incorporating support for each of these protocols within the SMS itself, the SMS will invoke a single sign-on service. SSO services (described in a later section) provide the runtime for the federation protocols that are needed to implement the challenge/response with a third-party. In response to this action, the session management service will receive from the SSO service some form of user credentials or user privileges from which it can build a session for the user.
Authentication services provide the functionality that is required to evaluate and validate credentials. Authentication services evaluate credentials such as a user name and password, tokens, or digital certificates. The authentication service can invoke some back-end data store such as an LDAP registry to validate these credentials.
In response to credential validation, an authentication service will usually generate a set of information to be used for authorization decisions. This information is also referred to as user credentials or user privileges. This information is used by an authorization service, as described below.
Single sign-on Services:
Within a federation environment, Federated Identity Management protocols are used to communicate information about a user between federation partners. For example, with federated single sign-on, the result of this communication is some form of security token that must be validated; this token provides the information that is required to determine a userâ€™s local identity. Single sign-on services are responsible for implementing the protocol runtimes that are associated with Federated Identity Management, including the validation of security tokens that are presented on behalf of a user and the generation of local user credentials and user privileges that are consumed by a session management service. Thus, within a federation environment, single sign-on services provide a federation-compatible alternative to authentication services.
This Federated Identity Management functionality is implemented as an add-on solution to an existing session management product. It is the responsibility of the SSO service to implement the required Federated Identity Management protocols and interface with an existing session management service. This interface leverages existing authentication service interfaces so that a session is established at the session management service in response to SSO service actions in the same way that a session is established at the session management service in response to authentication service actions.
Authorization services are responsible for providing access decision point functionality within a security model. The authorization service itself may not act as an access enforcement point; such functionality is typically provided by session management services.
At their simplest, authorization services implement an access decision functionality, taking in a request for access and evaluating this request based on a userâ€™s session privileges. The authorization service may respond with a simple yes/no, indicating whether an access request is allowed. Based on this response, session management services act as the authorization enforcement point by allowing or denying the actual request for access.
Attribute and Alias Services:
Attribute and alias services are two forms of an identity service. An alias service is used to provide alias (such as common unique identifier) management, including the lookup or creation of aliases within the scope of a single-sign-on protocol. An attribute service provides the interface to the management of attributes used as part of the exchange of information between federation partners. Attribute services provide the interface to local data stores, including user registries and databases. An attribute service can add, delete, and look up information against some backing data store.
Attribute services are leveraged by both authentication services and single sign-on services. These services are responsible for evaluating a userâ€™s presented authentication credentials and providing to the session management service some form of user credentials and privileges; these privileges are based on the attributes of a user that are saved within a local data store (such as group membership, roles, personal attributes such as age, and so on).
Provisioning services are used within a federated environment for both a priori and runtime provisioning solutions. Provisioning services interact with both local identity management systems (such as Tivoli Identity Manager) and local data stores (access via identity services). Provisioning services are leveraged to federate local identity management systems across federation partners and to provide federated management of identity data, including transactional and profile attributes.
Provisioning services are leveraged as part of the identity management functionality within an enterprise; as such, they are often integrated with a local identity management system. This enables the local identity management system to treat a federation partner as a local provisioning endpoint, which is then included in any workflow-based approval processes that are in place. Thus, an identity provider can have a seamless view of managing a user across a federation while allowing federation partners to benefit from the management functionality assumed by the identity provider.
Management of Federations: Management of Trust Infrastructure:
A trust relationship is represented at a technical level by cryptographic keys that are used to sign and encrypt messages. These types of cryptographic techniques provide a trust infrastructure over which other services can be layered.
The simplest form of trust infrastructure is that provided by the transport layer SSL protocol, which is used to encrypt communications at the transport layer between two partners. Enterprises generally understand how to manage SSL certificates and how to use them to authenticate other enterprises with techniques such as mutually authenticated SSL. SSL-based trust infrastructures suffer from some limitations, notably that they are (at best) point-to-point-based, not end-to-end.
Web Services, however, may not always run over SSL-compatible transport protocols but may be invoked via transport layer protocols such as Java Message Service (JMS) or Message Queue (MQ). Thus, a Web Services trust infrastructure requires more flexibility than SSL offers. This flexibility is provided by encryption and signing of Web Services requests themselves in addition to any transport level protection that may be applied.
Federated Identity Management requests will usually run over HTTP (and thus be able to take advantage of SSL). However, they are not point-to-point communications, meaning that an additional layer of protection is required. This is provided by encryption and signing of the Federated Identity Management requests themselves in addition to any transport-level protection that may be applied.Both Web Services and Federated Identity Management solutions use a non-transport-based trust infrastructure. This is provided by the signing and encryption of requests at the message layer. The trust service provides the infrastructure to manage the keys and certificates that are used for this signing and encryption.
The trust service provides a means of managing oneâ€™s own keys and certificates, and of binding a business partnerâ€™s certificates (validated by a third-party certificate authority) to the local, business-agreement-validated, business partner identity. These keys and certificates are then used to sign, validate, encrypt, and decrypt messages between business partners, independent of any transport layer security.
In addition to message layer security, security tokens may be included in a message to convey security-specific information (used for authentication or authorization purposes, for example) about a requestor. This information is part of the trust infrastructure in the same way that keys used for signing and encryption purposes: The proper use of these tokens conveys information about the holder of these tokens.
The trust service provides a means of managing these security tokens, which are common to (at least) one other business partner and contain prearranged security-relevant information. These tokens are themselves protected through signing and encryption, often using the same keying material as used at the message layer.
Using trust infrastructure to manage Federated Identity Management functionality:
Federated Identity Management functionality centers on the functionality that is required to implement a user life cycle management solution. By complete, we mean that more than just single sign-on is addressed. A Federated Web Services and Federated Identity Management solutions require a non-transport-based trust infrastructure.
Identity Management solution should also address user account creation and provisioning, account linking, identity and attribute mapping, single logout, and account de-linking/de-provisioning.
Federated Identity Management functionality is sensitive because it can affect a userâ€™s online experience. A seamless experience that enables a user to access necessary resources without having to repeat the account creation or single sign-on step at every partner site is desirable. An experience that involves repeated authentication tasks by the user, together with the occasional account registration, is not desirable.
To help ensure a desirable user experience, business partners within a federation need to communicate information about a user in a secure and trusted fashion. This is accomplished by leveraging a trust infrastructure that enables the protection of a message at all levels:
The trust infrastructure provides protection against invalid or fraudulent Federated Identity Management flows while allowing for a single point of management for the trust information.
Federated Identity Management Architecture:
The Federated Identity Management functionality described in the previous section introduces new functionality that is used by all business partners to implement each task. This functionality must be integrated with existing functionality; it is generally not intended to stand alone. For example, single sign-on at a service provider may result in a user not being able to authenticate directly to the service provider but still require that the service provider establish a valid session and local authorization credentials (privileges) for the user. Or, establishment of a common unique identifier (CUID) may require integration with a local user registry. Federated Identity Management functionality touches an existing architecture; Federated Identity Management solutions should therefore be implemented in a way that they can be integrated easily with an existing architecture.
Basic Federated Identity Management Architecture Pattern:
Federated Identity Management solutions will not be adopted if they impose architectural constraints and prerequisites on an existing environment. The IBM Tivoli Federated Identity Management solution is designed to be modular, helping minimize the effort that is required to integrate the solution into an existing environment. Figure 3 shows the basic pattern for a Federated Identity Management architecture.
In Figure 3, IBM Federated Identity Management functionality integrates with the Point of Contact and possibly with a local user registry. This architecture has been designed to minimize the impact and integration requirements on an existing environment. Each of the components in this figure, their roles, and the implications of a Federated Identity Management solution on that componentâ€™s functionality are:
Introduction of a Federated Identity Management solution means that the PoC at a service provider will offload the user authentication process to the Federated Identity Management component for single sign-on purposes. The PoC will not evaluate user-presented authentication credentials. It will instead rely on this component to evaluate an IdP-provided assertion about the user. The component will be responsible for presenting to the PoC the information that it requires to identify the user and build a session for that user.
Note that unless and until Federated Identity Management tasks are invoked, there is no interaction between the PoC and the Federated Identity Management components.
An HTTP Point of Contact such as Tivoli Access Manager implements authentication service, session management service, authorization service, and identity service functionality. It can also invoke (when required) single sign-on services as part of the implementation of federation identity management functionality.
Federated Identity Management functionality: From a high-level point of view, this functionality can be viewed as a single, black-box component. It contains several logical components that are discussed in detail in this paper (including the protocol runtimes and trust infrastructure support). This component provides the Federated Identity Management protocol implementations that are required for single sign-on, account linking, and more. This component must communicate with the HTTP PoC for the purposes of completing single sign-on and single logout functionality. It also integrates with a data store (user registry) for management of the federation common user identity (CUID) that is used in all of the federation tasks. Note that the Federated Identity Management component can also be treated as a stand-alone application (endpoint) for some federation tasks that do not require interaction with the PoC (such as account de-linking).
Federated Identity Management implements the required single sign-on protocols as part of a federated identity management solution. As a black box, this also includes trust service and security token services, as used by the SSO services. This Federated Identity Management component also includes identity service functionality and enables it to integrate with external user datastores as part of user identity and attribute management by a security token service.
User registry: IBM Federated Identity Management functionality requires some form of user registry or data store for maintaining the CUID-local identity mapping. This user registry may be implemented as an internal, private registry that is used only by Federated Identity Management (thus minimizing integration requirements with local user registries). IBM Federated Identity Management functionality may also leverage existing user registries to enable the Federated Identity Management componentry to access additional (partner-maintained) user attributes that may be required as part of the userâ€™s CUID-local identity mapping.
This user registry or data store is accessed by an identity service, which provides an implementation-independent means of access.
Detailed Federated Identity Management Architecture:
Federated Identity Management functionality is logically represented as a single component. This component is composed of individual functionality and components, as shown in Figure 4.
Federated Identity Management SSO Protocol Service:
The IBM Federated Identity Management SSO Protocol Service (SPS) provides the runtime implementation of supported Federated Identity Management profiles. Support for single sign-on, single logout, account linking, account de-linking, and Where are you from? functionality is included in the SPS.The SPS relies on the Point of Contact for session management for all users, whether the SPS is acting at the identity provider or service provider.
Federated Identity Management Trust Service
The IBM Federated Identity Management Trust Service implements the trust infrastructure over which Federated Identity Management functionality is layered. The trust service uses the keys that are bound to a trust relationship to validate the encryption and signatures placed on security tokens used within a Federated Identity Management profile. As part of this security token validation, the trust services also validate the token itself and use the information that is contained within a validated token to determine a locally valid identity for a user.
Just as the overall Federated Identity Management functionality can be considered to be a single black-box component, the Federated Identity Management Trust Service leverages additional services provided by an identity service and key services. These individual services are described in the following sections.
Token creation and validation functionality is included within the Trust service. As such, token runtimes are “plugged into” and invoked through the trust service. Within a Federated Identity Management infrastructure, the trust service is responsible for creating SP-specific security tokens as part of an SSO response by an identity provider. At the service provider, the trust service is responsible for validating the security token that is received by the service provider from an identity provider as part of an SSO response.
When creating (or issuing) a security token, the trust service is required to build a security token that contains enough information about a requestor that the requestor can be uniquely identified by the receiving partner. This may require that the security token contain the requestorâ€™s identity, attributes about the identity, attributes about the userâ€™s session, such as role, authentication method, and so on. The trust service may invoke the identity trust service as part of this identity and attribute functionality within token issuance and validation.
When issuing a security token, the trust service is responsible for any token-specific encryption and required signatures. For example, an identity provider may be required to issue a SAML assertion for a given partner. In general, SAML assertions are required to be signed; the identity provider trust service handles the signing of this assertion with the signing keys bound to the given federation partner based on the trust relationship with that partner. When validating a security token at the service provider side, the trust service is responsible for decrypting and validating the signatures on the token. This again is accomplished with the keys that are bound to the given federation partner based on the trust relationship with this partner.
Federated Identity Management Identity Services:
IBM Federated Identity Management Identity Services (alias service and attribute service functionality) are responsible for managing (add, lookup, delete) information from one or more user registries. These registries may be Java Naming and Directory Interface (JNDI)-type (for example LDAP-based user registries) or Java Database Connectivity (JDBC)-type (for example, IBM DB2-based data stores). This functionality is required as part of single sign-on functionality, where information about a requestor must be looked up at the identity provider as part of token creation and must be validated and mapped to local attributes at the service provider side. The identity services are also involved with account linking and de-linking functionality, as the common user identity (CUID) that is used within the scope of a single sign-on request will be managed through the identity service. This CUID must be stored at both the identity provider and service provider.
The registries accessed by the identity service may be a private registry, unique to the Federated Identity Management installation, or existing customer registries that can be plugged into the Federated Identity Management identity service. Both the alias service and the attribute service functionality within the identity service support “plugability” to various user registry stores.
Federated Identity Management Key ServicesIBM Federated Identity Management Key Services provide the management of the keys (encryption, signing) that are used as part of token management. Keys are managed in key stores. Federated Identity Management Key Services accommodate multiple different key stores, including key storage based on Java Key Store (JKS) and XML Key Management Specification (XKMS). Using a Federated Identity Management Key Service allows the plugability of the type of key store particular to a given environment. Federated Identity Management key services leverage trust roots from third-party certificate authorities such as VeriSign for purposes such as CertPath validation.A token may require signing and encryption as part of the token creation process. Federated Identity Management Key Services are used to determine the appropriate (private) keys to be used, based on the intended token recipient. When tokens are validated, the Federated Identity Management Key Services are used to determine the appropriate (public) keys to be used, based on the stated issuer of the token.
Keys are bound to federation partners, meaning that possession of a private key (as indicated by the encryption of information with this key) provides proof of the identity of the entity encrypting this information and validation of the trust relationship between the partners. In general, business partners will use public key cryptographic techniques, meaning that one partner (X) will retain a private key and give the corresponding public key, bound to a certificate, to another partner (Y). The binding of a public key to a certificate proves that the identity that is claimed in the certificate (partner X) has been validated by a third party (a certificate authority). This public key and certificate are then bound, at the business partner site (Y), to the business partnerâ€™s representation of the business partner identity claimed in the certificate (X).The key services are used at runtime to manage the keys that are required as part of the runtime management and implementation of a trust relationship. The Key Services also provide a management interface that enables administrators to establish the bindings that are used to govern trust relationships between partners.
Federated Identity Management Session Management, Authentication and Authorization Services:
The Federated Identity Management solution relies on a separate entity (the Point of Contact) to implement session management functionality, including authentication services (if required to directly authenticate a user) and authorization services as part of an authenticated userâ€™s overall session.The Federated Identity Management Point of Contact is responsible for appropriately invoking the Single Sign-on Protocol Services to implement Federated Identity Management functionality as required.
Federated Identity Management Provisioning Services:
The IBM Federated Identity Management solution leverages the Federated Identity Management trust infrastructure to provide a provisioning bridge between federation partners. Federated Identity Management does not provide a provisioning engine for enterprise user provisioning needs; this functionality, if required, can be leveraged from Tivoli Identity Manager. The Federated Identity Management solution integrates with identity management systems, such as Tivoli Identity Manager, to provide a local endpoint that acts as a proxy to the service provider, enabling an identity management system to provision to this Federated Identity Management endpoint. Federated Identity Management then brokers provisioning requests to the service provider to be appropriately received and acted on based on the trust relationship between the identity provider and service provider.
Integrating Federated Identity Management Functionality into an Existing Environment:
Integration with Tivoli Identity Management Solutions:
Federated identity management is an administration concept. It enables companies to extend and evolve their identity management infrastructure to be integrated with their partners. As such, the IBM Federated Identity Management solution can enhance identity management for both the identity provider and service provider infrastructure. The Federated Identity Management solution extends the current Tivoli identity and security offerings: Tivoli Identity Manager, the Tivoli Access Manager family, Tivoli Directory Server, and Tivoli Directory Integrator.
Tivoli Access Manager:
Tivoli Access Manager provides:
The IBM Federated Identity Management solutions extend IBM Tivoli Access Manager authentication and session management functionality by providing standards and public-specification based single sign-on and federation user session life cycle solutions.
IBM Tivoli Access Manager Identity Provider Integration:
In general, IBM Tivoli Access Manager treats Federated Identity Management as a generic back-end application that does not have explicit integration requirements with Federated Identity Management. When an enterprise is configured for identity provider functionality, IBM Tivoli Access Manager will:
When configured for identity provider functionality, the IBM Federated Identity Management solutions integrate with IBM Tivoli Access Manager and have expectations on IBM Tivoli Access Manager behavior as follows:
Tivoli Access Manager Service Provider Integration:
When an enterprise is configured for service provider functionality, IBM Tivoli Access Manager will:
When configured for service provider functionality, the IBM Federated Identity Management solution integrates with IBM Tivoli Access Manager and has expectations on IBM Tivoli Access Manager behavior as follows:
IBM Tivoli Identity Manager:
IBM Tivoli Identity Manager provides enterprise-wide identity management and user provisioning functionality. This includes both workflow and provisioning solutions for identity management. IBM Tivoli Identity Manager integrates with systems such as PeopleSoft and SAP, which enables Human Resources administrators to manage users through a dedicated system while IBM Tivoli Identity Manager provides the authoritative provisioning solution required to keep all of an enterpriseâ€™s user registries in synch. IBM Tivoli Identity Manager provides a workflow solution that enables administrators to implement local policy about the creation and management of users where policy requires some level of manual approval as part of the process.
Federated Identity Management extends IBM Tivoli Identity Managerâ€™s enterprise-provisioning capability with federated provisioning, which extends the concept of automated user provisioning to trusted third-party organizations such as suppliers, partners, and service providers. Federated provisioning can also help extend enterprise-provisioning solutions to support intranet organizations such as autonomous regional organizations who have a need to manage user provisioning locally. Federated Identity Management can leverage IBM Tivoli Identity Manager to implement the local provisioning of a user in response to a federated provisioning request. This allows a local enterprise to maintain locally relevant user information for a federated user, including user life cycle functionality, in response to provisioning information from federation partners.
Federated Identity Management extends IBM Tivoli Identity Managerâ€™s provisioning and workflow functionality by providing standards and public-specification-based federated provisioning for user life cycle management. Providing this support through Federated Identity Management provides a modular solution that allows easily extensibility of federation and provisioning solutions with minimal impact on an existing IBM Tivoli Identity Manager environment.
IBM Tivoli Identity Manager Identity Provider Integration:
In general, IBM Tivoli Identity Manager treats Federated Identity Management as a provisioning endpoint. When an enterprise is configured for identity provider functionality, IBM Tivoli Identity Manager will:
When configured for identity provider functionality, the IBM Federated Identity Management solutions integrate with IBM Tivoli Identity Manager and have expectations on IBM Tivoli Identity Manager behavior as follows:
When an enterprise is configured for service provider functionality, IBM Tivoli Identity Manager will:
When configured for service provider functionality, the IBM Federated Identity Management solutions integrate with IBM Tivoli Identity Manager and have expectations on Identity Manager behavior as follows:
IBM Tivoli Directory Integrator provides a lightweight data synchronization solution. This allows a simple solution for keeping multiple data stores in synchronization, even when there is no single authoritative data store.
Federated Identity Management internalizes IBM Tivoli Directory Integrator functionality within its federated provisioning solution. As such, the integration that is required with IBM Tivoli Directory Integrator is part of the installation and configuration of Federated Identity Management itself.Federated Identity Management extends Directory Integratorâ€™s data synchronization solutions to provide standards and public-specification-based federated provisioning and single sign-on. By leveraging IBM Tivoli Directory Integrator, Federated Identity Management can provide a modular solution that allows easily extensibility of federation and provisioning solutions with minimal impact on an existing enterprise environment.
IBM Tivoli Directory Integrator Identity Provider Integration:
IBM Tivoli Directory Integrator functionality:
Federated Identity Management/ IBM Tivoli Directory Integrator functionality:
IBM Tivoli Directory Integrator functionality:
IBM Tivoli Directory Server provides a highly available, scalable LDAP directory that can act as an enterpriseâ€™s main data repository. Federated Identity Management will leverage a data store (such as IBM Tivoli Directory Server) for the management of internal (only Federated Identity Management-relevant) information. Federated Identity Management may also require integration with a local data store as part of the fulfillment of federation functionality.
Federated Identity Management can leverage IBM Tivoli Directory Serverâ€™s LDAP directory as part of the Federated Identity Management standards and public-specification-based federated provisioning and single sign-on. By leveraging IBM Tivoli Directory Server, Federated Identity Management can provide a modular, highly scalable solution that allows extensibility of federation and provisioning solutions with minimal impact on an existing enterprise environment.
IBM Tivoli Directory Server identity provider integration
IBM Tivoli Directory Server service provider integration
Integration with the WebSphere Platform:
The IBM Federated Identity Management solution leverages and integrates with the IBM WebSphere middleware platform, including WebSphere Application Server, WebSphere Portal, and WebSphere Business Integrator.
WebSphereWebSphere is the IBM middleware platform for Java and Web Services strategy. Federated Identity Management extends the capability and dynamism of the WebSphere middleware platform with support for federated business interactions:
Organizations are looking to increase productivity and efficiency in both their internal and external interactions. Reducing cost, reducing friction, and promoting reuse are key to increasing productivity. Many organizations are moving to a services-based delivery model or service-oriented architecture in which business services are available through the integration of loosely coupled application platforms.
Federated Identity Management can deliver clear and compelling business productivity by helping reduce the friction that can be caused by incompatible identity management systems. Because identity is a fundamental tenet of business and organizations have a business need to integrate their systems and applications, Federated Identity Management offers a strategic opportunity for companies to address both issues. It enables organizations to network and integrate their application platforms securely using Web Services. Federated Identity Management enables companies to securely link, join, or extend their IT infrastructures with those of their business partners rather than create and manage redundant identity and security infrastructures.
IBM has recognized that Federated Identity Management is a user life cycle management and administration issue. This approach enables companies to simplify their user administration and security administration while improving security and corporate compliance. Many businesses have to manage employee, business partner, and customer identities; the relationship between the business and these individuals change fairly frequently, and each change requires an administrative action. Using Federated Identity Management, companies can offload the cost of third-party user management to third-parties. The lifecycle-management approach also enables company administrators and auditors to have the visibility, controls, and workflow to engage in federated administration with their partners.
A federated model provides the platform for companies to deliver identity-driven transactions. The solution extends the user lifecycle management of organizations to include trusted partners and members. Built on open Web Services standards, this integrated approach to user life cycle management provides an optimized and cost-effective approach to managing identities and access control rights while simplifying user experience.
By choosing to operate in business federations, companies:
The IBM Federated Identity
Management solution delivers concurrent support key identity management
specifications such as Liberty, WS-Federation, and SAML. Federated identity is
built on the trust foundation of the WS-Security family of specifications.
Integration of Federated Identity Management capabilities with IBM middleware
solutions such as WebSphere Application Server and WebSphere Portal enables
these platforms to quickly leverage and adopt federated business models using
U.S.A.IBM, the IBM logo, the On Demand Business logo, RACF, Tivoli, and WebSphere are trademarks of International Business Machines Corporation in the United States, other countries or both. Microsoft is a trademark of Microsoft Corporation in the United States, other countries or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product and service names may be trademarks or service marks of others. Each IBM customer is responsible for ensuring its own compliance with legal requirements. It is the customerâ€™s sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect its business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its products or services ensure compliance with any law or regulation. Software products and services provided by third parties are sold or licensed under the terms and conditions of the third-party providers. Product availability, warranty services and support for third-party products are the direct responsibility of the third-party providers. IBM is not liable for and makes no representations, warranties or guarantees regarding third-party products or services. The IBM home page on the Internet can be found at ibm.com Produced in the United States. 12-04 G507-1089-0
Search the ENTIRE Business
Forum site. Search includes the Business