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.
Tivoli® Federated Identity Manager is not directly involved in user authentication or the creation of an application session. Instead, Tivoli Federated Identity Manager relies on a point of contact server.
The point of contact server provides endpoints, which are the locations to and from which messages are sent and received. Each endpoint has a URL, so that the endpoints can be accessed by external users as Web sites on the Internet. The point of contact receives access requests and provides the authentication service.
It serves as the first component capable of evaluating the authentication credentials of the user that is requesting access to the protected network. It also manages session lifecycle of the user, from session creation, to session access, to session deletion (such as in response to session logout services).
If you must use IBM WebSphere Application Server, your configuration options depend on whether you assume the identity provider partner, or the service provider partner role.
You can use the following hosting application options in a federation that is configured in Tivoli Federated Identity Manager:
Each of these options has specific requirements. For more information about these requirements, see WebSphere as point of contact for identity providers and WebSphere point of contact server for a service provider.
To satisfy the functional requirements for a point of contact server, Tivoli Federated Identity Manager can leverage the extensive authentication and authorization capabilities of Tivoli Access Manager. In environments that use Tivoli Access Manager, a WebSEAL server typically acts as the point of contact.
WebSEAL is most commonly used as a reverse proxy that can control access to extensive protected resources, through the establishment and management of WebSEAL junctions. WebSEAL receives access requests, and serves as the first component capable of evaluating the authentication credentials of the user that is requesting access to the protected network. In addition, the point of contact must handle Web session management for user sessions.
The federation creation wizard requires specification of a URL for point of contact servers. The wizard presents a field in which to enter the URL that provides access to endpoints on the Point of Contact server. The URL must contain the following elements:
Note that this value must match how you configured your point of contact server (WebSEAL).
For example:
https://For example:
idp.example.comFor example:
/FIMThese parts are combined to form a URL. For example:
https://idp.example.com/FIM/spsLater in the federation configuration, the URL is extended further when you select a choice of single sign-on protocol and assign more specific endpoints for profiles such as login and logout. This means that this URL becomes part of a number of longer URL paths (endpoints) that are managed as Tivoli Access Manager protected objects.
Tivoli Access Manager deployments often include both a policy server (pdmgrd) and an authorization server (acld). Tivoli Access Manager requires a deployed policy server, but does not require an active authorization server. Tivoli Federated Identity Manager also requires only a deployed policy server. The WebSEAL point of contact server does not depend on an authorization server for any authentication or authorization services.
By default, the Default IVCred Module Instance in the product contacts the Tivoli Access Manager authorization server (also known as pdacld) to issue a credential. A skeleton credential is then built from the user name. This credential includes the groups (and Universal User IDs) for that user as defined in the user registry for Tivoli Access Manager. However, when you select WebSEAL No ACLD as the point of contact, the product does not use the authorization server to build credentials.
The generic point of contact is an additional point of contact implementation provided by Tivoli Federated Identity Manager. It is a HTTP-headers based solution that provides administrators with the ability to modify their point of contact environments (for example, Apache) to set and read headers. This allows integration with Tivoli Federated Identity Manager without writing a custom point of contact server.
The generic point of contact works pretty much the same as the WebSEAL point of contact server. The main difference is that headers names are used for the user information.
There generic point of contact server is included in the point of contact profiles that ship with Tivoli Federated Identity Manager. The administrator must enable it by selecting it on the console and setting it as active. The administrator can use the console to modify the header names used by each callback.
For example, a custom point of contact server would be useful in the following scenarios:
Developing a custom point of contact server requires programming experience with developing callback modules and knowledge of Tivoli Federated Identity Manager programming concepts. See the developerWorks® links in the information center at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.tivoli.fim.doc_6.2.2/ic/ic-homepage.html.
When you have completed the development work, integrate the solution with your Tivoli Federated Identity Manager environment. For more information, see the IBM Federated Identity Manager Administration Guide.