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