The Business Forum

"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 fr