Planning an Information Card federation

This planning guide reviews the Tivoli® Federated Identity Manager implementation of the Information Card standard, and describes how to plan the configuration process. This guide does not provide a comprehensive review of the Information Card standard.

You can use the Information Card system to manage your digital identities from various identity providers. Then, you can and use these digital identities to access various services that accept these digital identities.

Administrators who are not familiar with the standard must review the Information Card documentation in the Microsoft website.

The Tivoli Federated Identity Manager support for Information Card includes deployment of Tivoli Federated Identity Manager in both of the Information Card roles: Managed Identity Provider and Relying Party.

The protocol flow when the user provides an information card to authenticate at a website, resembles the forms-based login flow. However, it requires extra steps.

1. User directs the browser to a protected web page that requires authentication.
2. The site redirects the browser to a login page. In an Information Card-enabled browser, the login page contains an HTML tag that allows the user choose an Information Card to authenticate to the site. When the user selects the tag, the browser starts the identity selector.
   Note: An identity selector is a browser plug-in that enables the browser to use the Information Card protocol. The plug-ins are sometimes called identity agents.
3. The browser support code for Information Cards starts the identity selector. Then, the browser passes to the identity selector the parameter values supplied by the Information Card HTML tag obtained from the website in Step 2.

   The user then selects an Information Card, which represents a digital identity that can be used to authenticate at the site.

4. The identity selector sends the information card to the Tivoli Federated Identity Manager identity provider. The identity provider uses the Tivoli Federated Identity Manager security token service to process the WS-Trust message and WS-Metadata Exchange. Then, it generates a token that contains the user credentials. The identity provider returns the token to the browser.
   Note: IBM® deprecated the Tivoli Federated Identity Manager Security Token Service (STS) Client in this release.

   If you use WebSphere® 6.X, you can still use the Tivoli Federated Identity Manager Security STS client while Tivoli Federated Identity Manager supports WebSphere 6.X. When Tivoli Federated Identity Manager discontinues its support for WebSphere 6.X, use WebSphere Application Server version 7 Update 11 and later. See WS-Trust client API and WS-Trust Clients for details.

5. The browser forwards the user credentials to the website that protects the requested resource. The site validates the credentials and redirects the browser back to the requested page.

In the protocol flow, the Relying Party and the identity provider do not communicate directly with each other. By default, neither party is aware of the other. The Relying Party does not know which identity provider was selected by the user until the token is received in Step 5. At that time, the Relying Party can learn the identity by examining the Issuer field in the token.

You can use the Information Card to prompt the identity provider to require identification from the Relying Party. However, doing so is not a requirement, and is typically discouraged.