Isim Security PDF 70

IBM Security Identity Manager
Version 7.0.1.7
Security Topics
IBM
Version 7.0.1.7
Security Topics
IBM
ii IBM Security Identity Manager Version 7.0.1.7: Security Topics
Table of contents
Table list . . . . . . . . . . . . . . v Changing the logoff page . . . . . . . . . 31
Creating a user in IBM Security Access Manager
Chapter 1. Application server security that WebSEAL uses to connect to the backend
server . . . . . . . . . . . . . . . 32
and IBM Security Identity Manager . . . 1 Defining IBM Security Access Manager Accounts 33
Defining IBM Security Access Manager groups 34
Chapter 2. External user registry for Adding IBM Security Access Manager user
authentication . . . . . . . . . . . . 3 account to a group . . . . . . . . . . . 35
Defining a junction that points to IBM Security
Chapter 3. Secure environment practices 5 Identity Manager Server . . . . . . . . . 35
Defining IBM Security Access Manager ACLs . . 37
Granting access to the IBM Security Access
Chapter 4. Secure sockets layer Manager ACLs . . . . . . . . . . . . 37
communication . . . . . . . . . . . 7 Associating the WebSEAL junction to the ACLs 39
SSL terminology . . . . . . . . . . . . . 7 Configuring IBM Security Identity Manager to
One-way and two-way SSL authentication . . . . 8 use single sign-on . . . . . . . . . . . 40
SSL in a clustered environment . . . . . . . . 9 Configuring WebSEAL. . . . . . . . . . 40
SSL implementations . . . . . . . . . . . 9 IBM Security Identity Manager web services in a
single sign-on environment . . . . . . . . . 41
Chapter 5. Certificate file types . . . . 11 Installing on a system where the IBM Security
Identity Manager is installed . . . . . . . 42
Chapter 6. Securing of communication Installing on a separate system than where the
IBM Security Identity Manager is installed . . . 44
with adapters . . . . . . . . . . . . 13
Starting the SSO application . . . . . . . . 46
Testing the SSO application . . . . . . . . 47
Chapter 7. Securing of communication Building the SSO application . . . . . . . 47
with custom applications . . . . . . . 15 Preparing the WebSphere Application Server . . 49
Accessing IBM Security Identity Manager consoles 50
Chapter 8. Secure communication with Frequently used commands to configure single
supported middleware . . . . . . . . 17 sign-on . . . . . . . . . . . . . . . . 51
Example SSL configurations . . . . . . . . . 17
Preparation for SSL configuration . . . . . . . 18 Chapter 10. Security layer
Creating a certificate . . . . . . . . . . . 18 configuration around the data model
Configuring SSL for the database server . . . . . 20 and reports . . . . . . . . . . . . . 55
Configuring SSL for the directory server . . . . . 20 Authentication and authorization for IBM Cognos
Configuring SSL on the application server . . . . 21 reports . . . . . . . . . . . . . . . . 55
Configuring the IBM Security Identity Manager User authentication setup by using LDAP . . . . 55
Server . . . . . . . . . . . . . . . . 22 Configuring an LDAP Namespace for IBM
Testing SSL communication between servers . . . 23 Directory Server . . . . . . . . . . . . 55
Configuration of the HTTP server for additional Creating users in an LDAP . . . . . . . . . 57
security and performance. . . . . . . . . . 24 Access control definition for the reports and
SSL for the IBM HTTP server and Application reporting packages . . . . . . . . . . . . 58
server plug-in . . . . . . . . . . . . . 25 Restricting administration access and adding an
Configuring SSL for the IBM HTTP server . . . 25 LDAP user to system administrator role . . . . 58
Configuring SSL for the plug-in . . . . . . 26 Creating a role and adding LDAP users as
members . . . . . . . . . . . . . . 59
Chapter 9. Configuration of single Defining an access to the report by using a role 60
sign-on . . . . . . . . . . . . . . 29 Defining an access to the reporting package by
Configuration of IBM Security Identity Manager for using a role . . . . . . . . . . . . . 60
single sign-on with Application server Trust References for IBM Cognos report security
Association Interceptor and IBM Security Access configuration . . . . . . . . . . . . . . 61
Manager WebSEAL . . . . . . . . . . . . 29
Account mapping . . . . . . . . . . . 30 Index . . . . . . . . . . . . . . . 63
iii
iv IBM Security Identity Manager Version 7.0.1.7: Security Topics
Table list
1. Practices for a secure IBM Security Identity 3. Files in the /certs directory . . . . . . . 19
Manager environment . . . . . . . . . 5 4. Logoff pages . . . . . . . . . . . . 31
2. Example SSL configurations . . . . . . . 18 5. LDAP advanced mapping values . . . . . 56
v
vi IBM Security Identity Manager Version 7.0.1.7: Security Topics
Chapter 1. Application server security and IBM Security
Identity Manager
IBM® Security Identity Manager uses Application server security.
IBM Security Identity Manager uses Application server security to enforce

authentication and role-based authorization. Application server security includes
administrative security. Application server administrative security must be enabled
before IBM Security Identity Manager is installed. Application server security
supports security domains, which can be used to define a security scope that is not
global, but applicable to a specific application. Application server also supports
application security. IBM Security Identity Manager requires Application server
application security. You can enable application security at the security domain
level, or you can enable it at the global security level.
When you install IBM Security Identity Manager, you select either the default
custom registry that is provided with IBM Security Identity Manager, or you select
an external user registry. If you choose the default custom registry, the installation
program automatically creates a security domain that has application security
enabled. If you select an external user registry, you must manually enable
application security for the security domain that IBM Security Identity Manager
uses.
The external user registry can operate at the global security level, or can be part of
a specific security domain. If you select an external user registry that is used for
global security, then you must enable application security for global security. If you
select an external user registry that is associated with a security domain, then you
must enable application security for that security domain.
For information on using an external user registry, see Chapter 2, “External user
registry for authentication,” on page 3.
© IBM Corp. 2007, 2013 1

2 IBM Security Identity Manager Version 7.0.1.7: Security Topics
Chapter 2. External user registry for authentication
You can choose to use an external user registry instead of the default custom
registry.
IBM Security Identity Manager provides a default custom registry. You do not have
to use this registry for authentication. You can choose to use an external registry.
An external user registry is any other registry that can be configured with
Application server. You can use an existing registry or configure a new one.
For more information, see Configuring the Identity external user registry.
v If you use the custom registry, the IBM Security Identity Manager installation
program programmatically creates a security domain, enables application
security, and configures it to the IBM Security Identity Manager custom registry.
v If you use an external registry, you must manually configure application security.
To use an external user registry, you must complete specific configuration tasks.
See Configuring the Identity external user registry
External user registry example deployment
The IBM Security Identity Manager product distribution includes three documents
that describe an example deployment with an external user registry. The following
documents are included in the directory /extensions/7.0/doc/authentication/:
Do these steps to access the documents:

1. Log on to the IBM Security Identity Manager virtual appliance console to open
the Appliance Dashboard.
2. From the top-level menu of the Appliance Dashboard, select Configure >
Advanced Configuration > Custom File Management to display the Custom
File Management page.
3. Click the All Files tab.
4. Go to directories/utilities.
5. Select extensions.zip and click Download.
6. Extract the extensions.zip file.
7. Go to /extensions/version_number/doc/authentication/. For example,
version_number is 7.0.
© IBM Corp. 2007, 2013 3

Chapter 3. Secure environment practices
These practices can help ensure a secure IBM Security Identity Manager
environment.
Table 1. Practices for a secure IBM Security Identity Manager environment
Given sensitive data in these areas Ensure that these practices occur
Database data Restrict operating system access to database
files. Limit the privileges of the operating
system accounts (administrative,
root-privileged, or DBA) to the least
privileges needed. Change the default
passwords. Enforce periodic password
changes. See the security information in the
database documentation for more details.
Database logs Restrict operating system access to log and
trace files. Limit the privileges of the
operating system accounts (administrative,
root-privileged, or DBA) to the least
privileges needed. Change the default
passwords. Enforce periodic password
changes. See the security information in the
Database backups Store database backups at safe and secure
locations. Guard against leaks or exposure of
sensitive and confidential information. See
the security and backup information in the
LDAP data Securely handle any LDAP data that
contains sensitive information. Sensitive
information includes disabling anonymous
read, enabling SSL, and restricting access to
privileged and authorized operating system
and application users. See the security
information in the LDAP directory server
documentation for more details.
LDAP logs Restrict access to log files in the log
directory of the directory server to
privileged and authorized operating system
and application users. This restriction is
especially important if you enable audit
logging for the directory server. See the
security information in the directory server
documentation for more details.
LDAP backups If LDIF files contain sensitive information,
store them safely and handle them securely.
IBM Security Identity Manager logs If Security Identity Manager logs in the
path/ibm/tivo../../common/CTGIM directory
contain sensitive information, restrict access
to them.
Directories under ISIM_HOME If the data, configuration, and installation
logs contain sensitive information, restrict
access to the directories in ISIM_HOME.
5
Table 1. Practices for a secure IBM Security Identity Manager environment (continued)
Given sensitive data in these areas Ensure that these practices occur
Network traffic Restrict network traffic to what is required
by the deployment. If you write your own
application and use an IBM Security Identity
Manager API to retrieve sensitive data,
encrypt the data before you send it over the
network.
WebSphere® Application Server security Enable security on WebSphere Application
Server and disallow running WebSphere
Application Server with a non-root account.

Chapter 4. Secure sockets layer communication
The industry-standard Secure Sockets Layer (SSL) protocol uses signed digital
certificates from a certificate authority (CA) for authentication. It provides secure
communication in an IBM Security Identity Manager deployment.
SSL provides encryption of the data that is exchanged between the applications. An
application that acts as an SSL server presents its credentials in a signed digital
certificate to verify to an SSL client that it is the entity it claims to be. You can also
configure an application that acts as an SSL server to require the application that
acts as an SSL client to present its credentials in a certificate. This method
completes a two-way exchange of certificates.
SSL terminology
These terms apply to Secure Sockets Layer communication for IBM Security
Identity Manager.
SSL server
Listens for connection requests from SSL clients. For example, theIBM
Security Directory Server might be an SSL server that listens for connection
requests from the IBM Security Identity Manager Server and the
WebSphere Application Server.
SSL client
Issues connection requests. For example, the computer on which the IBM
Security Identity Manager Server and the WebSphere Application Server
are installed is the SSL client, which issues connection requests to the IBM
Security Directory Integrator.
Signed certificates
Is an industry-standard method of verifying the authenticity of an entity,
such as a server, client, or application. Signed certificates are issued by a
third-party certificate authority for a fee. Some utilities, such as the
iKeyman utility, can also issue signed certificates. A certificate authority or
CA certificate must be used to verify the origin of a signed digital
certificate.
Signer certificates (certificate authority certificates)
Must be used to verify the origin of a signed digital certificate. When an
application receives a signed certificate from another application, it uses a
CA certificate to verify the originator of the certificate. Many applications,
such as web browsers, are configured with the CA certificates of
well-known certificate authorities. This practice eliminates or reduces the
task of distributing CA certificates throughout the security zones in a
network.
Self-signed certificates
Contains information about the owner of the certificate and the owner of
the signature. Basically, it is a signed certificate and CA certificate in one. If
you choose to use self-signed certificates, you must extract the CA
certificate from it in order to configure SSL.
SSL keystore
Is a key database file designated as a keystore. It contains the SSL
certificate.
7
Note: The keystore and truststore can be the same physical file.
SSL truststore
Is a key database file designated as a truststore. The SSL truststore contains
the list of signer certificates (CA certificates) that define which certificates
the SSL protocol trusts. Only a certificate issued by one of these listed
trusted signers is accepted.
Note: The truststore and keystore can be the same physical file.
One-way SSL authentication
Requires a keystore and certificate only on the SSL server side (such as the
Security Directory Server) and a truststore only on the SSL client side (such
as the Security Identity Manager Server).
Two-way SSL authentication (client-side authentication)
Requires a keystore with a certificate and a truststore that contains the
signer of the certificate that issued the other certificate on both the SSL
server and client.
One-way and two-way SSL authentication

Configuring communication between an SSL server and client can use one-way or
two-way SSL authentication. For example, the SSL client is the computer on which
the IBM Security Identity Manager Server is installed, and the SSL server is the
IBM Security Directory Server.
One-way authentication creates a truststore on the client and a keystore on the

server. In this example, CA certificate "A" exists in the truststore on the SSL client
and also in the keystore on the SSL server.
IBM Security Identity Manager Security Directory Integrator

(SSL client) (SSL server)
Truststore Keystore
CA certificate “A” CA certificate “A”
Figure 1. One-way SSL communication
Two-way authentication creates a truststore and a keystore on both the client and
the server. In this example, there is a CA certificate "A" in the truststore and a CA
certificate "B" in the keystore on both client and server.

IBM Security Identity Manager Security Directory Integrator
(SSL client) (SSL server)
Truststore Truststore
CA certificate “A” CA certificate “B”
Keystore Keystore
Certificate “B” Certificate “A”
Figure 2. Two-way SSL communication
For more information about configuring SSL communication between the IBM
Security Identity Manager Server and an IBM Security Identity Manager adapter,
see the installation and configuration guide for the adapter.
SSL in a clustered environment

Communication between an SSL server and client can use one-way or two-way
SSL authentication. For example, the SSL client is the computer on which the IBM
Security Identity Manager Server is installed. The SSL server is the IBM Security
Directory Server.
1. From the top-level menu of the Appliance Dashboard, click Configure >
Manage Server Setting > Single Sign-On Configuration.
2. On the Single Sign-On Configuration page, click Configure.
3. In the Single Sign-On Configuration Details window, specify the expected
variable values.
4. Click Save Configuration to complete this task.
For more information, see Managing the single sign-on configuration.
SSL implementations
IBM Security Identity Manager Server uses several implementations of the SSL
protocol.
IBM Security Identity Manager Server uses these implementations of the SSL
protocol:
IBM Global Security Toolkit (GSKit)
Used by the WebSphere Application Server, IBM Security Directory Server,
and IBM Security Identity Manager adapters.
IBM Java™ Secure Socket Extension (JSSE)
Used by the IBM Security Identity Manager Server and by IBM Security
Directory Integrator
Chapter 4. Secure sockets layer communication 9

OpenSSL
Used by IBM Security Identity Manager Server Adapter Development Kit
(ADK)-based adapters.

Chapter 5. Certificate file types
Certificates and keys are stored in several types of files.
Files that store certificates and keys can have the following formats:
.pem A privacy-enhanced mail file with a file extension of .pem. It begins and
ends with the following lines:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
A privacy-enhanced mail format supports multiple digital certificates,

including a certificate chain. If your organization uses certificate chaining,
use this format to create CA certificates.
.arm A file with an extension of .arm contains a base-64 encoded ASCII
representation of a certificate. It includes its public key but not its private
key. The IBM Key Management utility generates and uses an .arm format.
Specify this format to extract a self-signed certificate from the computer on
which it was generated to the computer that uses it as the CA certificate.
.der A file with an extension of .der contains binary data. This format can be
used only for a single certificate, unlike a file with a privacy-enhanced mail
format, which can contain multiple certificates. Specify this format to
extract a self-signed certificate from the computer on which it was
generated to the computer that uses it as the CA certificate.
.pfx (PKCS12)
A PKCS12 file has an extension of .pfx. It contains a certificate (CA-issued
certificate or self-signed certificate) and a corresponding private key. Use
this format to transfer the contents of a keystore to a separate computer.
For example, you can create and install a certificate and private key with
the key management utility. You can then export them to a PKCS12 file and
import the file into another keystore. This format is also useful for
converting from one type of SSL implementation to a different
implementation. For example, you can create and export a PKCS12 file with
the IBM Key Management utility and then import the file on another
computer with the OpenSSL CertTool utility.
11
Chapter 6. Securing of communication with adapters
The IBM Security Identity Manager Server uses either SSL or Secure Shell (SSH)
communication to communicate securely with supported adapters.
Figure 3 illustrates how you can configure secure communication links.
Security A UNIX
IBM Security d SSH
Identity Directory a managed
Manager SSL Integrator p resource
Server t
e
r LDAP
SSL
managed
resource
S
S
L
Other
adapters
KEY:
SSL = One-way or two-way SSL
SSH = Secure Shell protocol

Figure 3. Secure communication in the IBM Security Identity Manager environment
Managed resources can communicate with the IBM Security Identity Manager
adapters with the following protocols:
SSL Configures adapters, such as Windows Server Active Directory or Lotus
Notes®, to use SSL authentication to communicate with the IBM Security
Identity Manager Server. Not all adapters use the same SSL configuration.
For more information, see the installation and configuration guide for the
specific adapter.
Secure Shell (SSH)
Is used between the adapter and managed resource. The SSH protocol
requires no configuration. The use of SSH between the adapter and
managed resources cannot be disabled. However, configuration of SSH
might be required on the managed resource. For more information, see the
IBM Security Identity Manager adapter installation and configuration
guides for UNIX and Linux.
13
Chapter 7. Securing of communication with custom
applications
If you develop custom applications to access the IBM Security Identity Manager
Server, these applications must adhere to the programming guidelines described in
this section.
These guidelines ensure that:

v Security boundaries built into the IBM Security Identity Manager Server are
observed strictly.
v Only authorized application programming interfaces (APIs) are used for
communication between the server and custom applications.
v Appropriate roles are assigned to users and user groups that use custom
applications to access IBM Security Identity Manager functions.
IBM Security Identity Manager shields its core functions with a layer of managed
enterprise Java beans (EJBs). These EJBs are in an unprivileged layer of the IBM
Security Identity Manager, which is illustrated in Figure 4.
When the IBM Security Identity Manager communicates with a client application,
every managed EJB method takes a signed token from the caller. The token verifies
the caller identity, except when the method does the authentication. The caller
obtains this signed token after authentication with the IBM Security Identity
Manager Server.
WebSphere Application Server

Server (EJB server)
Web EJB
container Container
Browser
IBM
Web application Security
(JSPs/servlets) Identity
Manager
core logic
Privileged
IBM Security
Identity Manager EJBs
APIs
Managed
(unprivileged)
EJBs
IBM Security Identity

Manager APIs
Custom application
Figure 4. Security layers in IBM Security Identity Manager Server
15
The following types of custom applications can be created to communicate with
the IBM Security Identity Manager Server:
Stand-alone Java client
Deployed as a WebSphere Application Server thin client.
Web application
Deployed outside of WebSphere Application Server. A web application can
start only a specific subset of IBM Security Identity Manager Server APIs.
Enterprise application, same Java virtual machine (JVM)
Deployed in the same server instance (enrole.ear) as the IBM Security
Identity Manager Server .
Enterprise application, separate JVM
Deployed on the same computer as the IBM Security Identity Manager
Server, but runs as a separate JVM process.
Servlets
Deployed on a separate computer that runs WebSphere Application Server.
Servlets are not deployed in the context of a web application.
When you develop custom applications to communicate with the IBM Security
Identity Manager Server, use the following rules to ensure secure communication:
v Allow only published APIs to access the managed EJBs in the unprivileged area.
v Allow custom applications to use only the functions that the APIs provide.
v Ensure that the computer on which the IBM Security Identity Manager Server
runs is always secure.
WebSphere Application Server uses roles to manage access to application

components and other objects, including user and group names. Use the following
guidelines for assigning roles in custom applications that interface with IBM
Security Identity Manager Server.
ITIM_SYSTEM
This role is defined when the IBM Security Identity Manager Server is
deployed into WebSphere Application Server. ITIM_SYSTEM is used by IBM
Security Identity Manager Server components. It is authorized to call all
EJB methods in both privileged and unprivileged layers. Do not assign any
principal names or user IDs to this role without prior consultation with an
IBM representative.
ITIM_CLIENT
This role is authorized to call only managed EJB methods in the
unprivileged layer. Map to this role the users, and user group names, and
other principals that perform less restricted tasks in the IBM Security
Identity Manager Server.

Chapter 8. Secure communication with supported middleware
The IBM Security Identity Manager Server uses SSL for secure communication with
supported middleware, such as a directory server.
Your configuration might be similar to the cluster configuration example in

Figure 5.
Backup Primary node
Appliance Cluster
Web server /
Managed resource Reverse proxy /
Load balancer
Directory server
Database server
Cognos server
server
Figure 5. Initial cluster configuration
After initial installation, you might configure secure communication links between
IBM Security Identity Manager Server and these applications:
v Database server
v Directory server
v HTTP server
v Web browser
v Other supported middleware
Example SSL configurations

Example SSL configurations include secure communication between IBM Security
Identity Manager Server and the directory server and between an HTTP server and
a web browser.
In Table 2 on page 18, the first application is the SSL client, and the second
application is the SSL server:
17
Table 2. Example SSL configurations
One-
way Two-
SSL client SSL server SSL way SSL
IBM Security Identity Manager LDAP directory server
Server
HTTP server (IBM HTTP IBM Security Identity Manager
Server) Server
Web browser IBM Security Identity Manager
Server
Your site might require additional configuration for SSL authentication with the
IBM Security Identity Manager Server.
Preparation for SSL configuration

Before you configure SSL for secure communication, install and configure IBM
Security Identity Manager Server. Then, locate IBM Global Security Kit (GSKit) to
generate certificates.
Complete these tasks:

1. Install and configure the IBM Security Identity Manager Server and required
supported middleware, including the directory server. This example assumes
that a cluster configuration exists and that the directory server is on a separate
computer.
2. Ensure that the initial configuration is running correctly. For more information,
see IBM Security Identity Manager Configuration Guide.
3. Locate the IBM Global Security Kit (GSKit), which is included in the IBM
Security Directory Server that the initial configuration installs. For example,
locate the /path/local/ibm/gsk7/bin directory on the computer that has the
Security Directory Server, where path is a value such as usr.
The GSKit package provides the iKeyman key management utility, gsk7ikm. Use
the utility to create key databases, public-private key pairs, and certificate
requests. The following steps assume that you use the iKeyman utility to create
self-signed certificates for secure communication. Alternatively, you can use the
WebSphere Application Server administrative console to create a self-signed
certificate.
A self-signed digital certificate is a temporary digital certificate that you issue
to yourself with yourself as the certificate authority (CA). When you complete
testing, replace the self-signed certificate with a certificate signed by a CA
certificate from a well-known certificate authority.
Creating a certificate
Use the iKeyman utility to create a self-signed certificate and extract the certificate
to make it available for secure communication.
Before you begin

Depending on how your system administrator customized your system, you might
not have access to this task. To obtain access to this task or to have someone
complete it for you, contact your system administrator.

About this task
The iKeyman utility is in the IBM Security Directory Server.
Procedure
1. Start the iKeyman utility. For example, type the gsk7ikm command in the
/usr/local/ibm/gsk7/bin directory
2. If the iKeyman utility cannot locate Java, run this command: export
JAVA_HOME=opt/IBM/ldapv6.1/java/jre
3. On the IBM Key Management page, select Key Database File > Open > New.
4. Select a default database type of CMS.
5. In the File Name field, type a name for the CMS key database file. For
example, type: LDAPSERVER_TEST1234.kbd
For example, the value specifies application_serverhostname where application is
the directory server, and serverhostname is the computer that has the directory
server.
6. In the Location field, specify a location to store the key database file. For
example, type /certs.
7. Click OK.
8. On the Password menu:
a. Type and then confirm a password, such as Pa$$word1.
b. Specify the highest password strength possible.
c. Specify Stash the password to a file?.
d. Click OK.
9. Select Create > New Self Signed Certificate and specify a label that matches
the CMS key database file name, such as LDAPSERVER_TEST1234.
This example uses the same name (LDAPSERVER_TEST1234) for both the
certificate name and the key database file that contains the certificate.
10. Type IBM in the Organization field, accept the remaining field default values,
and click OK. A self-signed certificate, including public and private keys, now
exists.
11. For subsequent use with clients, extract the contents of the certificate into an
ASCII Base-64 Encoded file. Complete these steps:
a. Select Extract Certificate.
b. Specify a data type of Binary DER Data.
A file with an extension of .der contains binary data. This format can be
used only for a single certificate. Specify this format to extract a self-signed
certificate.
c. Specify the name of the certificate file name you created, such as
LDAPSERVER_TEST1234.der.
d. Specify a location, such as /certs, in which you previously stored the key
database file
e. Click OK.
12. Verify that the /certs directory contains the following files:
Table 3. Files in the /certs directory
File Description
LDAPSERVER_TEST1234.crl Not used in this example.
LDAPSERVER_TEST1234.der The certificate.
Chapter 8. Secure communication with supported middleware 19

Table 3. Files in the /certs directory (continued)
File Description
LDAPSERVER_TEST1234.kbd Key database file that has the certificate.
LDAPSERVER_TEST1234.rdb Not used in this example.
LDAPSERVER_TEST1234.sth Stash file that has the password
Note: If you use an existing or newly acquired certificate from a CA, copy it
to the /certs directory on root file system of the directory server.
Alternatively, you can use the WebSphere Application Server administrative

console to create a self-signed certificate:
a. Select Security > SSL certificate and key management > Manage
endpoint security configurations > {Inbound | Outbound} >
ssl_configuration > Key stores and certificates > [keystore ]. From
Additional Properties, click Personal certificates.
b. Click Create a self-signed certificate
What to do next
For more information, see:
v Topics on securing directory communications in the IBM Security Directory Server
Administration Guide at
http://www.ibm.com/support/knowledgecenter/SSVJJU/welcome
v IBM Global Security Kit Secure Sockets Layer Introduction and iKeyman User’s Guide
at
http://www.ibm.com/support/knowledgecenter/SSPREK_6.1.1/
com.ibm.itame.doc_6.1.1/ss7cumst.htm?cp=SSPREK_6.1.1%2F0-3-5
Configuring SSL for the database server

Configure the database server to use SSL for secure communications.
About this task
To use SSL for secure communications, select the SSL check box in the Database
Server Configuration Details window from the Database Server Configuration page
of the Appliance Dashboard. For more information, see Managing the database
server configuration.
Configuring SSL for the directory server

Use an LDIF file to configure SSL on the directory server and to specify a secure
port.
Before you begin

Procedure
1. If the directory server is not running, start the server. For example, on UNIX,
type this command:
/opt/IBM/ldap/V6.1/sbin/ibmslapd -I itimldap
Where -I specifies the instance.
2. Create an LDIF file, such as ssl.ldif, with the following data:
dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSslAuth
ibm-slapdSslAuth: serverauth
-
replace: ibm-slapdSecurity
ibm-slapdSecurity: sslonly
-
replace: ibm-slapdSslKeyDatabase
ibm-slapdSslKeyDatabase: /certs/LDAPSERVER_TEST1234.kdb
Note: The empty lines that contain only the - (hyphen) character are required
for LDIF file formatting.
To change the secured port from the default port number 636, add these
additional lines:
replace: ibm-slapdSecurePort
ibm-slapdSecurePort: 637
3. Place the LDIF file in the following directory:
/opt/IBM/ldap/V6.1/bin
4. Run the idsldapmodify command, which modifies the password policy by
adding the LDIF file to the process.
idsldapmodify -D cn=root -w passwd -i ssl.ldif
-D Binds to the LDAP directory, which is cn=root in this example.
-w Uses the passwd value, which is the directory server administrator
password, as the password for authentication.
-i Reads the entry modification information from an LDIF file instead of
from standard input. In this example, the file is named ssl.ldif.
A successful result produces a message similar to the following one:
Operation 0 modifying entry cn=SSL,cn=Configuration
5. Test the directory server to confirm that it is listening on the default secure port
636. Follow these steps:
a. Stop the directory server. Type /opt/IBM/ldap/V6.1/sbin/ibmslapd -k:.
b. Start the directory server. Type /opt/IBM/ldap/V6.1/sbin/ibmslapd -I
itimldap.
Where -I specifies the instance.
c. Determine whether the directory server is listening on port 636. For
example, display statistics for the network interface with the directory
server by typing netstat -an |grep 636.
A return message that indicates the port is listening might be this example:
tcp 0 0 9.42.62.72:636 0.0.0.0:* LISTEN
Configuring SSL on the application server

Set up the application server to enable SSL communication between IBM Security
Identity Manager and the directory server.

Before you begin
About this task

The topic guides you through the configuration of SSL by using the default
cacerts file that is provided by the Java SDK. Take note that this cacerts file is
likely to be overwritten each time the Java SDK is upgraded or a fix pack is
applied. To save your settings, backup the cacerts file before you upgrade the Java
SDK and then restore the file after upgrade is completed. Otherwise, you can store
the certificates in a different keystore file that is not the default cacerts file.
Procedure
1. Log on to the IBM Security Identity Manager virtual appliance console.
Advanced Configuration > Application Server Certificate Management to
display the Application Server SSL Certificate page. The Application Server SSL
Certificate page displays the certificate details.
3. Click Update to open the Upload Keystore window.
4. Click Browse to search and select the certificate that you want to import. The
File field is populated with the certificate name. For example, appserver.jks.
5. Type the password for the certificate in the Keystore Password field.
6. From the Keystore Type list, select a type that specifies the keystore.
v CMSKS
v JCEKS
v JKS
v PKCS11
v PKCS12
7. Click Save Configuration.
Note: The application server SSL certificate configuration takes some time. Do
not refresh or close the page. Wait for the configuration process to complete.
Configuring the IBM Security Identity Manager Server

Configure the IBM Security Identity Manager server to communicate with the
computer and port on which the directory server listens for secure communication.
Before you begin
Procedure
1. On the computer that has the Security Identity Manager Server, edit the
java.naming.provider.url property that specifies the LDAP connection.

Advanced Configuration > Update Property to display the Update Property
page.
4. In the Update Property page, do these steps.
a. In the All properties tab, click Identity server property files.
b. Click New to add the property name as enRoleLDAPConnection.properties
and the property value as java.naming.provider.url. For more information,
see Managing the server properties.
c. From the Server Control widget on the Appliance Dashboard, select
Cluster Manager server and click Stop.
d. From the Server Control widget on the Appliance Dashboard, select
Cluster Manager server and click Start.
Testing SSL communication between servers

Test the SSL communication between IBM Security Identity Manager Server and
IBM Security Directory Server.
Before you begin
Procedure
1. Test that the Security Directory Server is listening. In the $TDS_INSTALL_HOME/
bin directory on the computer where Security Directory Server is installed, type
the following command on one line. For example:
ldapsearch -b dc=com –K /certs/LDAPSERVER_TEST1234.kdb
–p 636 -s base "objectclass=*"
LDAPSERVER_TEST1234.kdb is the name of the key database.

The result has entries for the top-level schema similar to the following entries:
dc=com
objectclass=top
objectclass=domain
dc=com
Manage External Entities > Directory Server Configuration.
4. Click Configure.
5. In the Directory Server configuration details window, specify the expected
variable values. For more information, see Managing the directory server
configuration.
6. Select the SSL check box to manage the secure connection.
7. Click Save Configuration.
8. To confirm that secure communication is configured, log in with your user ID
and password to the IBM Security Identity Manager Server.
A successful login indicates that you configured SSL communication between
the IBM Security Identity Manager Server and the directory server.

9. If your login does not succeed, an error message on the login screen indicates
that the directory server is not available. After you analyze the LDAP
configuration log and the IBM Security Identity Manager Server log, try the
configuration steps again.
Additionally, you might determine whether:
v Statements were correctly added to the ldapConfig.lax file.
v Required spaces were entered in the ldapConfig.lax file.
v The path to the truststore file is valid.
v The truststore file is corrupted.
Configuration of the HTTP server for additional security and

performance
For additional security and better performance, configure an HTTP server, such as
the IBM HTTP Server, on a stand-alone computer that is external to any other IBM
Security Identity Manager component.
By default, SSL is set to off in the IBM HTTP Server. To enable SSL, you must
specify SSL directives (properties) in the httpd.conf server configuration file. A
configuration that provides additional security and performance is similar to
Figure 7 on page 25
WebSphere Application Server Network Deployment

IBM Security Identity Manager cell
IBM Security Identity Manager cluster
} IBM Security Identity Manager

database
IBM HTTP Server Application Server
WebSphere Web
Server plug-in
} IBM Security Identity Manager Server
JDBC driver
}
LDAP
data store
} Deployment Manager
JDBC driver
Figure 6. HTTP server configuration for increased security

Backup Primary node
Appliance Cluster
Web server /
Managed resource Reverse proxy /
Load balancer
Directory server
Database server
Cognos server
server
Figure 7. Configuration of HTTP server for increased security
SSL for the IBM HTTP server and Application server plug-in
The external IBM HTTP Server forwards HTTP requests that are sent to it to the
internal HTTP transport of the Application server web container through the
Application server plug-in.
To secure this communication, you must enable SSL for the IBM HTTP Server and
configure the Application server plug-in to communicate securely with the
Application server web container.
Configuring SSL for the IBM HTTP server

To configure the use of SSL, you must specify SSL directives (properties) in the
httpd.conf file in the IBM HTTP Server. By default, SSL is set to off in the IBM
HTTP Server.
Before you begin
See the configuration information in the "Securing with SSL Communications"

topic in the "Securing IBM HTTP Server" section at http://www.ibm.com/
support/knowledgecenter/SSAW57/mapfiles/product_welcome_wasnd.html.
For enhanced security, do not use RC4 ciphers. Use the strongest cipher suites that
the browser and web server support. To set specific ciphers, see the "Setting
advanced SSL options" section at http://www.ibm.com/support/
knowledgecenter/SSAW57/mapfiles/product_welcome_wasnd.html.

About this task
To enable SSL on the IBM HTTP Server, use the configuration information to
complete these steps:
Procedure
1. Use the IBM HTTP Server iKeyman utility graphical user interface or command
line to create a CMS key database file and self-signed server certificate.
2. Enable SSL directives in the httpd.conf configuration file for the IBM HTTP
Server.
a. Uncomment the LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
configuration directive.
b. Create an SSL virtual host stanza in the httpd.conf file by using the
following examples and directives:
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
<IfModule mod_ibm_ssl.c>
Listen 443
<VirtualHost *:443>
SSLEnable
</VirtualHost>
</IfModule>
SSLDisable
KeyFile "c:/Program Files/IBM HTTP Server/key.kdb"
Note: On Windows platforms:

v The load module name is LoadModule ibm_ssl_module
modules/mod_ibm_ssl.dll.
v Always specify the address with the port on the Listen directive. To add
the Listen directive in httpd.conf by using the default address 0.0.0.0 to
listen on IPv4 port 443, type Listen 0.0.0.0:443.
3. Stop and start the IBM HTTP Server.
4. Test the configuration with a browser in an HTTPS session to the IBM HTTP
Server (https://ihs_host).
Configuring SSL for the plug-in

After you enable the IBM HTTP Server for SSL, configure the WebSphere
Application Server plug-in so that the IBM HTTP Server can communicate securely
with the application servers. You must ensure that SSL was enabled for the
WebSphere Application Server web container by pointing your browser to a URL
such as https://dm_host:9043/ibm/console.
Before you begin
Set up the IBM HTTP server on a stand-alone computer that is external to any
other IBM Security Identity Manager component. For more information, see the
topic "Selecting a web server topology diagram and roadmap" on the following
website:
http://www.ibm.com/support/knowledgecenter/SSAW57_7.0.0/as_ditamaps/
welcome_nd.html

The installation and configuration of the plug-in registers the web server with the
WebSphere Application Server deployment manager, and the IBM HTTP Server
becomes a managed web server. You can manage a managed web server with the
WebSphere Application Server administrative console.
About this task
The application server profile to which you point during the WebSphere
Application Server plug-in installation and configuration is the deployment
manager itself in this topology. It creates a key file called plugin-key.kdb in the
app_server_root/profiles/dm_profile/etc directory. The plugin-key.kdb file
contains the certificates of all federated application servers.
Push the key file to the managed web server so the plug-in can establish secure
application with the application servers. For more information, see the topic
"Configuring the Web server plug-in for Secure Sockets Layer" on the web site:
http://www.ibm.com/support/knowledgecenter/SSAW57_7.0.0/as_ditamaps/
welcome_nd.html
Procedure
1. Create a directory on the web server host for storing the key ring file that is
referenced by the plug-in and associated files. For example, create a
plugin_install_root/etc/keys directory.
2. On the WebSphere Application Server administrative console, click Servers >
Web servers.
3. Select the web server name.
4. Click Plug-in properties.
5. Click Manage keys and certificates to access configuration options for your
keys and certificates. By default, you can change the password that protects the
keystore.
6. Click OK.
7. Click the web server keystores button to copy the keystore and to stash files to
a managed web server.

Chapter 9. Configuration of single sign-on
Single sign-on services provide a seamless experience for a user who accesses a
number of applications in the enterprise.
You can enable single sign-on for the IBM Security Identity Manager
administrative console, the Self-service console, and the Identity Service Center
applications with IBM Security Access Manager.
After you configure single sign-on, a user logs on to IBM Security Access Manager
web security one time. The identity of the user is propagated to IBM Security
Identity Manager, which eliminates the need for another login.
This function requires IBM Security Access Manager to enable single sign-on with
IBM Security Identity Manager.
1. IBM Security Access Manager provides user authentication and coarse-grained
authorization before it allows access to IBM Security Identity Manager.
2. IBM Security Identity Manager then applies fine-grained access control with its
own Access Control Item (ACI).
You can configure IBM Security Access Manager and IBM Security Identity
Manager for single sign-on with either
v WebSEAL
v IBM Security Access Manager plug-in servers
Before you configure single sign-on with WebSEAL, you must install and configure
IBM Security Access Manager and WebSEAL.
Configuration of IBM Security Identity Manager for single sign-on with

Application server Trust Association Interceptor and IBM Security
Access Manager WebSEAL
Trust Association Interceptor and WebSEAL authentication eliminates the need for
a separate password to access IBM Security Identity Manager.
To configure single sign-on with Trust Association Interceptor and WebSEAL,

complete the following steps:
1. Define how IBM Security Access Manager maps its accounts to IBM Security
Identity Manager accounts during authentication.
2. Create a user in IBM Security Access Manager that WebSEAL can use to
connect to the backend server.
3. Create a junction that points to the IBM Security Identity Manager server.
4. Define two IBM Security Access Manager ACLs to control access to IBM
Security Identity Manager. Define one ACL for the IBM Security Identity
Manager Administrator application. Define ACLs for the IBM Security Identity
Manager Self Service application and the Identity Service Center application.
5. Configure the Trust Association Interceptor.
6. Configure IBM Security Identity Manager to use single sign-on.
7. Configure WebSEAL.
29
Account mapping
Single sign-on, account mapping occurs between IBM Security Access Manager and
IBM Security Identity Manager during login authentication.
When a user accesses IBM Security Identity Manager with WebSEAL and single
sign-on, the user must specify a IBM Security Access Manager user account and
password. IBM Security Access Manager checks if the user is authorized to access
IBM Security Identity Manager.
If the authentication and authorization are successful, the IBM Security Access
Manager user account is passed in the iv-user HTTP request header to IBM
Security Identity Manager. IBM Security Identity Manager passes the information
in the HTTP request header to IBM Security Identity Manager for further
processing. IBM Security Identity Manager uses the IBM Security Access Manager
user account to find a matching user account in the IBM Security Identity Manager
directory.
Typically, IBM Security Access Manager and IBM Security Identity Manager user
accounts are identical. If they are identical, the IBM Security Identity Manager user
can log in to IBM Security Identity Manager.
If they are not identical, you can configure IBM Security Identity Manager user
account mapping. There are two configuration options. They are controlled by the
enrole.authentication.idsEqual attribute in the
enRoleAuthentication.properties file.
Do these steps:
page.
3. In the All properties tab of the Update Property page, click Identity server
property files.
4. Select enRoleAuthentication.properties.
5. Follow the steps that are described in Managing the server properties. View the
following information for the configuration options.
enrole.authentication.idsEqual=true
No mapping is attempted. The IBM Security Access Manager user account
passed in the iv-user HTTP request header must be identical to an IBM
Security Identity Manager user account defined in the IBM Security
Identity Manager directory for the user to log in to IBM Security Identity
Manager.
If the policy in your installation is that all IBM Security Identity Manager
user accounts must have matching IBM Security Access Manager user
accounts, specify enrole.authentication.idsEqual=true to avoid the
unnecessary mapping processing and overhead.
enrole.authentication.idsEqual=false
The IBM Security Access Manager user account passed in the iv-user
HTTP request header searched the IBM Security Access Manager directory
for a matching IBM Security Identity Manager user account:
v If an identical IBM Security Identity Manager is found, the user can log
in to IBM Security Identity Manager.

v If an identical IBM Security Identity Manager account is not found, then
IBM Security Identity Manager attempts to locate a matching IBM
Security Identity Manager user account with the following mapping
logic:
The IBM Security Access Manager user account in the iv-user HTTP
request header searches the IBM Security Identity Manager directory for
a IBM Security Access Manager user account.
If an identical IBM Security Access Manager user account is found in the
IBM Security Identity Manager directory, it searches for the IBM Security
Identity Manager Person entity that owns the IBM Security Access
Manager user account. If an owning IBM Security Identity Manager
Person entity cannot be located, the user cannot log in.
If the IBM Security Identity Manager Person entity that owns the
matching IBM Security Access Manager user account is found, then a
search is performed for anIBM Security Identity Manager user account
owned by that entity. If an IBM Security Identity Manager user account
owned by the IBM Security Identity Manager Person is found, then the
user can log in to IBM Security Identity Manager with that IBM Security
Identity Manager user account. Otherwise, the user cannot log in.
Changing the logoff page

IBM Security Identity Manager comes with different files that can be specified as
the logoff page for its Console.
Before you begin
About this task
See the following table about Logout pages.

Table 4. Logoff pages
File name Description
Webseal default This sample file is the most secure. Use it when you want
the following combined behavior when the user clicks the
Logoff button:
v o End the logon session.
v o End the logon session; the pkmslogout function is
started.
Note: The pkmslogout function works only for clients
with an authentication mechanism that does not supply
authentication data with each request. For example,
pkmslogout does not work for clients that use Basic
Authentication, certificates, or IP address information. In
these cases, you must close the browser to log out. The
pkmslogout function provides this information to the user
in a message on the logout page.
Chapter 9. Configuration of single sign-on 31

Table 4. Logoff pages (continued)
File name Description
Single Sign-On default Use this sample file for the following combined behavior
when the user clicks the Logoff button:
v End the current logon session and provide a link to
return to IBM Security Identity Manager.
v Remain logged in to IBM Security Access Manager; the
iv-user HTTP header information is still available. For
example, this action provides for continued use of a
portal page or a return to IBM Security Identity Manager
without a logon prompt.
Procedure
Manage Server Setting > Single Sign-On Configuration.
2. From the Single Sign-On Configuration page, change the log off page. The
Logout page values are described in Table 4 on page 31.
Creating a user in IBM Security Access Manager that

WebSEAL uses to connect to the backend server
You must create a IBM Security Access Manager user that is used to configure the
single sign-on.
Before you begin
IBM Security Access Manager must be installed.
About this task
Use the pdadmin command to create a user in IBM Security Access Manager that
can be used by WebSEAL. For this task, the user name is sso. You can also use the
web interface to create the user.
Perform this task on the server where IBM Security Access Manager is installed.
Procedure
1. Start the utility by typing pdadmin at a command prompt. The pdadmin
command is located in the /PolicyDirectory Installation path/bin directory.
2. Log in to a secure domain as the sec_master administration user to use the
utility.
a. At the command prompt, type login.
b. Type sec_master when prompted for a user ID.
c. Specify the associated password at the Enter Password prompt.
For example:
pdadmin> login
Enter User ID: sec_master
Enter Password: password
pdadmin>

3. To create the sso user, type the following command on one line at the
command prompt.
pdadmin sec_master> user create sso cn=sso,cn=Users,secAuthority=Default
sso sso password
sso Specifies the user name you want to create. In this case, the user is sso.
cn=sso,cn=Users,secAuthority=Default
Specifies the full LDAP distinguished name (DN).
password
Specifies the password for the user.
4. To make the user account valid, type this command
pdadmin sec_master> user modify sso account-valid yes
Defining IBM Security Access Manager Accounts

For users that access IBM Security Identity Manager, you must define IBM Security
Access Manager user accounts in addition to Security Identity Manager user
accounts.
Before you begin
About this task
Use Security Identity Manager to provision the IBM Security Access Manager user
accounts.
This example defines myaccount as an identical user account for both applications.
Use identical user accounts for both the IBM Security Access Manager and IBM
Security Identity Manager. Otherwise, you must configure the user account
mapping.
Procedure
1. On the computer on which IBM Security Access Manager is installed, start the
IBM Security Access Manager utility. Type pdadmin at a command prompt. This
prompt can be on the IBM Security Access Manager Authorization Server or
the IBM Security Access Manager Policy Server. You can also use IBM Security
Identity Manager to provision IBM Security Access Manager user accounts.
2. Take the following steps:
a. Log in to a secure domain as the sec_master administration user to use the
utility.
b. At the command prompt, type login.
c. Type sec_master when prompted for a user ID.
d. Specify the associated password at the Enter Password prompt.
For example:
pdadmin> login
pdadmin>
3. Define the example myaccount user account on IBM Security Access Manager
with the user create command.

user create [-gsouser][-no-password-policy] user_name dn cn sn password [groups]
Where:
-gsouser
Enables global sign-on.
-no-password-policy
Enables the administrator to create the user with an initial password
that is not checked by the existing global password policies.
user_name
Specifies the name of the user.
dn Specifies the registry identifier assigned to the user you want to create.
The format for a distinguished name is like:
cn=Mary Jones,ou=Austin,o=IBM,c=us
cn Specifies the common name assigned to the user you want to create.
For example, Mary.
sn Specifies the family name of the user. For example, Jones.
password
Specifies the new user account password.
groups
Specifies a list of groups to which the new user is assigned.
For example, type:
user create "myaccount" "cn=FirstName LastName,o=ibm,c=us"
"FirstName LastName" "LastName" password
4. To make the user account valid, type user modify "myaccount" account-valid
yes.
Defining IBM Security Access Manager groups

Use the pdadmin utility to define two IBM Security Access Manager groups.
Before you begin

About this task
Create a group for the users who need access to the following IBM® Security
Identity Manager user interfaces:
v Administrative console.
v Self-service user interface.
v Identity Service Center.
Procedure
1. Create a group ITIM-Group for users who need administrative access, by typing
the following command:
group create ITIM-Group cn=ITIM-Group,o=ibm,c=us ITIM-Group
2. Create a group ITIM-Self-Service-Group for users who need self-service access,
by typing the following command:

group create ITIM-Self-Service-Group cn=ITIM-Self-Service-Group,o=ibm,c=us
ITIM-Self-Service-Group
3. Create a group ITIM-ISC-Group for users who need Identity Service Center
access, by typing the following command:
group create ITIM-ISC-Group cn=ITIM-ISC-Group,o=ibm,c=us
ITIM-ISC-Group
Adding IBM Security Access Manager user account to a group

You must add IBM Security Access Manager user accounts to IBM Security Access
Manager groups.
Before you begin
Procedure
1. Add user account myaccount to the group ITIM-Group by typing this command:
group modify ITIM-Group add "myaccount"
2. Add the IBM Security Access Manager user account myaccount to the group
ITIM-Self-Service-Group by typing the following command:
group modify ITIM-Self-Service-Group add "myaccount"
3. Add the IBM Security Access Manager user account myaccount to the group
ITIM-ISC-Group by typing the following command:
group modify ITIM-ISC-Group add "myaccount"
What to do next
Use IBM Security Identity Manager to provision.
Defining a junction that points to IBM Security Identity

Manager Server
Create a WebSEAL junction that points to the IBM Security Identity Manager
Server with the pdadmin utility.
Before you begin
Procedure
1. Start the utility by typing pdadmin at a command line.
2. Log in to a secure domain as the sec_master administration user to use the
utility.
a. At the command line, type the text as login.
b. Type the ID as sec_master when prompted for a user ID.
c. Specify the associated password at the Enter Password prompt.
For example:

pdadmin> login
pdadmin>
3. Locate the name of the WebSEAL server to create the junction. To determine the
name of the WebSEAL server that is defined in IBM Security Access Manager,
issue the server list command. The information that is returned contains the
name in the following format:
webseald-server_hostname
where server_hostname is the WebSEAL server name.
Note: If you install multiple WebSEAL server instances on the same

workstation, the name format is server_ instancename-webseald-server_
hostname. For example:
pdadmin sec_master> server list
amwpm-tam60-server
ivacld-tam60-server
default-webseald-tam60-server
pdadmin sec_master>
4. Issue the server task create command to create the junction. The command
format is as follows.
server task webseal_server_name create options /junction_name
webseal_server_name
Name of the WebSEAL server.
options
The following options are needed:
-b supply
Defines how the WebSEAL server passes the HTTP BA
authentication information to the backend server.
-c iv-creds
Specify a value client_identity_options, such as iv-creds to
instruct WebSEAL to insert the iv-creds HTTP header variable.
-e utf8_uri
Specifies the encoding to use when it generates HTTP headers
for junctions. This encoding applies to headers that are
generated with both the -c junction option and tag-value. The
value utf8_uri specifies that WebSEAL sends the headers in
UTF-8 but that URI also encodes them. This behavior is the
default behavior.
-h hostname
Specify the fully qualified host name of the IBM Security
Identity Manager Server.
-j Supplies junction identification in a cookie to handle
script-generated server-relative URLs. This option is valid for
all junctions except for the type of local.
-s Specifies that the junction supports stateful applications. By
default, junctions are not stateful. This option is valid for all
junctions except for the type of local.
-p port_number
Specify the port number for the IBM Security Identity Manager
Server.

-t tcp Defines the type of junction type.
-x Creates a transparent path junction. This option is valid for all
junctions except for the type of local.
junction_name
Specify a name for the junction point. Each junction point must
have a unique name.
For example, to define a TCP junction, type the following command on one
line:
server task default-webseald-tam60-server create -b supply -t tcp -s -x
-e utf8_uri -c iv_creds -p 9080 -h ITIMServer.ondemandinc.com /itim/ui
5. Create two junctions, one for Identity Service Center and the other for IBM
Security Identity Manager REST.
See the example in Step 4 on page 36.
v The junction name for Identity Service Center REST must be /itim/ui as
shown in the example of Step 4 on page 36.
v The junction name for IBM Security Identity Manager REST must be
/itim/rest.
Defining IBM Security Access Manager ACLs

Use the pdadmin utility to define IBM Security Access Manager access control lists
(ACLs) to these IBM Security Identity Manager interfaces: Administrative console,
the Self-service console, and the Identity Service Center.
Before you begin
Procedure
1. Start the utility by typing pdadmin at a command prompt.
2. Create an ACL requiring authenticated access to associate with the WebSEAL
junction.
Use the acl create acl_name command, where acl_name is the name of the
ACL being created.
For example, for administrative console access, type the following command:
pdadmin> acl create ITIM-ACL
For self-service access, type the following command:

pdadmin> acl create ITIM-Self-Help-ACL
For Identity Service Center access, type the following command:

pdadmin> acl create ITIM-ISC-ACL
Granting access to the IBM Security Access Manager ACLs

Grant IBM Security Access Manager groups access to their corresponding IBM
Security Access Manager access control lists (ACLs).

Before you begin
About this task

For the administrator group (ITIM-Group), self-service group (ITIM-Self-Service-
Group), and Identity Service Center group (ITIM-ISC-Group), complete these steps:
Procedure
1. Add groups to the ACL with the acl modify acl_name set group group_name
permissions command. For example, add the administrator group to its
corresponding ACL:
pdadmin> acl modify ITIM-ACL set group ITIM-Group Trx
where:
acl_name
Specifies the name of the ACL groups you want to add.
group_name
Specifies the name of the group you want to add.
permissions
Specifies one or more of the following permissions:
T Specifies traverse subdirectories.
r Specifies read.
x Specifies execute.
2. To allow unauthenticated users to only Traverse the directory, modify the ACL:
acl modify ITIM-ACL set any-other T
3. To modify the ACL to allow users who are not authenticated to only Traverse
the directory, type this command:
acl modify ITIM-ACL set unauthenticated T
4. To modify the corresponding ACL to allow ITIM-Self-Service-Group the
authority to Traverse directories and to also read and execute, type this
command:
acl modify ITIM-Self-Help-ACL set group ITIM-Self-Service-Group Trx
5. To modifyITIM-Self-Help-ACL to allow unauthenticated users to only Traverse
the directory, type this command:
acl modify ITIM-Self-Help-ACL set any-other T
6. To modify ITIM-Self-Help-ACL to allow users who are not authenticated to
only Traverse the directory, type this command:
acl modify ITIM-Self-Help-ACL set unauthenticated T
7. To modify the corresponding ACL to allow ITIM-ISC-Group the authority to
Traverse directories and to also read and execute, type this command:
acl modify ITIM-ISC-ACL set group ITIM-ISC-Group Trx
8. To modifyITIM-ISC-ACL to allow unauthenticated users to only Traverse the
directory, type this command:
acl modify ITIM-ISC-ACL set any-other T

9. To modify ITIM-ISC-ACL to allow users who are not authenticated to only
Traverse the directory, type this command:
acl modify ITIM-ISC-ACL set unauthenticated T
Associating the WebSEAL junction to the ACLs

Use the pdadmin utility to associate the WebSEAL junction with a URL path prefix
to the corresponding IBM Security Access Manager access control list (ACL).
Before you begin
Procedure
Associate the ACL with the attach junction_name acl_name command. The
command syntax is:
acl attach prefix/webseal_junction/url_path_prefix acl_name
where:
prefix Specifies the IBM Security Access Manager Object Space prefix for your
WebSEAL server.
Type the following command to see the prefix:
pdadmin> object list /WebSEAL
/WebSEAL/tam60-server-default
In this example, the value of the prefix is /WebSEAL/tam60-server-default.

webseal_junction
Specifies the name of the WebSEAL junction that you created previously
with the server task create command. In this example, the WebSEAL
junction name is /itimserver. The fully qualified WebSEAL junction name
is /WebSEAL/tam60-server-default/itimserver.
url_path_prefix
Specifies the name of the URL path prefix for the IBM Security Identity
Manager administrative console (itim/console), or the self-service console
(itim/self), or Identity Service Center (itim/ui).
acl_name
Specifies the name of the corresponding IBM Security Access Manager
ACL (ITIM-ACL or ITIM-Self-Help-ACL).
For example, associate the fully qualified WebSEAL junction name

/WebSEAL/tam60-server-default/itimserver/itim/console to:
v The IBM Security Identity Manager administrator console access to the IBM
Security Access Manager ACL ITIM-ACL.
acl attach /WebSEAL/tam60-server-default/itimserver/itim/console ITIM-ACL
v The IBM Security Identity Manager self-service console access to the IBM
Security Access Manager ACL ITIM-Self-Help-ACL.
acl attach /WebSEAL/tam60-server-default/itimserver/itim/self ITIM-Self-Help-ACL
v The IBM Security Identity Manager Identity Service Center access to the IBM
Security Access Manager ACL ITIM-ISC-ACL.

acl attach /WebSEAL/tam60-server-default/itimserver/itim/ui ITIM-ISC-ACL
Configuring IBM Security Identity Manager to use single

sign-on
Change the ui.properties file to configure IBM Security Identity Manager to use
single sign-on.
Before you begin

Procedure
page.
2. In the All properties tab, click Identity server property files.
3. Select ui.properties.
4. Select the enrole.ui.taiEnabled property name.
5. Click Edit.
6. Set the Property Value to true.
7. From the Server Control widget on the Appliance Dashboard, do these steps.
a. Select these servers and click Stop.
v Cluster Manager server
v Identity Manager server
b. Select these servers and click Start.
v Cluster Manager server
v Identity Manager server
What to do next
Configure WebSEAL.
Configuring WebSEAL
Configure WebSEAL to use the password of the IBM Security Access Manager user
that is created in the first task of this procedure.
Before you begin

This task configures WebSEAL to use form-based authentication. Form-based

authentication ends the IBM Security Access Manager session when the user logs
out. For more information about the topic, see the IBM Security Access Manager
product documentation website at http://www.ibm.com/support/
knowledgecenter/SS9JLE/welcome.

Procedure
1. On the WebSEAL server, locate the webseald-default.conf file. This file is in
the WebSEAL installation directory.
2. Find the entry basicauth-dummy-passwd.
3. Replace dummypasswd with the password you specified for the user that is
created in the first task of the procedure.
4. Configure WebSEAL to use form-base authentication. Ensure that these values
are set in the WebSEAL configuration file.
v ba-auth=none
v forms-auth=https
5. Save your changes.
6. Restart the WebSEAL server.
What to do next
Log on to IBM Security Identity Manager Server with any defined IBM Security
Access Manager user ID.
Note:
1. You are logging in through the WebSEAL junction URI and not directly in to
IBM Security Identity Manager Server.
2. If you use basic authentication, you must close the browser when you log off to
end the current session.
IBM Security Identity Manager web services in a single sign-on

environment
The single sign-on (SSO) application in the IBM Security Identity Manager installed
example directory, achieves single sign-on by using the IBM Security Identity
Manager web services.
The SSO application fetches the Lightweight Third Party Authentication (LTPA)
token from the Hypertext Transfer Protocol (HTTP) header. The LTPA token serves
as an identity token for using and maintaining the authenticated user information.
The token enables the user to access the resources without requiring to log in to
the IBM WebSphere Application Server again. The SSO application inserts this
token into the SOAP header and then makes a web service call.
IBM Security Identity Manager installation configures ISIMSecurityDomain as its

security domain that scopes to the IBM WebSphere Application Server where the
IBM Security Identity Manager is deployed. Any application that runs on the same
WebSphere Application Server uses the ISIMSecurityDomain. Any application that
runs on a separate WebSphere Application Server runs under a separate domain
and the user security realm must be configured as trusted realm in
ISIMSecurityDomain.
The SSO application uses form-based login when it is not accessed from a
WebSEAL junction. IBM Security Identity Manager users can log in to the sample
application by using the same credentials as the IBM Security Identity Manager
account. The SSO application runs on the same WebSphere Application Server and
uses the ISIMSecurityDomain. When deployed in a separate server than IBM
Security Identity Manager, the SSO application must be configured to share the
IBM Security Identity Manager user registry. Upon successful authentication, the

SSO application receives an LTPA cookie in the response header from the
WebSphere Application Server. The sample application extracts the LtpaToken2
cookie from the Hypertext Transfer Protocol (HTTP) header and sets it in the
session. The WebServiceCall servlet starts the getPrincipalPerson web service
API.
When the SSO application is accessed from a WebSEAL junction, the TAI (Trust
Association Interceptor) prevents WebSphere security from requiring multiple
authentications. IBM Security Identity Manager users can log in to the sample
application by using the credentials from the WebSEAL authentication server.
Because the SSO application is deployed with the same ISIMSecurityDomain in the
same WebSphere Application Server, the SSO application can log in to IBM
Security Identity Manager seamlessly with the LTPA token from WebSEAL. When
run on a separate WebSphere Application Server, the SSO application must run
under a separate domain and the user security realm must be configured as a
trusted realm in the ISIMSecurityDomain.
The SSO application demonstrates that you can achieve SSO authentication with
the IBM Security Identity Manager web services in various deployment scenarios
by using the WS-Security header. Modify the SOAP message to add the
WS-Security header BinarySecurityToken. The BinarySecurityToken element has
the LTPA identity token embedded. Provide the WS-Security header with the actor
attribute, http://services.itim.com/60/actor, to enable the IBM Security Identity
Manager web services for processing the security header. Modify the SOAP
message with the outgoing request of the ClientHandler.
Installing on a system where the IBM Security Identity

Manager is installed
You must install the single sign-on application by using the IBM WebSphere
Application Server administrative console.
Before you begin

Familiarize yourself with the SSO application details and installation requirements
before you install it.
You must install the IBM WebSphere Application Server fixes that are specified in
the IBM Security Identity Manager Release Notes. Use the installation instructions
in the Release Notes to install the fixes. Install the SSO application on the IBM
WebSphere Application Server where the IBM Security Identity Manager is
installed.
About this task

When you install the SSO application on the same system where IBM Security
Identity Manager is installed, SSO authentication uses the IBM Security Identity
Manager web services. The WebSphere Application Server returns an LTPA token
when you authenticate with the WebSphere Application Server.
Procedure
1. Build the SSO application to create the itim_ws.war file. For information about
building the application, see “Building the SSO application” on page 47.
2. Install the application by using the IBM WebSphere Application Server
administrative console.

a. Log on to the IBM WebSphere Application Server administrative console.
For example, http://localhost:9060/ibm/console
b. Click Applications > New Applications > New Enterprise Application.
c. In the Path to the new application area, select Local file system.
d. Click Browse to set Full path to the location of the itim_ws.war file.
e. Click Next.
f. In the How do you want to install the application area, select Detailed -
Show all installation options and parameters.
g. Click Next.
h. At the Application Security Warnings window, click Continue.
i. Click the Map context roots for Web modules step and specify the context
root value as /itim_ws.
j. Click Map security roles to users or groups step. Select the ITIM_CLIENT
role
k. Click Map Special Subjects > All Authenticated in Trusted Realms.
l. Click Next repeatedly until the Summary window is displayed.
m. Click Finish.
n. Click Save to save your changes directly to the master configuration.
3. Update the class loader properties
a. Click Applications > Application Types > WebSphere enterprise
applications.
b. Click itim_ws.war.
c. Under Detailed Properties, click Class loading and update detection.
d. Select Classes loaded with local class loader first (parent last) for the Class
loader order and Single class loader for application for the WAR class
loader policy.
e. Click OK.
f. Click Save to save your changes directly to the master configuration.
What to do next
The SSO application works only with its own authentication by using the IBM
Security Identity Manager user registry. You must enable authentication with
WebSEAL.
Enabling authentication with WebSEAL

Enabling authentication with WebSEAL eliminates the need for a separate
password to access IBM Security Identity Manager.
Procedure
1. Follow the instructions in “Configuration of IBM Security Identity Manager for
single sign-on with Application server Trust Association Interceptor and IBM
Security Access Manager WebSEAL” on page 29 Use the following
modifications for web services.
2. Create an ACL that requires authenticated access to associate with the
WebSEAL junction. For example,
pdadmin> acl create SSOAPP-ACL
3. Grant access to the ACL. For example,

pdadmin> acl modify SSOAPP-ACL set group ITIM-Group Trx
acl modify SSOAPP-ACL set any-other T
acl modify SSOAPP-ACL set unauthenticated T
4. Create the junction between WebSEAL and the back-end WebSphere server If
you are installing the SSO application on an IBM Security Identity Manager
cluster, the LTPA token must be enabled at the WebSEAL junction. To enable
the LTPA token at the junction to the SSO application, you must provide the
following information.
v The location of the key file that is used to encrypt the identity information.
v The password to this key file.
Web services configuration requirements are specified in three extra options to
the server task create command that is used to create the junction.
-A Enables the LTPA cookies.
-F keyfile
Specifies the full path name location on the WebSEAL server of the key
file that is used to encrypt the identity information that is contained in
the cookie. The shared key is originally created on the WebSphere
server and copied securely to the WebSEAL server. See the appropriate
WebSphere documentation for specific details about this task.
-Z keyfile-password
Specifies the password that is needed to open the key file. The
password appears as encrypted text in the junction XML file.
Use these options and the other junction options when you create the junction
between WebSEAL and the back-end WebSphere server. For example,
server task default-webseald-tam60-server create -b supply -t tcp -s -j
-e utf8_uri -c iv-creds -A -F "/abc/xyz/key.file" -Z "abcdefg" -p 9080
-h ITIMServer.ondemandinc.com/isimserver
5. Associate the WebSEAL junction to the ACLs. For example,
acl attach /WebSEAL/tam60-server-default/itimserver/itim_ws SSOAPP-ACL
Installing on a separate system than where the IBM Security

Identity Manager is installed
You must install the single sign-on application by using the IBM WebSphere
Application Server administrative console.
Before you begin
Familiarize yourself with the SSO application details and installation requirements
before you install it.
You must install the IBM WebSphere Application Server fixes that are specified in
the IBM Security Identity Manager Release Notes. Use the installation instructions
in the Release Notes to install the fixes. Install the SSO application on the IBM
WebSphere Application Server where the IBM Security Identity Manager is
installed.
About this task
When the SSO application is installed on a separate system, the IBM Security
Access Manager is positioned as a single sign-on front. It returns an LTPA token
from the WebSphere Application Server or the IBM Security Access Manager
depending on if the junction has LTPA enabled.

Procedure
1. Prepare the WebSphere Application Server environment. See “Preparing the
WebSphere Application Server” on page 49
2. Build the SSO application to create the itim_ws.war file. For information about
building the application, see “Building the SSO application” on page 47.
3. Use File Transfer Protocol (FTP) to copy the itim_ws.war file to the location in
the system where the SSO application is going to be deployed.
4. Install the application by using the IBM WebSphere Application Server
administrative console.
b. Click Applications > New Applications > New Enterprise Application.
c. In the Path to the new application area, select Local file system.
d. Click Browse to set Full path to the location of the itim_ws.war file.
e. Click Next.
f. In the How do you want to install the application area, select Detailed -
Show all installation options and parameters.
g. Click Next.
h. At the Application Security Warnings window, click Continue.
i. Click the Map context roots for Web modules step and specify the context
root value as /itim_ws.
j. Click Map security roles to users or groups step. Select the ITIM_CLIENT
role
k. Click Map Special Subjects > All Authenticated in Trusted Realms.
l. Click Next repeatedly until the Summary window is displayed.
m. Click Finish.
n. Click Save to save your changes directly to the master configuration.
5. Update the class loader properties
a. Click Applications > Application Types > WebSphere enterprise
applications.
b. Click itim_ws.war.
c. Under Detailed Properties, click Class loading and update detection.
d. Select Classes loaded with local class loader first (parent last) for the Class
loader order and Single class loader for application for the WAR class
loader policy.
e. Click OK.
f. Click Save to save your changes directly to the master configuration.
6. Ensure that you properly export and import the LTPA keys for correct
encryption and decryption of the identity tokens (LTPA). See the IBM
WebSphere Application Server documentation for setting up SSO by using
LTPA with multiple servers.
7. Make the security realm that the sample SSO application is deployed a trusted
realm of the IBM Security Identity Manager server. Perform the following steps
on the WebSphere Application Server where IBM Security Identity Manager is
installed.

b. Click Security > Security domains > ISIMSecurityDomain > User
Realms:Customized - itimCustomRealm > Trusted authentication realms -
inbound.
c. Click Add External Realm Type in the security realm of the SSO
application. For example,
appCustomRealm
d. In the ISIM_HOME/data directory, modify
theenRoleAuthentication.properties file. Change
enrole.authentication.idmapper to
com.ibm.itim.authentication.mapping.SSOIDMapper.
e. Restart the IBM Security Identity Manager server.
What to do next
The SSO application works only with its own authentication by using the IBM
Security Identity Manager user registry. You must enable authentication with
WebSEAL.
Enabling authentication on a separate system with WebSEAL

Enabling authentication with WebSEAL eliminates the need for a separate
password to access IBM Security Identity Manager.
About this task
Procedure
1. Follow the instructions in “Configuration of IBM Security Identity Manager for
single sign-on with Application server Trust Association Interceptor and IBM
Security Access Manager WebSEAL” on page 29 Use the following
modifications for web services.
2. On the server where the SSO application is installed, configure a Trust
Association Interceptor for the application security domain. For example,
APPSecurityDomain
Follow the steps in Configuring the Trust Association Interceptor.

3. Define a junction that points to the SSO application. For example,
server task default-webseald-tam60-server create -b supply -t tcp
-s -j -e utf8_uri -c iv_creds -p 9080
-h AppServer.ondemandinc.com /appserver
4. Create an ACL that requires authenticated access to associate with the
WebSEAL junction. For example,
pdadmin> acl create SSOAPP-ACL
5. Grant access to the ACL. For example,
pdadmin> acl modify SSOAPP-ACL set group ITIM-Group Trx
acl modify SSOAPP-ACL set any-other T
acl modify SSOAPP-ACL set unauthenticated T
6. Associate the WebSEAL junction to the ACLs. For example,
acl attach /WebSEAL/tam60-server-default/itimserver/itim_ws SSOAPP-ACL
Starting the SSO application

To use single sign-on, you must start the SSO application.

About this task
Perform these steps on the WebSphere Application Server where the SSO
application is installed.
Procedure
1. Log on to the WebSphere Application Server administrative console. For
example,
http://localhost:9060/ibm/console
2. Click Applications > Enterprise Applications.
3. If itim_ws_war is not already started, then select the itim_ws_war check box.
4. Click Start.
Testing the SSO application

After you start the SSO application, you can access the Webservices Call page to
test whether single sign-on is working.
Procedure
1. Use one of the following URLs to access the SSO application with a web
browser.
v Use the URL http://hostname:9080/itim_ws/jsp/Home.jsp
v If you enabled SSL, use the URL https://hostname:9443/itim_ws/jsp/
Home.jsp
v If you configured WebSEAL to authenticate, use the URL https://WebSEAL
Proxy/junction name/itim_ws/jsp/Home.jsp.
The hostname is the name of the host where the SSO application is installed.
2. Display the Webservices Call page.
a. Log in to IBM Security Identity Manager.
b. Specify the server host and port on which the IBM Security Identity
Manager web services are deployed.
WS Host
The host name or IP address of the server on which the IBM
Security Identity Manager is deployed.
WS Port
The server port on which the IBM Security Identity Manager web
services are available. For example, 9080.
3. Click Get Principal User to invoke the web service to fetch information about
the logged in user.
Building the SSO application

You can create the itim_ws.war file by using the build scripts in the /examples
directory.
Before you begin
Before you compile the examples, the WAS_HOME environment variable must be set
to the WebSphere Application Server home directory.

About this task
To build only the SSO application, specify sso_sample as the target when you build
the examples. For example, when you issue the build sso_sample command on
Windows operating systems, or the ./build.sh sso_sample command on UNIX
operating systems, it creates the itim_ws.war file.
You must re-create the itim_ws.war file if you change the source of the SSO
application.
Procedure
1. Log in as a user in the IBM Security Identity Manager.
2. Open a command prompt.
3. Change directories to ITIM_HOME/extensions/RELEASE_VERSION/examples.
4. Compile the source code. Type one of the following commands
v On Windows operating systems
build
v On UNIX operating systems
build.sh
The command compiles the Java classes into the following files.
v ITIM_HOME/extensions/RELEASE_VERSION/lib/examples.jar
v ITIM_HOME/extensions/RELEASE_VERSION/examples/self_care/itim_expi.war
v ITIM_HOME/extensions/RELEASE_VERSION/examples/selfregistration/sr.war
v ITIM_HOME/extensions/RELEASE_VERSION/examples/ws/SSOSample/itim_ws.war
What to do next
Some examples require that the examples.jar file is available on the classpath of
the application server. See “Adding the examples.jar file to the class path”
Adding the examples.jar file to the class path

Some examples require that the example code is run within IBM Security Identity
Manager. To run the code, the ITIM_HOME/extensions/RELEASE_VERSION/lib/
examples.jar must be added to the class path of the application server.
About this task
Procedure
1. Stop the IBM Security Identity Manager application.
2. Add the examples.jar file to the ITIM_LIB WebSphere shared library.
a. Log in to the WebSphere administrative console.
b. Click Environment > Shared Libraries
c. Click ITIM_LIB.
d. Scroll down to the bottom of the list. Add the line $ITIM_HOME/extensions/
RELEASE_VERSION/lib/examples.jar
e. Click OK and then click Save.
3. Start the IBM Security Identity Manager application for the changes to take
effect.

Preparing the WebSphere Application Server
To install the single sign-on application on a separate system than where IBM
Security Identity Manager is installed, you must modify the WebSphere
environment on that system.
About this task
Procedure
1. Make sure that administrative security is enabled for the profile on which the
SSO application is to be installed.
2. Create a folder that is named classes, if it does not exist, in
WAS_HOME/profiles/profile_name folder on which SSO application is
deployed.
Copy the itim_server.jar, itim_common.jar, and jlog.jar files from
ISIM_HOME/lib to the WAS_HOME/profiles/profile_name/classes folder on the
WebSphere Application Server client.
3. Copy the following property files from ISIM_HOME/data to the
WAS_HOME/profiles/profile_name /properties folder on the WebSphere
Application Server client.
v enRole.properties
v enRoleAuthentication.properties
v enRoleLDAPConnection.properties
Specify the IBM Security Identity Manager LDAP server in the url
java.naming.provider.url field. Use the IP address or machine name, such
as java.naming.provider.url=ldap://10.88.36.209:389.
v Properties.properties
v tmsMessages.properties
4. Create a data folder in the WAS_HOME/profiles/profile_name folder on the
WebSphere Application Server client.
5. Copy the ISIM_HOME/data/keystore folder to the WAS_HOME/profiles/
profile_name/data folder on the WebSphere Application Server client.
6. Restart the WebSphere Application Server client/server.
7. Log in to the WebSphere Application Server client. On WebSphere
administrative console, click Global security > Security Domains > Copy
Global Security.
8. Enter the information for IBM Security Identity Manager Security Domain.
9. Click OK and save the changes to the master configuration.
10. Configure the security domain.
a. Go to Security Domain > ISIMSecurityDomain. Specify server1 as the
scope of the domain. Click OK and save the changes to the master
configuration.
b. Go to Security Domain > ISIMSecurityDomain > Security Attributes >
Application Security. Select the option Customize for this domain and
check the checkbox Enable Application Security. Click OK and save the
changes to master configuration.
c. Go to Security Domain > ISIMSecurityDomain > User Realm. Select
Standalone custom registry.
d. Click Configure. Enter the realm name and custom registry class name.
Select Ignore case for authorization.
e. Click OK and save the changes to master configuration.

11. Export and import the LTPA keys for the encryption and decryption of the
identity tokens.
a. Export the LTPA key from the WebSphere Application Server, where IBM
Security Identity Manager is installed.
1) Go to Global Security > LTPA.
2) Specify a password in the Password and Confirm password fields.
3) Specify the path and LTPA key file name in the Fully qualified key
file name field.
4) Click Export keys.
b. Import the LTPA key on the WebSphere Application Server client, where
SSO application is installed.
1) Go to Global Security > LTPA.
2) Specify the password that was used in exporting the LTPA key in the
Password and Confirm password fields.
3) Copy the LTPA key file from the WebSphere Application Server to the
WebSphere Application Server client. Specify the path of the LTPA key
file on the WebSphere Application Server client in the Fully qualified
key file name field.
4) Click Import keys.
5) Save the changes to the master configuration.
Accessing IBM Security Identity Manager consoles

After a junction exists between the WebSEAL server and the host for IBM Security
Identity Manager, the URLs must include the junction name to access the
Administrative console, the Self-service console, and the Identity Service Center.
Before you begin
About this task
Use the following syntax in each console address:
protocol://host_name/junction_name/url_path_prefix
protocol
Specifies the type of protocol that you want to use. Your choices are http or
https.
host_name
Specifies the name of the computer on which the IBM Security Access
Manager WebSEAL server is installed.
junction_name
Specifies the name of the WebSEAL junction.
url_path_prefix
v For the Administrative console, specify itim/console.
For example, type:
http://TAM60-Server/ITIMServer/itim/console

Or type:
https://TAM60-Server/ITIMServer/itim/console
v For the Self-service console, specify itim/self.
For example, type:
http://TAM60-Server/ITIMServer/itim/self
Or type:
https://TAM60-Server/ITIMServer/itim/self
v For the Identity Service Center, specify itim/ui.
For example, type:
http://TAM60-Server/ITIMServer/itim/ui
Or type:
https://TAM60-Server/ITIMServer/itim/ui
Frequently used commands to configure single sign-on

As an aid to configuring IBM Security Access Manager single sign-on for IBM
Security Identity Manager, this section lists the most frequently used pdadmin
commands. See IBM Security Access Manager documentation for the pdadmin
command line.
Type each command in this example on one line.
Defining IBM Security Access Manager user accounts:

pdadmin -a sec_master -p password -m user delete -registry "itim manager"
pdadmin -a sec_master -p password -m user create "itim manager"
"cn=itim manager,o=ibm,c=us" "itim manager" "itim manager" tivoli
pdadmin -a sec_master -p password -m user modify "itim manager"

account-valid yes
pdadmin -a sec_master -p password -m user show "itim manager"
pdadmin -a sec_master -p password -m user delete -registry "myname"

pdadmin -a sec_master -p password -m user create "myname"
"cn=My Name,o=ibm,c=us" "My Name" "Name" tivoli
pdadmin -a sec_master -p password -m user modify "myname"

account-valid yes
pdadmin -a sec_master -p password -m user show "myname"
pdadmin -a sec_master -p password -m user delete -registry "teamleader"

pdadmin -a sec_master -p password -m user create "teamleader"
"cn=Team Leader,o=ibm,c=us" "Team Leader" "Leader" tivoli
pdadmin -a sec_master -p tivoli -m user modify "teamleader" account-valid yes

pdadmin -a sec_master -p tivoli -m user show "teamleader"
pdadmin -a sec_master -p password -m server task default-webseald-tam60-server

delete /itimserver
Defining a WebSEAL TCP or SSL Junction

create -t tcp -s -j -e utf8_uri -c iv_user -p 9080 -h ITIMServer /itimserver

create -t ssl -s -j -e utf8_uri -c iv_user -p 9443 -h ITIMServer /itimserver
pdadmin -a sec_master -p password -m server task

default-webseald-tam60-server show /itimserver

pdadmin -a sec_master -p password -m acl detach
/WebSEAL/tam60-server-default/itimserver/itim/console
Defining IBM Security Access Manager ACLs:

pdadmin -a sec_master -p password -m acl delete ITIM-ACL
pdadmin -a sec_master -p password -m acl create ITIM-ACL
/WebSEAL/tam60-server-default/itimserver/itim/self
pdadmin -a sec_master -p password -m acl delete ITIM-Self-Help-ACL

pdadmin -a sec_master -p password -m acl create ITIM-Self-Help-ACL
/WebSEAL/tam60-server-default/itimserver/itim/ui
pdadmin -a sec_master -p password -m acl delete ITIM-ISC-ACL

pdadmin -a sec_master -p password -m acl create ITIM-ISC-ACL
Defining IBM Security Access Manager groups:

pdadmin -a sec_master -p password -m group delete ITIM-Group -registry
pdadmin -a sec_master -p password -m group create
ITIM-Group cn=ITIM-Group,o=ibm,c=us ITIM-Group
pdadmin -a sec_master -p password -m group modify ITIM-Group

add "itim manager"
pdadmin -a sec_master -p password -m group show ITIM-Group
pdadmin -a sec_master -p password -m group

delete ITIM-Self-Service-Group -registry
pdadmin -a sec_master -p password -m group create ITIM-Self-Service-Group
cn=ITIM-Self-Service-Group,o=ibm,c=us ITIM-Self-Service-Group
pdadmin -a sec_master -p password -m group modify ITIM-Self-Service-Group
add "itim manager"
add "myname"
add "teamleader"
pdadmin -a sec_master -p password -m group show ITIM-Self-Service-Group
pdadmin -a sec_master -p password -m group
delete ITIM-ISC-Group -registry
pdadmin -a sec_master -p password -m group create ITIM-ISC-Group
cn=ITIM-ISC-Group,o=ibm,c=us ITIM-ISC-Group
pdadmin -a sec_master -p password -m group modify ITIM-ISC-Group
add "itim manager"
add "myname"
add "teamleader"
pdadmin -a sec_master -p password -m group show ITIM-ISC-Group
Associate the WebSEAL junction to the ACLs:

pdadmin -a sec_master -p password -m acl modify ITIM-ACL
set group ITIM-Group Trx
set any-other T
set unauthenticated T
pdadmin -a sec_master -p password -m acl show ITIM-ACL
pdadmin -a sec_master -p password -m acl modify ITIM-Self-Help-ACL

set group ITIM-Self-Service-Group Trx

set any-other T

pdadmin -a sec_master -p password -m acl show ITIM-Self-Help-ACL
pdadmin -a sec_master -p password -m acl modify ITIM-ISC-ACL
set group ITIM-ISC-Group Trx

set any-other T
pdadmin -a sec_master -p password -m acl show ITIM-ISC-ACL
pdadmin -a sec_master -p password -m acl attach
/WebSEAL/tam60-server-default/itimserver/itim/console ITIM-ACL

/WebSEAL/tam60-server-default/itimserver/itim/self ITIM-Self-Help-ACL
/WebSEAL/tam60-server-default/itimserver/itim/ui ITIM-ISC-ACL

Chapter 10. Security layer configuration around the data
model and reports
An access to the data model and reports can be restricted to a set of authorization
roles. The users can create the authorization roles and associate them with the
reporting entities. Only entitled users can access the data model or reports.
Authentication and authorization for IBM Cognos reports

IBM Cognos Business Intelligence administrators can set up the folders that store
the reports. They can then secure those folders so that only authorized users can
view, change, or perform other tasks by using the reports in the folder. To set up
access control on the reports, administrators can set up the user authentication and
define the access control for the set of users.
User authentication setup by using LDAP

You can configure IBM Cognos 10.2.1 components to use an LDAP namespace for
authentication when the users are in an LDAP user directory.
Configuring an LDAP Namespace for IBM Directory Server

If you configure a new LDAP namespace for use with the IBM Directory Server,
you must modify the necessary settings and change the values for all properties of
the IBM Directory objects.
Procedure
1. Open IBM Cognos Configuration.
2. In the Explorer window, under Security, right-click Authentication.
3. Click New resource > Namespace.
4. In the Name box, type a name for your authentication namespace.
5. In the Type list, click LDAP-General default values.
6. Click OK. The new authentication namespace resource appears in the Explorer
window, under the Authentication component.
7. In the Properties window, for the Namespace ID property, specify a unique
identifier for the namespace.
Tip: Do not use colons (:) in the Namespace ID property.

For Host and Port, specify <Hostname>:<port>. For example, localhost:389.
8. Specify the values for all other properties to ensure that IBM Cognos 10.2.1
can locate and use your existing authentication namespace.
v For Base Distinguished Name, specify the entry for a user search.
v For User lookup, specify (uid=${userID}).
v For Bind user DN and password, specify cn=root. For example, cn=root as
a user name and secret as a password.
Note: Specify the values if you want an LDAP authentication provider to

bind to the directory server by using a specific bind user DN and password.
If no values are specified, an LDAP authentication namespace binds as
anonymous.
55
9. If you do not use external identity mapping, use bind credentials to search an
LDAP directory server. Complete the following items.
v Set Use external identity to False.
v Set Use bind credentials for search to True.
v Specify the user ID and password for Bind user DN and password.
10. To configure an LDAP advanced mapping properties, see the values that are
specified in the following table.
Table 5. LDAP advanced mapping values
Mappings LDAP property LDAP value
Folder Object class organizationalunit, organization, and container
Description description
Name ou, o, and cn
Group Object class groupofnames
Member member
Name cn
Account Object class inetorgperson
Business phone telephonenumber
Content locale (leave blank)
Email mail
Fax/Phone facsimiletelephonenumber
Given name givenname
Home phone homephone
Mobile phone mobile
Name cn
Pager phone pager
Password userPassword
Postal address postaladdress
Product locale (leave blank)
Surname sn
Username uid
If the schema is modified, you must make extra mapping changes.

11. To prevent the anonymous access, complete the following steps:
a. Go to Security > Authentication > Cognos.
b. Set Allow anonymous access? to False.
12. From the File menu, click Save.
Results
A new LDAP namespace is configured with the appropriate values.
What to do next
Create the users in an LDAP. See “Creating users in an LDAP” on page 57.

Creating users in an LDAP
See the example in this procedure that uses an LDAP utility to create users in
LDAP.
Procedure
1. Open an LDAP utility. For example, if you are using the IBM Directory Server,
the LDAP utility is idsldapadd.
2. Import the sample file LdapEntries.ldif that lists all the users who are
authorized to access the reports. See the following example.
Results
After the successful import operation, you can see the users that are created in
ou=users,ou=SWG.
Example
A sample file: LdapEntries.ldif
In this example, dc=com is the root entry. Specify the entry according to the schema
that you use.
dn: ou=SWG, dc=com
ou: SWG
objectClass: top
objectClass: organizationalUnit
dn: ou=users,ou=SWG, dc=com

ou: users
objectClass: top
objectClass: organizationalUnit
dn: uid=steves,ou=users,ou=SWG, dc=com

uid: steves
userPassword:: hello123
objectClass: inetOrgPerson
objectClass: top
objectClass: person
objectClass: organizationalPerson
sn: Wiley
cn: Steves
dn: uid=PortalAdmin,ou=users,ou=SWG, dc=com

uid: PortalAdmin
objectClass: top
objectClass: person
sn: Poon
cn: Chuck
dn: uid=william,ou=users,ou=SWG, dc=com

uid: william
objectClass: top
objectClass: person
sn: Hanes
cn: William
Chapter 10. Security layer configuration around the data model and reports 57
dn: uid=lucy,ou=users,ou=SWG, dc=com
uid: lucy
objectClass: top
objectClass: person
sn: Haye
cn: Lucy
What to do next
Authenticate IBM Cognos® by using an LDAP user. Complete these steps:

1. Access the IBM Cognos Gateway URI. For example, http://
localhost:portnumber/ibmcognos/cgi-bin/cognos.cgi. The localhost is the IP
address or network host name where IBM Cognos gateway is configured. The
portnumber is the port on which the IBM Cognos gateway is configured.
2. Select the configured Namespace, and click OK.
3. Enter your LDAP user ID and password.
4. Click OK.
Access control definition for the reports and reporting packages

You can define the access control for the LDAP users who are the members of a
role that is defined in the IBM Cognos namespace. Access can be granted to those
users who are the members of a defined role.
A user who has the system administrator privileges can grant the access.
Initially, all users are the members of the system administrator. Therefore, you can
log in with your LDAP user authentication in IBM Cognos and access the
administration section before you restrict the administration access.
Restricting administration access and adding an LDAP user to

system administrator role
You can restrict the IBM Cognos administration access by using the system
administrators role in IBM Cognos namespace. You can also add an LDAP user to
the system administrator role for IBM Cognos report administration.
Procedure
1. Log in to IBM Cognos with an LDAP user whom you want to assign the
system administrator role.
2. Go to Launch, and click IBM Cognos Administration.
3. Click the Security tab.
4. In the Users, Groups, and Roles section, click Cognos.
5. Navigate to System Administrator role.
6. Click the More link.
7. Under Available actions, click Set properties.
8. Click the Members tab.
9. Click the Add link.
10. Under Available entries section, click an LDAP namespace.
11. Select the Show users in the list check box.

12. Select the user whom you want to assign the system administrator role and
make it into selected entries list.
13. Click OK.
14. Select Everyone from the members entry.
15. Click the Remove link to ensure that only the added users can have the
system administration access.
16. Click OK.
17. Click the Permissions tab.
18. Verify that the system administrators are listed and they are provided all the
permissions. If no permissions are provided, then select the system
administrators and grant all the permissions. Complete this step:
a. Select the Override the access permissions acquired from the parent
entry check box to grant the permissions.
19. Click OK.
Results
An LDAP user is added with the system administrator role.
What to do next
Create a role and add LDAP users as the members to that role. See “Creating a
role and adding LDAP users as members.”
Creating a role and adding LDAP users as members

The topic describes the procedure to create a role in IBM Cognos and add the
members from an LDAP namespace to it.
Procedure
1. Log in to IBM Cognos with an LDAP user who has the system administrator
privileges. For example, PortalAdmin.
2. Go to Launch, and click IBM Cognos Administration.
3. Click the Security tab.
4. In the Users, Groups, and Roles section, click Cognos.
5. Click the New Role icon from the palette.
6. Specify the name for a role. For example, ISIMAuditor.
7. Add the description and the screen tip.
8. Click Next.
9. Under Select the members, click Add.
10. Under Available Entries Directory, click an LDAP namespace.
11. Select the Show users in the list check box.
12. Select the users whom you want to add as the members to the role and make
it into selected entries list.
13. Click OK.
14. Click Finish.
Results
A new role is created and LDAP users are added as the members to the new role.
Defining an access to the report by using a role
You can define an access to the report by using a role. All the members of a role
can access the report or reports.
Procedure
2. Under Public Folders, click SAReportingmodel_6.0.
3. Click the More link on the Actions toolbar that is associated with the report
for which you want to provide the access.
6. Select the Override the access permissions acquired from the parent entry
check box.
7. Click Add link at the bottom of the list of entries.
8. Click Cognos.
9. Select the role that you want to add and make it to the selected entries.
10. Click OK.
11. Select the role and grant the permissions.
12. Optional: Remove other roles for which you do not want to provide the
access.
13. Click OK.
Results
An access is defined to the report by using a role and all the members of a role can
access the reports.
Defining an access to the reporting package by using a role

You can define an access to the report package by using a role. All the members of
a role can access the report package.
Procedure
2. Under Public Folders, click the More link on the Actions toolbar that is
associated with the report package SAReportingmodel_6.0.
5. Select the Override the access permissions acquired from the parent entry
check box.
6. Click the Add link at the bottom of the list of entries.
7. Click Cognos.
8. Select the role that you want to add and make it to the selected entries.
9. Click OK.
10. Select the role and grant the permissions.
11. Optional: Remove other roles for which you do not want to provide the
access.
12. Click OK.

Results
An access is defined for the reporting package by using a role and the members of
a role can access the reporting package.
References for IBM Cognos report security configuration

Use the following references that provide information about the topics that are
related to the security configuration for the IBM Cognos reports.
Access the IBM Cognos Business Intelligence 10.2.1 documentation at

http://pic.dhe.ibm.com/infocenter/cbi/v10r2m1/index.jsp and search for the
following terms.
v Security model.
v Authentication providers.
v Add or remove members of a cognos group or role.
v Create a cognos group or role.
v Authorization.
v Access permissions and credentials.
Index
A G separate systems
single sign-on 49
access group setup, user authentication 55
IBM Security Identity Manager define 34 single sign-on 40
consoles 50 enabling authentication with
access control WebSEAL
reports 58
access reports, defining 60
H same system 43
HTTP server 24 separate system 46
account installing
define 33 same system 42
mapping 30
ACL 39 I separate system 44
starting 47
access 38 IBM HTTP server 25 testing 47
define 37 IBM Security Identity Manager server web services 41
adapter 13 configure 22 WebSphere Application Server
administrator iKeyman utility 18 preparation 49
access restriction 58 SSL 9, 25, 26
Application server 25 configure 20
Application server security 1
authentication
L SSL authentication, one-way,
LDAP two-way 8
IBM Cognos reports 55 SSL communication 7
creating users 57
authorization SSL configuration
LDAP namespace
IBM Cognos reports 55 example 17
configuration 55
logoff page preparation 18
Security Identity Manager Console SSL implementation 9
B changing 31 SSL terminology 7
backend server 32 SSL client 7
SSL communication 22
M test 23
C members, adding 59
SSL server 7
certificate 11 middleware 17
class path
adding the examples.jar file 48 T
clustered environment 9
command
P Trust Association Interceptor 29
pdadmin 35
example 51
pdadmin utility 37
single sign-on 51
protocol 50 U
communication 13, 15 ui.properties 40
configuration 17 user
configure 29
database server 20 R create 32
user account
single sign-on 29 references add 35
SSL 20 security configuration 61 user authentication
custom application 15 report package setup 55
defining access 60 user registry
reports Application server 3
D access control 58
define access 60
directory server 20
roles
creating 59 W
web services
E enabling authentication with
examples.jar file 48
external user registry 3
S WebSEAL
same system 43
secure environment separate system 46
practices 5 in a single sign-on environment 41
security 24
F security configuration references 61
installing single sign-on
same system 42
file types 11 security layer configuration 55 separate system 44
form-based authentication 40 self-signed certificate 18 single sign-on for separate
systems 49
63
web services (continued)
starting single sign-on 47
testing single sign-on 47
WebSEAL 29, 32, 40
WebSEAL junction 35
associate 39
WebSphere Application Server
plug-in 26

IBM®
Printed in USA

Isim Security PDF 70

Uploaded by

Copyright:

Available Formats

Isim Security PDF 70

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Isim Security PDF 70

Uploaded by

Copyright:

Available Formats

IBM Security Identity Manager

IBM Security Identity Manager uses Application server security to enforce

© IBM Corp. 2007, 2013 1

See Configuring the Identity external user registry

External user registry example deployment

Do these steps to access the documents:

© IBM Corp. 2007, 2013 3

6 IBM Security Identity Manager Version 7.0.1.7: Security Topics

One-way and two-way SSL authentication

One-way authentication creates a truststore on the client and a keystore on the

IBM Security Identity Manager Security Directory Integrator

CA certificate “A” CA certificate “A”

Figure 1. One-way SSL communication

8 IBM Security Identity Manager Version 7.0.1.7: Security Topics

CA certificate “A” CA certificate “B”

Certificate “B” Certificate “A”

Figure 2. Two-way SSL communication

SSL in a clustered environment

Chapter 4. Secure sockets layer communication 9

10 IBM Security Identity Manager Version 7.0.1.7: Security Topics

A privacy-enhanced mail format supports multiple digital certificates,

Figure 3 illustrates how you can configure secure communication links.

SSH = Secure Shell protocol

These guidelines ensure that:

WebSphere Application Server

IBM Security Identity

Figure 4. Security layers in IBM Security Identity Manager Server

WebSphere Application Server uses roles to manage access to application

16 IBM Security Identity Manager Version 7.0.1.7: Security Topics

Your configuration might be similar to the cluster configuration example in

Backup Primary node

Figure 5. Initial cluster configuration

Example SSL configurations

Preparation for SSL configuration

Complete these tasks:

Before you begin

18 IBM Security Identity Manager Version 7.0.1.7: Security Topics

The iKeyman utility is in the IBM Security Directory Server.

Chapter 8. Secure communication with supported middleware 19

Alternatively, you can use the WebSphere Application Server administrative

Configuring SSL for the database server

About this task

Configuring SSL for the directory server

Before you begin

20 IBM Security Identity Manager Version 7.0.1.7: Security Topics

Configuring SSL on the application server

Chapter 8. Secure communication with supported middleware 21

About this task

Configuring the IBM Security Identity Manager Server

Before you begin

22 IBM Security Identity Manager Version 7.0.1.7: Security Topics

Testing SSL communication between servers

Before you begin

LDAPSERVER_TEST1234.kdb is the name of the key database.

Chapter 8. Secure communication with supported middleware 23

Configuration of the HTTP server for additional security and

WebSphere Application Server Network Deployment

IBM Security Identity Manager cluster

} IBM Security Identity Manager

Figure 6. HTTP server configuration for increased security