IBM Tivoli Federated Identity Manager, Version 6.2.2.7

Configuring

The Configuring topics explain how to deploy and configure Tivoli Federated Identity Manager scenarios. Note: Support for Liberty protocol will be deprecated in the later versions of IBM Tivoli® Federated Identity Manager.

PDF
Customizing federation templates
The Federation First Steps tool contains federation templates which you can use to create SAML 2.0 federations. The federation templates are response files that contain macros which are expanded during runtime. You can edit the federation templates to customize some properties.
Federation First Steps tool
Use the Federation First Steps tool to create a generic SAML federation, configure risk-based access, or add service providers as a partner.
Domain configuration
A Tivoli Federated Identity Manager domain is a deployment of the Tivoli Federated Identity Manager runtime component to either a WebSphere® single server or a WebSphere cluster.
Overview of configuration tasks for federated single sign-on
Use Tivoli Federated Identity Manager to establish a single sign-on federation in which users can log in once to access multiple web applications at different providers.
Identity provider and service provider roles
Each partner in a federation has a role. The role is either Identity Provider or Service Provider. An identity provider is a federation partner that vouches for the identity of a user. A service provider is a federation partner that provides services to the user.
Using keys and certificates to secure communications
In a typical production environment, all messages and the communication of those messages between partners and between users in the federation are secured. In addition, you must secure the communication among the servers in your environment, such as the communication between your server and your user registry.
Configuring LTPA and its keys
You must review the Lightweight Third Party Authentication (LTPA) on your WebSphere Application Server after you have installed Tivoli Federated Identity Manager. You can choose to use the default LTPA configuration or modify the configuration so that it is appropriate for your environment.
Setting up message security
Tivoli Federated Identity Manager uses certificates (pairs of public and private keys) to secure messages.
Setting up transport security
To protect the message as it is communicated (transported) between the partners, SAML requires the use of Secure Sockets Layer (SSL) with server authentication and in some cases with mutual authentication.
Selecting a point of contact server
The point of contact server is a proxy or application server that interacts with a user, performs the authentication and manages sessions. In a typical deployment, the point of contact is located at the edge of a protected network in front of a firewall, such as in a DMZ.
Configuring WebSphere as point of contact server
Tivoli Federated Identity Manager can be installed with either an embedded WebSphere server or into an existing WebSphere environment. When you install the embedded server, and use WebSphere as a point of contact server, the installation automates much of the configuration. When you install into an existing WebSphere environment, and want to use WebSphere as a point of contact server, you must manually configure the WebSphere and IHS servers to fit your deployment.
Configuring a Web server plug-in
The Web server plug-in is required to be installed on your Web server only if that server is a supported server other than WebSphere Application Server. The primary function of the plug-in is to extract the user identity information from the LTPA cookie in a Web request and make the identity information available to the target application that is hosted by the Web server using either HTTP headers or server variables (if supported by the Web server).
Setting up the alias service database
SAML 2.0 supports the use of name identifiers (aliases) for communication of user identities between partners. Aliases are intended to increase the privacy of the user when that user accesses resources at a service provider. When aliases are used, an identifier that both the identity and service provider recognize is sent instead of the actual account name of the user. Aliases are created and recorded during account linkage (federation). After account linkage, the alias is in all messages that are sent between the partners. A different alias is used with each partner. The alias used in one direction, such as from identity provider to service provider, can be different from the alias that is used in the other direction, such as from service provider to identity provider.
Planning the mapping of user identities
Plan the mapping of user identities appropriate to your deployment.
SAML federations overview
SAML (Security Assertion Markup Language) is an XML standard for exchanging single sign-on information. It relies on the use of SOAP among other technologies to exchange XML messages over computer networks. The XML messages are exchanged through a series of requests and responses. In this process, one of the federation partners sends a request message to the other federation partner. Then, that receiving partner immediately sends a response message to the partner who sent the request.
SAML endpoints and URLs
Communications within a federation take place through endpoints on the servers of the identity provider and service provider partners.
Sample identity mapping rules for SAML federations
The following topics show the sample identity mapping rules that are provided for SAML federations. If you have decided to use identity mapping rules for your federation, you can review the XSLT rules.
SAML 2.0 Attribute query
The SAML 2.0 attribute query feature extends the capability of the SAML 2.0 protocol. Traditional SAML 2.0 function requires that the identity provider sends all required user attributes to the federation partner. The attributes are included as part of the assertion generated during the single sign-on flow.
Establishing a SAML federation
Establish a SAML federation to complete the configuration of your federation.
Configuring a SAML federation using CLI
To configure a SAML federation using CLI, you must configure the Identity Provider federation, configure the Service Provider federation, and provide the federation configuration properties to your partner.
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.
Configuring an Information Card federation
Information Card reference
OpenID planning overview
Tivoli Federated Identity Manager supports single sign-on through use of the OpenID protocol.
Configuring OpenID
Configure an OpenID federation by creating the federation, setting up the point of contact server, and updating the information on the login pages.
OpenID reference
This section contains a list of references for OpenID. It discusses supported algorithms and transports, and the template pages that are used in a single-sign on flow.
OAuth planning overview
Tivoli Federated Identity Manager supports OAuth 1.0 and OAuth 2.0 protocols. The implementation of OAuth in Tivoli Federated Identity Manager strictly follows the OAuth standards.
Configuring an OAuth federation
To configure an OAuth federation, you must create the federation, add your partner to your federation, and configure the enforcement point for the protected resource.
OAuth reference
This topic contains references about the enforcement points and their custom properties, external authorization service (EAS) stanzas, and HTML template pages for both. This topic applies to both OAuth 1.0 and OAuth 2.0.
Planning a Liberty federation
You must specify the values for federation properties when configuring a Liberty federation. Keep in mind however, that support for Liberty protocol will be deprecated in the later versions of IBM Tivoli Federated Identity Manager.
Configuring a Liberty federation
Configure a Liberty federation by creating the federation, adding a partner to your federation, and providing the new federation configuration information to your partner.
Planning a WS-Federation single sign-on federation
You must specify values for federation properties when configuring WS-Federation.
Configuring a WS-Federation single sign-on federation
To configure a WS-Federation single sign-on federations, you must create the federation, add your partner to your federation, and provide your partner with configuration information from your new federation.
Web services security management configuration
Configuration of Web services security management starts with the establishment of a Tivoli Federated Identity Manager domain. When the domain is established, you can configure the Web services security management component.
Kerberos constrained delegation overview
Tivoli Federated Identity Manager provides a security token service (STS) that can exchange security token formats. This function is used to move user credential information between different token formats, as needed for different applications.
Enabling integrated Windows authentication
These instructions describe how to configure Microsoft IIS for SPNEGO authentication.
Configuring Active Directory and WebSphere for constrained delegation
You must configure Active Directory and WebSphere for your Kerberos delegation to work.
Tivoli Federated Identity Manager configuration for a Kerberos junction scenario
WebSEAL configuration
You must install and configure the Tivoli Access Manager policy server before you install WebSEAL.
SSL configuration task for a Kerberos junctions deployment
For optimal security, configure SSL communication between servers in a Kerberos junction deployment.
Understanding User Self Care
User Self Care provides a method by which users can be provisioned into business-to-consumer environments.
Deploying User Self Care
Tivoli Federated Identity Manager automatically installs User Self Care as part of the runtime. You are not required to install any additional software, unless you plan to use Tivoli Access Manager as the target user registry.
Tuning User Self Care
You can improve User Self Care performance by adjusting settings for several distributed caches.
Response file parameters
Use the parameters described in this section to configure response files for User Self Care.
One-time password
Configure Tivoli Federated Identity Manager to use one-time password as an authentication factor in a federated single sign-on and in an extended authentication scenario.
One-time password deployment
You must configure various components, such as one-time password federation and point of contact, to deploy one-time password authentication. One-time password is valid for either the federated single sign-on or extended authentication scenario.
Tuning the one-time password
Improve the performance of the one-time password system by tuning the OTPProviderDynaCacheOTPStore component.
Customizing runtime properties
Custom properties can be used to tailor the runtime service of the Tivoli Federated Identity Manager to meet specific needs.
Customizing an authentication login form for single sign-on
Customize an authentication login form by adding parameters to a WebSphere or WebSEAL point of contact server profile.
Customizing single sign-on event pages
Tivoli Federated Identity Manager generates files that are displayed in response to events that occur during single sign-on requests. The response displayed might be a form (such as when login information is required) or an error or information statement about a condition that occurred while the request was processed.
Developing a custom point of contact server
The point of contact server in your Tivoli Federated Identity Manager environment is the first entity to process a request for access to a resource. You can choose one of the provided options for a point of contact server or you can create a custom point of contact server.
Customizing signature X.509 certificate settings
When you sign messages or assertions, the X.509 certificate (public key) is included with your signature as a base64-encoded X.509 certificate. However, you can specify whether this data should be excluded and whether additional data should be included with your signatures.
Running WebSphere Application Server with Java 2
If you are running Java™ 2 security on the WebSphere Application Server where Tivoli Federated Identity Manager is installed, you must modify the java.policy to grant permission to the Tivoli Federated Identity Manager directories that are in the temp subdirectory of your WebSphere profile.
tfimcfg reference
Use the tfimcfg command to configure WebSEAL or the Web Gateway Appliance as a point of contact server or configure LDAP settings for the alias service.
URLs for initiating SAML single sign-on actions
The SAML specifications provide limited or no guidance about the endpoints or methods that users must use to initiate single sign-on actions. However, in a Tivoli Federated Identity Manager environment, URLs are defined that user can use to initiate single sign-on actions.
Using the command-line interface to configure Tivoli Federated Identity Manager SHA256 support
Learn how to configure the required parameters from the response file to support SHA256 in Tivoli Federated Identity Manager.
Disabling logging to enhance performance
When using Tivoli Federated Identity Manager with Tivoli Access Manager, you can improve the performance on a service provider by disabling logging for theTivoli Access Manager policy server.

Feedback