IBM Security Access Manager for Enterprise Single Sign-On, Version 8.2.1

Deployment considerations

There are several factors that affect the successful deployment of IBM® Security Access Manager for Enterprise Single Sign-On. This topic provides a list of what you need to consider when deployingIBM Security Access Manager for Enterprise Single Sign-On.

Installation package

IBM Security Access Manager for Enterprise Single Sign-On is available in Standard and Suite packages. The IBM Security Access Manager for Enterprise Single Sign-On features that the organization can use might vary depending on the package to be deployed.

Consideration:
  • Before you proceed with the installation, determine whether to deploy a standard or suite package.

See Distribution and packaging for information about the Standard and Suite packages.

Installation method

IBM Security Access Manager for Enterprise Single Sign-On is deployed by components. There are options on how to deploy each component. The IMS Server can be installed with an interactive graphical mode. AccessAgent and AccessStudio can be installed with interactive graphical mode or silent mode.

Considerations:
  • Determine which installation mode is applicable for the organization.

See Installation options for a comparison of the different installation options for the different product components:

High availability and disaster recovery

There are different ways to ensure IBM Security Access Manager for Enterprise Single Sign-On high availability and disaster recovery, from caching Wallets to using load balancers and clusters.

Considerations:
  • Determine the high availability requirements.
  • Collect information necessary to estimate hardware sizing for high availability:
    • Peak hour traffic estimates
    • Peak installation and user sign-up rates
    • Database utilization
    • Clustering requirements
    • Load balancing architecture requirements
  • Determine the preferred method to achieve high availability. Choices are:
    • Using load balancers and clusters
    • Distributing the IMS Server
  • Determine failover and recovery criteria.
  • Determine backup and restore strategy.
  • Set up DR environment in a separate site or location.

See Planning for high availability and disaster recovery for the options to achieve high availability.

Performance tuning

You can configure IMS Server and AccessAgent to achieve better performance.

Considerations:

  • Identify the potential performance problems and establish numeric values that categorize acceptable behavior.
  • Identify the most active time when users tend to log on to AccessAgent.
  • Estimate the number of users involved.
  • Identify the synchronization interval.

Application server tier

IMS Server runs on a WebSphere® Application Server.

Considerations:
  • Determine whether to do a stand-alone or network deployment.
  • For network deployment, determine the number of nodes and clusters.

    You need at least two WebSphere Application Server nodes to achieve high availability. Add more nodes into the cluster to achieve scalability.

Web server tier

The web tier typically serves as the front end of the deployment. The web server manages incoming requests from the client computers or from a load balancer and distributes the requests to the application server.

Considerations:
  • Determine the number of web servers to deploy.

    You need at least two web servers to achieve high availability. If you have more than one web server, you must use a load balancer.

  • Determine whether to install the web server on the same computer where the application server is installed.

Directory server

IMS Server can be configured to use an existing or new directory server to identify and validate a user during sign-up.

Considerations:
  • Determine whether to use an Active Directory or a generic LDAP. The combination of Active Directory and LDAP as directory servers is not supported.
  • If Active Directory is used, determine whether:
    • To enable or disable Active Directory password synchronization. This feature is not available when using a generic LDAP.
    • To use multiple Active Directory domains. If you are using a generic LDAP, you cannot configure multiple LDAP domains.

    If LDAP is used or if Active Directory password synchronization is disabled, the Tivoli® Identity Manager Active Directory Adapter is not required.

  • Determine whether to provide self-service password reset through AccessAssistant.
  • If Active Directory password synchronization and password reset through AccessAssistant are enabled, determine whether to use SSL connection. If there is no SSL connection, a Tivoli Identity Manager Active Directory Adapter is required.
  • Distinguished names must be unique for a collection of users or groups over all directory servers. For example: If uid=imsadmin,o=ibm exists in LDAP1, it must not exist in LDAP2, and in LDAP3.
  • Ensure that the LDAP short name is unique for a realm across registries. For example: imsadmin.
  • Ensure that the base distinguished names for all registries that are used within a realm must not overlap. For example: If the LDAP1 value is c=us,o=ibm, LDAP2 must not be o=ibm.

See Configuring IMS Server to use the directory server for more information about directory servers.

See the IBM Security Access Manager for Enterprise Single Sign-On Configuration Guide for configuring the directory server.

Database server

A database server is required to store AccessProfiles, user credentials, policies, and audit logs.

Considerations:
  • Verify whether the database server and its version are supported. See Hardware and software requirements. Database configuration settings vary depending on the selected database.
  • Determine whether to install the database server on the same computer where the IMS Server is installed.
  • Determine whether to implement database clustering and replication.
  • Verify the network connection between the IMS Server and database server if they are in different workstations or servers.
  • Determine the path of the database.
  • Synchronize the system clocks if the IMS Server database and IMS Server are running on different computers.

See "Preparing the database server" in the IBM Security Access Manager for Enterprise Single Sign-On Installation Guide for the specific requirements for each supported database.

Session management

IBM Security Access Manager for Enterprise Single Sign-On can be deployed on personal workstations or shared workstations; in private desktops or user desktops; on Microsoft Remote desktops or on Citrix XenApp Servers. Furthermore, AccessAgent can run in lightweight mode on Microsoft Remote desktops or on Citrix XenApp Servers.

Considerations:
  • Identify and understand the session management requirements
  • Determine whether to deploy AccessAgent on personal or shared workstations.
  • Determine whether to implement a shared desktop or a private desktop for the users.
  • Determine whether to implement strong authentication and identify the authentication factor.
  • Identify the corporate security policies
  • Determine whether the organization wants to deploy IBM Security Access Manager for Enterprise Single Sign-On on Microsoft Remote desktops or on Citrix XenApp Servers.
  • Determine whether to set Server AccessAgent on standard mode or lightweight mode.
  • Determine whether the organization is using thin clients.
  • Determine the required configuration such as whether to enable or disable Active Directory password synchronization, Network Provider, and others.

See Session management for the different desktop modes, and for the implementation overview.

See the IBM Security Access Manager for Enterprise Single Sign-On AccessAgent on Terminal Server and Citrix Server Guide for deploying IBM Security Access Manager for Enterprise Single Sign-On on Microsoft Remote desktops or on Citrix XenApp Servers.

See the IBM Security Access Manager for Enterprise Single Sign-On Configuration Guide for configuring the Citrix or Terminal Server and lightweight mode.

See the IBM Security Access Manager for Enterprise Single Sign-On Policies Definition Guide for the related policies.

Audit logs and reports

IBM Security Access Manager for Enterprise Single Sign-On provides audit logs, report models, and static reports. You can use IBM Cognos® reporting framework or Tivoli Common Reporting to generate the packaged reports.

Considerations:
  • Identify the auditing requirements.
  • Define the custom audit logs to be generated.
  • Configure the audit log events.
  • Define the specific duration for which the audit logs are required.

See the IBM Security Access Manager for Enterprise Single Sign-On Administrator Guide for the different logs and reports that can be queried or generated.

Application profiles

Single sign-on to applications within the organization is a core function of IBM Security Access Manager for Enterprise Single Sign-On. This core capability depends on successfully profiling the applications with AccessStudio.

Considerations:
  • Identify the applications to be profiled including exact part numbers, version numbers, and patch levels.
  • Determine whether the bundled profiles meet the application requirements.
  • Determine the priority of the applications. Know the numbers of users for each application, and the business impact.
  • Understand the behavior of the applications. Know the application logon and logoff process.
  • Identify the error scenarios of the application.
  • Determine and categorize the different types of applications are Web, Windows, mainframe, Java™, or others.
  • Determine the password policies for each application.
  • Determine which application password change workflow is required.
  • Determine whether any applications share credentials.
  • Determine the application credential fields. An application typically has username and password fields but some applications might have additional fields as part of a credential.
  • Identify challenging applications.
  • Identify applications with complex workflows or uses non-standard user interface libraries.
  • Determine whether the applications support different locales. Identify which locales are used by the users.
  • Determine whether to create standard or advanced AccessProfiles.

Authentication

You can deploy IBM Security Access Manager for Enterprise Single Sign-On with strong authentication, and self-service password reset. You can also enable Active Directory password synchronization, ESSO GINA, and ESSO Credential Provider.

Considerations:

  • Identify the authentication requirements.
  • Identify the policy for new, change, and reset passwords.
  • Determine whether to implement strong authentication and identify the authentication factor.
  • Determine whether to enable the ESSO GINA.
  • Identify the existing authentication factors.
  • Determine whether IBM Security Access Manager for Enterprise Single Sign-On supports the existing authentication factors and their respective middleware.
  • Ensure that the authentication devices and middleware are already installed, tested, and functioning before you deploy the product.
  • Identify the password requirements.
  • Determine whether to enable self-service.
  • Be careful when formulating the series of question users must answer to reset their passwords. Issues of privacy and cultural sensitivity must be considered.
  • Review the security questions with the Legal department to ensure that the questions are in compliance with local privacy laws.

See Planning for authentication factors for information about the primary and strong authentication factors.

Provisioning

You can provision users through a provisioning system.

Considerations:
  • Determine whether to use a provisioning system such as Tivoli Identity Manager.
  • Determine whether users can sign up for authentication and sign-on services through AccessAgent or AccessAssistant.
  • Determine whether to provision users before the AccessAgent push-out installation.

See Provisioning users.

Security

Secure the IBM Security Access Manager for Enterprise Single Sign-On deployment and related components to mitigate against potential security risks.

Considerations:
  • Identify the security policy of the organization.
  • Determine the security hardening requirements.
  • Identify the options for securing the Application tier.
  • Identify the options for securing the Web-tier.
  • Identify a secure location for the hardware or systems running the software.

See Planning for security.

Parent topic: Planning for deployment

Feedback