IBM Security
© Copyright International Business Machines
Corporation 2003, 2012. All rights reserved.
US Government Users
Restricted Rights – Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
Purpose of this Document
Overview
Customizing the Logon User Interface
Environment Set-up
This document describes the configuration of single sign-on for Identity Governance.
Some Identity Governance installations may be required to be integrated with third party single sign-on providers. Typically, such single sign-on providers protect a set of web-based resources using an authentication data store that is managed separately from Identity Manager. The first time a client attempts to access any protected resource, the single sign-on provider will authenticate and, if successful, will pass a token indicating the identity of the authenticated user to all subsequently accessed resources.
When using a single sign-on provider with Identity Governance it will be necessary to add a customized logon user interface specific to the single sign-on provider. Typically, single sign-on providers intercept http requests to a protected resource, authenticate the user, and place authentication data into the http header before allowing access to the resource. In this case the protected resource is the Identity Governance user interface.
The standard logon user interface provided with Identity Governance will not be appropriate, since it will prompt the user for a user id and password. An Identity Governance logon interface customized for a single sign-on logon provider will typically collect user credentials from the sign-on provider, verify that the user has a Identity Manager account, establish an Identity Governance session, and forward the user into the Identity Governance system.
Logout and session timeout are related problems that can also be addressed to fit in with custom approaches.
Figure 1 describes the actors involved in managing and using a system configured for user with a single sign-on provider.
A description of the actors is presented in Table 1.
| Actor | Description |
| User | The user tries to access Identity Governance’s web user interface |
| Single sign-on provider | Protects access to Identity Governance’s web user interface |
| SSO Provider User Data store | Stores user identities and logon credentials used by the single sign-on provider |
| Directory Server | Data store used by Identity Governance |
The steps when a user logs in via a single sign-on provider:
A custom logon user interface appropriate to custom authentication methods may be added to Identity Governance. There are two steps required:
The Identity Governance framework requires an Identity Governance user id at logon time in order to establish an Identity Governance session. An SSO Adapter that examines the incoming HTTP request for logon information placed in the header by an external authentication authority may implement this.
An example for the same is , SampleSSOAdapter.java (which implements the SSOAdapter interface) provided in the examples directory.
To establish an Identity Governance session and forward the user to the Identity Governance application, use the SampleSSOAdapter.java class. The customer needs to provide the implementation for the following methods in the implementation class of SSOAdapter interface:
isAuthenticated(HttpServletRequest request)
This method returns true if the request object passed to this method is authenticated via an SSO provider. Otherwise,it will throw ITIMUIException or ITIMUISSOUserIdNotFoundException.
getUserId(HttpServletRequest request)
This method returns the ISDI User ID that identifies the authenticated user. The SSO adapter should use information stored in the HTTP request to identify the ISDI user. If the user id used to the authenticate to the SSO provider does not match the ISDI user id, the adapter is responsible for mapping/returning the ISDI user id.
Note : The SampleSSOAdapter.java provided in the $ISDI_HOME\extensions\examples\singlesignon\src\examples\singlesignon example is only a sample implementation provided for user's reference. It does not cater to the specific security requirements of the user. In this example, only null check of the user id is present as an authentication mechanism. Hence while using the same for a production environment , kindly perform the required modifications in this class.
Details of the SSOAdapter interface, ITIMUIException, ITIMUISSOUserIdNotFoundException classes are provided in the API documents.
When the user logs out, their session will be terminated and by default they will be directed back to the Identity Governance logon page. If this is not appropriate a new logout URL should be registered. The property enrole.ui.logoffURL in file ui.properties should be set to the URL where the user should be directed to when logging out of the Identity Governance application. This may be set to the URL of a HTML page, a JSP page, a Servlet, or some other web resource.
It is desirable that, on logging out, the user’s HTTP session be terminated. This can be done by a call to session.invalidate().
If the user’s session times out then, by default, the user will again be forwarded to the logon page. This may also be inappropriate for a single sign-on protected installation. A separate session timeout URL is defined for this by the parameter enrole.ui.timeoutURL in the ui.properties configuration file.
All custom code written must be compiled and added to the application server classpath. An appropriate place to locate the classes is in the lib directory under $ISDI_HOME. The classes should be put into a jar file. If the classes are placed in $ISDI_HOME/lib, then you should modify the WebSphere shared library ITIM Lib to include your jar file. Using the WAS admin console, navigate to Environment > Shared Libraries and select ITIM Lib. Then add a new line to the Classpath text box that looks something like:
${ITIM_HOME}/lib/your_custom_jar.jar
Save the changes and restart WAS to have your custom code included in the Classpath.