Federated Identity Management

"It is impossible for ideas to compete in the marketplace if no forum for
their presentation is provided or available." Thomas Mann, 1896

Federated Identity Management

Contributed by IBM - Tivoli Group

Executive Summary

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:

Federated Identity Management is user lifecycle management. It can simplify the administration of user management and access management between companies. This concept is not about single sign-on or a specific standard but the recognition that administration can be simplified when companies can apply relationship-based trust with their business partner organizations to improve their security, governance and user experience.
A federated identity is built on trust. The IBM approach is to build robust key management (security token services) as an integral part of our federated solution.
The goal of Federated Identity Management is to achieve a common identity framework that simplifies sharing and provisioning of identity and identity information (such as entitlements and credentials) among users, applications and Web services. The key to achieving this common identity framework is to support a rich set of standards and specifications including Liberty, WS-Federation, and Security Assertions Markup Language (SAML) in its Federated Identity Management solution.
Federated Identity Management builds on the WS-Security family of specifications. The WS-Security family provides broad standards to deliver a trust management platform built on Web services on which companies can conduct business.
Our technology is built on J2EE and Web Services, enabling customers to deploy these solutions on their middleware platform.

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.

Introduction:

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:

Achieving top-line growth
Whether a company is looking to grow organically or through mergers and acquisitions, access to new customers and markets, as well as delivering a broader range of products and services is a strategic priority for many initiatives. A company that is growing by acquisitions faces significant challenges in integrating its various customer information systems in order to drive revenue from these acquisitions. A company that is driving organic growth faces significant challenges in integrating their customer identity systems and products to create opportunities to cross-sell, up-sell and resell.
Reducing bottom-line costs
IT budgets are under pressure. Companies are challenged to reduce spending by pursuing infrastructure consolidation, improving efficiency of business processes, and using automation to reduce costs. Meanwhile, a typical large organization has several IT infrastructure “silos” of systems for ordering and procurement, customer care and relationship management, and back-end systems resulting from mergers and acquisitions, autonomous business unit operations and incompatible technology infrastructures with poor resource utilization. These silos yield fragmented business processes that require significant IT budgets for support, maintenance and updating. Many companies are now employing IT transformation projects based on service-oriented architectures to achieve transformational efficiencies across their core business processes such as order management, customer care, customer relationship management, supply chain management and legacy integration.
Improving corporate governance goals around compliance, audit and accountability
Many organizations are under board-level scrutiny to improve their accountability and transparency to adhere with new regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA) and Basel II. Companies may fail audits because of lack of accountability for access rights granted to users. The reason for failure is the inability to demonstrate the process and procedures by which access rights were granted or revoked.

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.

Corporate identities

- Network identities (remote access, VPN, or Wi-Fi accounts) that enable users to access the network- Desktop identities to sign on to the workstation (Windows credentials)
- Corporate e-mail and white pages accounts- Legacy accounts for mainframe accounts
- HR accounts (PeopleSoft, SAP, Oracle)
- Supply chain and CRM accounts (such as SAP and Siebel)
- Identities that are managed in middleware and database solutions, such as Oracle accounts, WebSphere accounts, Portal accounts
Employee to employer-outsourced provider identities
Many employee services such as employee savings plans, retirement accounts, pension, employee stock options, health care, payroll and travel services typically are outsourced. However, employees must register and enroll at these third-party Web sites to get a login account before they can access these services. Many small and medium businesses typically outsource many aspects of their non-core services such as customer management, payroll and financial accounting.

- Employee benefits accounts (such as 401(k) or superannuation, pension, stock options, health care, online travel)
- Employee access to software-as-a-service (SAAS) identities, which access hosted software such as WebEx, ADP, quicken.com, salesforce.com and Siebel CRM On Demand
- Accounts at financial service providers (IRA, 401(k))
- Accounts at outsourced procurement sites- Online banking and bill payment accounts
- Accounts with credit card providers
Business-to-consumer (B2C) identities
Companies have to work with many forms of identities to deal with suppliers, partners, distributors and dealers. Customers need login identities to access various applications in the company portal:

- Suppliers need login accounts to access procurement systems such as SAP.
- Business Partners need accounts in various systems.
- Distributors and dealers need access to various line of business applications.

The unique element in B2C is the scale: Millions of these identities and accounts must be maintained.

IT administrators are faced with these familiar challenges when dealing with these clusters of identities. Each identity account entails the following responsibilities for IT administrators:

Managing user identity using an specific application-specific custom tool.
Managing a password or credential for that identity.
Managing entitlements or attributes related to that identity.
Managing changes to identity, password, or attributes.
Staffing and managing Help Desk to support end users.
Managing the lifecycle of identity information: as users change jobs or roles the various user entitlements or access control privileges in an application must be updated.
When users turn over, user identities (accounts) must be de-provisioned at the various systems where the user has an account.

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:

Support for open service-oriented architecture standards to enable secure cross-enterprise, cross-platform, cross-vendor Web solutions, building on a foundation of identity, provisioning, federation, data access, privacy and risk management
Enhanced product support for Web Services security mechanisms with seamless integration with a variety of Web Services development and deployment platforms (such as IBM WebSphere, J2EE, Microsoft® .NET).
Evolutionary approach building on identity management, user provisioning, extranet access management, privacy, and trust management
Enable a whole new class of secure and on demand business services building on Federated Security Management capabilities.

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:

Insufficient confidence in business transactions: Identity is the basis of security, and poor identity management means weak security.
Administrative costs: Soaring costs with account information administration and password administration, user registration, and Help Desk support.
Risk, compliance, security exposure
- Business, legal and privacy issues with user data access
- Issues with unauthorized access from users
- Audit failures due to inactive user account exposure
- Identity and password theft
- Phishing attacks
Poor market reach:
- No standard mechanism to trust identities from mergers and acquisitions, partners, and third parties
- High cost of non-standards-based identity integration with applications and services

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:

Create an account in each target system for the user
Enroll or register new users to services
Establish access rights or credentials ensuring the privacy and integrity of account data
Establish initial password or PIN
Handle Help Desk or Customer Care support for:
- Forgotten user name
- Forgotten password
- Password reset
- New access request
Manage password synchronization
Manage changes to access rights as user changes roles and entitlements due to organizational changes
Eliminate access rights
De-provision accounts when user leaves the company
Ensure the privacy and integrity of account data

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.

Password Management Costs:

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:

No standard mechanism exists to “trust” identities from mergers and acquisitions, partners, and third parties. There is no concept of a portable digital identity.
Lack of trust means that companies or business units replicate identity accounts because there is no way to federate identities between applications.
When companies replicate accounts they incur costly and inefficient account management.
When companies replicate and synchronize accounts, each account can increase the security exposure due to unauthorized access, introduce compliance challenges, and add privacy.

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:

Identity management costs can be lowered because companies are no longer in the business of managing users or identities that are not under their control. Businesses need to manage access to data but not have to manage accounts and user account data.
Superior user experience can be delivered when users can navigate easily between Web sites while maintaining a globally interoperable identity.
Integration can be simplified because there is a common way to network identities between companies or between applications and services. Organizations can implement business strategies that drive organic market and customer growth by eliminating the friction caused by incompatible identity and security management between companies.

Business models for Federated Identity Management:

Mergers and acquisitions
In this scenario, a company implements a growth strategy using mergers and acquisitions. The success of the merger or the acquisition is predicated on how quickly the companies can integrate their IT infrastructures to target and cross-market to the new customer base. Identity Management is one of the most complex activities in such mergers. Rather than having to forklift all of the acquired users in the various systems, an integration strategy based on identity federation simplifies the user experience. The combined users from the merged customer bases can have access to the shared assets of the merged companies without affecting user experience, customer care, or the quality of support. Federated Identity provides a quick and seamless way to integrate the customers of the two companies to drive merged growth scenarios.
Collaboration between autonomous cross-business units
Many large companies have independent business units that want to directly maintain ownership and relationship with their users. This may be due to organizational structure or for political, competitive, or regulatory reasons. A large global manufacturing company may be organized as independent companies with regional management consolidated in the Americas, Europe/Middle East/Africa and Asia. However these business units may also have users (employees) who need access to cross-business-unit resources. For example, employees in Asia may need access to ordering and parts information in other regions. Federated Identity enables business units to retain autonomy and control of their users yet have a flexible way to federate data to cross-business unit resources.
Customer acquisition strategy via partnerships
A company whose growth strategy is based on acquiring new customers must either obtain these customers outright or have partnerships with other companies to target their customers. For example, a financial services provider may form a partnership with a mobile wireless provider with millions of subscribers to deliver paperless e-billing to these customers. The incentive for the mobile wireless provider in this business partnership is to reduce its non-core expenses by outsourcing billing functions to the financial provider. In return, the mobile provider may offer the incentive of a 5% discount for customers who subscribe to the new e-billing service. Through this business partnership, the financial services company has acquired a million new customers to which it can target its e-billing service. Federated Identity Management as a solution enables the company to access large pools of customers that have a well-established identity.
Employee access to outsourced provider services
Employee self-service is a major initiative for many companies looking to reduce user provisioning or user care costs. Most organizations outsource non-critical competencies to third-party providers. The services that are being outsourced include human resources management, employee stock options, health care, payroll, travel and procurement. Using the corporate intranet portal to connect employees directly with these external service providers enables the organization to simplify the administration of these outsourced services. Organizations outsource these services to reduce service administration costs. However, the inability to directly connect the employee to these service providers means that the organization is now required to support and maintain staging systems (Help Desk) for employee enrollment to Savings Plan (401(k) or superannuation), health care, or payroll. Employers spend a significant amount of plan administration costs in employee 401(k) administration, employee stock options, employee health care, and travel. These services are typically outsourced to various outside providers; however, the company stills ends up manually administering these plans or having to staff customer care personnel for employee management. Federated Identity Management provides a compelling value proposition in this scenario by enabling employees to access and manage their data on the various third-party service provider Web sites by simply signing on to the employee portal. Access through an existing portal simplifies the user experience and enables the user to interact with various Employee provider sites without requiring additional enrollment, registration or authentication to these partner sites. The employer in turn can lower their employee support and plan administration costs by enabling employees to interact directly with the various providers.
Service provider automation with B2B clients
A larger service provider managing employee retirement accounts, pension plans, employee stock options, or health care for their institutional clients may incur a tremendous cost of user lifecycle management of its clientsâ€™ employees. These costs can result from having to register and provision online accounts for client employees, manage passwords, and staff the help desk for dealing with user access problems resulting from forgotten user names, credentials, or passwords. Assume an average password reset call costs $20, and that there exists a service provider who manages 100 Fortune clients, each of whom on average have 10,000 employees. Even if only a quarter of these employees forget their password just once a year, this would represent a $5 million annual cost in managing user accounts and passwords. The service provider is heavily motivated to move to a federated model where the service provider leverages the employeeâ€™s corporate portal authentication to provide access to their services. In this model, the employer (client) is responsible for managing its users and passwords (the client does not face additional costs, because they already have to manage these users and passwords), and the service provider offloads the cost of user administration to its clients. This approach also benefits the employee tremendously, as the employee does not have to register or remember a separate login and password to manage their 401(k) or health care.
Portal-based integration of software-as-a-service providers
A new generation of Internet-based providers now delivers software-as-a-service (SAAS) to companies. These providers include WebEx, salesforce.com, Siebel CRM OnDemand and Travelocity.com. These services enable companies and small businesses to access Internet-hosted services without having to undertake the IT infrastructure cost of managing these services locally. Federated Identity Management plays a critical role in this system by enabling employees of the companies to access various software-based services using their employee identity login. As more and more non-core business services are being outsourced or offloaded with providers, Federated Identity Management fulfills the role of an identity integration technology that enables the user to seamlessly access third-party services that may be locally hosted, remote-hosted, or accessed by an SAAS provider.
Improved corporate governance
Corporate governance and complying with various regulations may be major initiatives at companies. One of the key impediments to passing an audit and achieving compliance is lack of accountability for granting user rights and permissions to access business systems. A primary reason for failing audit is the inability to account for access rights that are granted to partner users.
Here are some issues with compliance:
- Organizations cannot account for access rights that are granted in their internal systems for third-party users; there is no proof whether a third-party user actually exists or even needs access.
- No accountability for why a third-party user was granted access in the first place; failure to demonstrate and document the business reason for the request and which company officer approved the request.
- No procedures in place to delete entitlements or purge user access rights belonging to third parties and their users. This results in users accumulating access rights far beyond what they were originally authorized.
- No procedures in place to de-provision user accounts in cases of user turnover. This issue is magnified when dealing with third parties when the company does not control the third-party user and no process typically exists by which third-party companies will notify of user turnover.
- No way to recertify third-party user access. Does this third-party user still need access beyond three months or six months? Why do they still need access?
- No way to audit requests for third-party access. Most companies are not able to audit third-party user access in a centralized fashion because there is no one single tool that is used to grant third-party access. In todayâ€™s model, in which the company takes on the management burden of third-party user administration and provisioning, these audit issues are magnified when third-party users turn over.

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?

Is there a legitimate business with the stated name?
Is this the authorized party making the request?
Is the specific employee making the request authorized?

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:

Self-assertion
Leveraging an existing relationship
Confirmation of electronic or postal address
Credit agency, business bureau ratings
Identity verification

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.

Examples of the types of characteristics that are evaluated as part of the accreditation process include:

Is the company creditworthy?
Is the company considered to be a reputable business?
Is the company approved by relevant professional or trade bodies?
Is the company part of the federation?
Has the company authenticated and issued credentials in a standardized trustworthy fashion?

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

Introduction to Federation:

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:

Seamless and secure user interaction across federation business partners (also known as Federated Identity Management)
Seamless and secure business interaction across application platform integration (Web Services Security Management for Service Oriented Architectures)

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.

Background

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

Federated Identity Life Cycle Management:

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.

A simple federation example:

The potential benefits of federation and Federated Identity Management are best described by a simple example. Consider a scenario with three entities:

An employer, myemployerx.com
A benefits provider, benefitsx.com
An employee, John Doe

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 benefitsx.com-maintained attributes.

Provisioning and Identity Management:

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:

Authentication credentials
Transaction attributes
Profile attributes
Provider-specific attributes

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.

Sharing authentication credentials between the identity provider and service provider means that the service provider can rely on the identity provider to authenticate the user. This frees up the service provider from managing password and credentials for the user. If identity account data cannot be shared, then both identity provider and service provider must manage a separate identity account for the user, forcing the user to remember multiple accounts and passwords.
NOTE: Regardless of the sharing of account data, both an identity provider and service provider will usually maintain (at least) a set of transactional attributes associated with a userâ€™s identity.
Sharing transactional attributes requires that the identity provider and service provider agree on the roles and entitlements or groups that the user belongs to up front. This is a difficult proposition to implement because two independent providers typically have different ways to group identities or manage role information. Rather than sharing transactional attributes, a provider may map their transactional attributes in a form that the partner understands. In this approach, identity metadata is maintained separately by both identity provider and service provider.
Sharing profile attributes between identity provider and service provider is usually a function of user consent. This is dictated more by user preference and user privacy concerns. Sharing of attributes in many cases requires user consent (opt-in) and the ability to prove user consent. In a pragmatic sense, some attributes may be shared (such as e-mail address) ,whereas some attributes will not be shared. If attributes cannot be shared, then the attributes must be replicated between the identity provider and service provider. For example, if a userâ€™s home address is replicated, both business partners must independently manage this information. If the user moves, and one of the business partners knows about the updated address, in a distinct identity model, the business partner cannot notify or provision this information to other partners.

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:

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:

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:

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:

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
transactional attributes may include a userâ€™s buying history maintained with an online auction house and the bonuses (such as free shipping) that are associated with this userâ€™s transaction history. Examples of provider-specific profile attributes may include a userâ€™s preference to always search for new auction items within the “Toys less than $25” category.

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.

Account Linking:

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.

At a technical level, account linking is the process by which an identity provider and service provider agree on some common unique identifier (CUID), and then each bind their internal, local user identity to this CUID. This enables the identity provider and service provider to refer to the user by their CUID during single sign-on without disclosing information about their local internal representation of the user.

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.

Part of the account-linking process is normally the establishment of some long-term or persistent piece of information, such as an HTTP cookie, that identifies myemployerx.com as this userâ€™s identity provider. During a roll-over period, this can also be used to distinguish between linked and yet-to-be-linked users from myemployerx.com. After the roll-over period has completed, all users without this persistent information must be queried to determine whether myemployerx.com really is their identity provider. (See the next section “Where are you from?” for more information).

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:

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:

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:

SAML assertions that are used to transfer information within a single sign-on protocol
SAML bindings and profiles for a single sign-on protocol

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 available from:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

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.

Liberty:

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.

WS-Security
While WS-Security itself is not a federation or single sign-on specification, it does define the binding of Web Services security tokens. This binding is leveraged within the WS-Federation profile (see next section).

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
WS-Federation is a specification defined by IBM, Microsoft, VeriSign, and RSA within the scope of the IBM-Microsoft Web Services Security Roadmap. WS-Federation was published on July 8, 2003. WS-Federation interoperability between IBM and Microsoft has been demonstrated several times, including by Bill Gates and Steve Mills in New York City in September of 2003. Subsequent to that, a public interoperability exercise was held on March 29-30, 2004 between IBM, Microsoft, and other third-party vendors.

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:

[WS-FED] http://www.ibm.com/developerworks/webservices/library/ws-fed/
[WS-FEDACT] http://www.ibm.com/developerworks/webservices/library/ws-fedact/
[WS-FEDPASS] http://www.ibm.com/developerworks/webservices/library/ws-fedpass/

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.

Federation Standards and Interoperability

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.

Federation Services:

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:

Engage in trust relationships that facilitate direct integration of business processes in the most efficient fashion. The concept of business federations directly provides services for customers who are registered at other (partner) businesses or institutions by establishing business trust relationships.
Share identity information and entitlements in a trusted fashion between companies. Current approaches to identity management generally rely on companies incurring user-lifecycle management costs by maintaining redundant identities to manage employees, business partners, and customers. The relationship between the business and these individuals can change fairly frequently. Each change requires an administrative action that can result in a high cost of user lifecycle management.

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.

Trust Services:

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:

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:

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:

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:

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:

Transport: using SSL to protect HTTP-based Federated Identity Management communications
Message: using encryption and signing to provide confidentiality and integrity protection on messages within a Federated Identity Management flow
Token: using secure tokens to communicate information about a user as part of specific steps within a Federated Identity Management flow

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:

Browser: A browser provides an interface between the end user and the infrastructure. In order to participate in Federated Identity Management protocols, the browser must be capable of supporting redirects or automatic forwarding (POST) of requests (via JavaScript or ActiveX) or both.
Non-HTTP browser: Non-HTML browsers, such as WAP (Wireless Application Protocol) browsers, are used by agents such as mobile devices. These browsers may have limitations that are not found with Internet-based browsers, such as query-string size limitations and content adaptation requirements. Specific techniques to address WAP use cases exist for Federated Identity Management functionality, including the Liberty Alliance LEP profile. These are described in more detail below.
HTTP Point of Contact: The HTTP Point of Contact (PoC) is a generic component that is normally located in the DMZ. It is typically an HTTP reverse proxy or similar component that is capable of authenticating a user and managing that userâ€™s session. Typically, the HTTP PoC will have a connection to a local user registry for validation of the user authentication credentials presented by the user and for retrieval of the authenticated userâ€™s attributes and privilege information for session management.

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:

Authentication, authorization, and session-management services
A centralized session management service for Web (HTTPS) and SOAP Web Services for user-based and service-based transactions
A Policy Decision Point (PDP) with its authorization server and policy server
Several out-of-the-box Policy Enforcement Points (PEP), primarily the HTTP-based WebSEAL reverse proxy and plug-in
The ability to implement customized PEPs through its industry-standard Java™ and C-based API
Authentication services where the authentication process is a direct interaction with the end user (such as a traditional username/password challenge response) or a proprietary IBM Tivoli Access Manager-based cross-domain single sign-on solution In a federated scenario, IBM Tivoli Access Manager establishes and controls a session for a user in response to a federation-based interaction.

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:

Provide session management services for local users, including:
- Authentication services for local users, providing support for direct authentication of users
- Authorization services, providing access control for local resources based on local access policy
Provide access control to Federated Identity Management functionality:
Provide authorization and access to Federated Identity Management federated single sign-on solutions. IBM Tivoli Access Manager authorization decisions can be used to provide fine-granular access to Federated Identity Management, so that only properly authorized users can participate in a federated solution.

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:

Federated Identity Management will be configured as a normal, back-end resource to provide federated single sign-on functionality, including SSO, single sign-off, account linking, and so forth.
Federated Identity Management will rely on IBM Tivoli Access Manager as an authorization service to ensure that only authorized users can invoke Federated Identity Management solutions.
Federated Identity Management will rely on IBM Tivoli Access Manager to identify users for purposes of federation functionality based on information asserted by IBM Tivoli Access Manager (such as iv_user, iv_creds).

Tivoli Access Manager Service Provider Integration:

When an enterprise is configured for service provider functionality, IBM Tivoli Access Manager will:

Provide session management services for local and federation (third-party) users, including:
- Authentication services for local users, providing support for direct authentication of these users
- Session establishment for federation users, based on federated single sign-on functionality implemented by Federated Identity Management
- Authorization services, providing access control for all users to local resources based on local access policy
Provide access control to Federated Identity Management functionality
- Treat Federated Identity Management single sign-on functionality as a publicly available resource.
- Treat Federated Identity Management session life cycle functionality (such as session logout) as a protected resource accessible only to authenticated or authorized users.

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:

Federated Identity Management will be configured as a normal, back-end resource to provide federated single sign-on functionality, including SSO, single sign-off, account linking, and so forth.
Federated Identity Management will rely on IBM Tivoli Access Manager as an authorization service to ensure that only authorized users can invoke Federated Identity Management solutions.
Federated Identity Management will provide IBM Tivoli Access Manager with information to build a session for a user in response to a successful SSO by the user.
Federated Identity Management will rely on IBM Tivoli Access Manager to identify users for purposes of (non-SSO) federation functionality based on IBM Tivoli Access Manager-asserted information (such as iv_user, iv_creds).

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:

Provide local identity management, including workflow and provisioning:
- Apply workflow functionality to the overall management of users within local enterprise, including initiating a possible workflow and approval process (if required) to authorize provisioning to an Federated Identity Management endpoint.
- Provide provisioning solutions to push-create user information at required local endpoints such as application-specific user repositories.

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:

Federated Identity Management will rely on IBM Tivoli Identity Manager as the authoritative source for information that is to be provisioned to federation partners.
Federated Identity Management will act as a local IBM Tivoli Identity Manager endpoint for provisioning purposes.
Federated Identity Management will initiate federated provisioning in response to an IBM Tivoli Identity Manager provisioning request.
Federated Identity Management will receive notification and provisioning responses from federation partners and will “proxy” this information to IBM Tivoli Identity Manager.IBM Tivoli Identity Manager service provider integrationIn general, IBM Tivoli Identity Manager will treat Federated Identity Management as a provisioning source.

When an enterprise is configured for service provider functionality, IBM Tivoli Identity Manager will:

Provide local identity management, including workflow and provisioning:
- Apply workflow functionality to the overall management of users within a local enterprise, including initiating a possible workflow and approval process (if required) to authorize local provisioning based on an Federated Identity Management provisioning trigger.
- Provide provisioning solutions to push-create user information at required local endpoints, such as application-specific user repositories in response to an Federated Identity Management provisioning trigger.

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:

Federated Identity Management may directly provision to IBM Tivoli Identity Manager through the IBM Tivoli Identity Manager service provider interface (SPI).
Federated Identity Management may also provision information to a local repository that is, in turn, monitored by IBM Tivoli Identity Manager to trigger a local IBM Tivoli Identity Manager provisioning event.
Federated Identity Management will proxy any IBM Tivoli Identity Manager provisioning responses (such as status, notification) as required.
Federated Identity Management will appropriately respond to the identity provider federated provisioning functionality with status notification, based on the information received from the local IBM Tivoli Identity Manager.IBM Tivoli Directory Integrator (formerly IBM Directory Integrator)

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:

Synchronizes local identity provider data stores.

Federated Identity Management/ IBM Tivoli Directory Integrator functionality:

In response to events within monitored data stores, builds a WS-Provisioning federated provisioning request.
As part of building a federated provisioning request, implements markup language translation (such as DSMLv2 to DAML) if required.
Acts as client to Federated Identity Management federated provisioning service.

IBM Tivoli Directory Integrator functionality:

Synchronizes local service provider data stores
Receives (WS-Provisioning) federated provisioning request.
As part of building a local provisioning request, implements markup language translation (such as DSMLv2 to DAML) if required.
Receives federated provisioning events, validates them, and triggers local provisioning by provision to a local datastore that is monitored by the local IBM Tivoli Identity Manager.
Receives federated provisioning events, validates them, and directly triggers a provisioning event (including workflow) at the local IBM Tivoli Identity Manager.IBM Tivoli Directory Server (formerly IBM Directory Server)

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

Stores common identifiers that are used when communicating with a service provider or partner about a given local user.
Integrates with a local data store to retrieve information about users as part of building a single sign-on response to an SSO request issued by a service provider.

IBM Tivoli Directory Server service provider integration

Stores common identifiers that are used when communicating with an identity provider or partner about a given local user.
Integrates with a local data store to retrieve information about users as part of building a local session in response to a single sign-on request from an identity provider.

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:

The addition of Federated Identity Management capability can extend the reach of the middleware platform. Services that are deployed on the WebSphere platform can now be extended to a number of third-party clients and their users.
Federated Identity Management enables WebSphere platform users to access various third-party services with simplified single sign-on. This requires no changes to existing Web applications or Web sites.
Federated Identity Management can add significant value to WebSphere Portal by securely connecting Portal users with various third-party and software-as-services providers. By delivering Liberty, WS-Federation, and SAML identity “dial tones,” Federated Identity Management helps organizations use the portal to manage customer-for-life scenarios by enabling the portal to transparently bring in third-party resources and delivering these services to portal users without any changes in user experience.
Federated Identity Management can add significant value to WebSphere Business Integration platform. The ability to broker multiple forms of identity enables WebSphere business integration services to implement mediation services, connecting various users to various services.

Conclusion:

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:

Can reduce identity and security management costs through linkage and reuse between companies. Companies no longer have to separately manage users or identities that are not under their control, thus helping reduce identity lifecycle management costs.
Can achieve order-of-magnitude increases in efficiency through reuse of security infrastructure and end-to-end business process integration.
Can deliver simplified and trusted user experience with single registration and single sign-on because users can navigate easily between Web sites with a single identity and explicitly control release of their personal data.
Can eliminate the friction caused by incompatible identity and security management between 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 industry standards.
© 2004 IBM Corporation. All Rights Reserved.IBM Corporation

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 Our Site

Search the ENTIRE Business Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.

Editorial Policy: Nothing you read in The Business Forum Journal should ever be construed to be the opinion of, statements condoned by, or advice from, The Business Forum Institute, its staff, workers, officers, members, directors, sponsors or shareholders. We pass no opinion whatsoever on the content of what we publish, nor do we accept any responsibility for the claims, or any of the statements made, within anything published herein. We merely aim to provide an academic forum and an information sourcing vehicle for the benefit of the business and the academic communities of the Pacific States of America and the World. Therefore, readers must always determine for themselves where the statistics, comments, statements and advice that are published herein are gained from and act, or not act, upon such entirely and always at their own risk. We accept absolutely no liability whatsoever, nor take any responsibility for what anyone does, or does not do, based upon what is published herein, or information gained through the use of links to other web sites included herein. Please refer to our: legal disclaimer

Home    Calendar   The Business Forum Journal    Features
Concept     History     Library    Formats    Guest Testimonials
Client Testimonials      Search      News Wire     Why Sponsor
Tell-A-Friend     Join    Experts   Contact The Business Forum

The Business Forum
Beverly Hills, California United States of America

Email: [email protected]
Graphics by DawsonDesign
Webmaster: bruceclay.com

© Copyright The Business Forum Institute - 1982 - 2013 All rights reserved.
The Business Forum Institute is not responsible for the content of external sites.
Read more

Search the ENTIRE Business Forum site. Search includes the Business Forum Library, The Business Forum Journal and the Calendar Pages.

Search the ENTIRE Business Forum site. Search includes the Business
Forum Library, The Business Forum Journal and the Calendar Pages.