One of the first important steps of a Tivoli Access Manager for Enterprise Single Sign-On deployment is to define the project's scope, which involves collecting details about the current environment, gathering the requirements, and finally creating the solution document.
In this section, we describe processes required for designing an enterprise single sign-on foundation based on Tivoli Access Manager for Enterprise Single Sign-On. We discuss an organization’s overall structure, the business objectives, the business requirements, and functional requirements.
2.2.1 Basic solution definition
The solution enables an enterprise to extend capability to allow employees to use single sign-on from private, shared, and roaming desktops as well as personal desktops for applications using the basic profiling wizard. It also includes basic password reset and self-service functionality.
Several variations of the solution exist, as follows:
Basic single sign-on solution
The basic solution includes an AccessAgent that is deployed to each user workstation and a single IMS Server to centrally manage users, policies, and configuration parameters through AccessAdmin, the administrative interface.
In this solution, the user is able to rely on Tivoli Access Manager for Enterprise Single Sign-On to log them into Windows applications, Web applications, and other applications configured into Tivoli Access Manager for Enterprise Single Sign-On. You should also expect to configure user,
machine, and authentication policies.
Basic single sign-on solution with session management
Mobile employees can enjoy the benefits of single sign-on by accessing their applications from Windows Terminal Services clients or Citrix MetaFrame clients. You should expect to configure Terminal Services or Citrix
MetaFrame prior to deploying the AccessAgent, as well as configure the Terminal Services or Citrix MetaFrame policy settings in AccessAdmin.
Single sign-on solution with user life cycle management
Tivoli Access Manager for Enterprise Single Sign-On user credentials can be provisioned and de-provisioned automatically when, for example, a new user’s Active Directory ID has to be created or deleted when they leave the company. This approach requires configuration of a Provisioning Bridge and de-provisioning parameters in combination with an identity management solution such as IBM Tivoli Identity Manager.
Single sign-on with two-actor authentication
Configure a strong second authentication factor for one or more users and machines.
These variations of the solution can be intermixed throughout an enterprise to match the requirements of various corporate entities.
2.2.2 Design approach
In this section, we consider how the security design objectives can be realized using Tivoli Access Manager for Enterprise Single Sign-On. Our goal is to produce a plan that includes a set of smaller implementation steps where the end-result satisfies the functional requirements and, therefore, also satisfies the original business requirements.
Although business and functional requirements are the main parts of the security design objectives, we also have to consider other non-functional requirements and constraints. These can include objectives that are necessary to meet
general business requirements, or practical constraints on constructing security sub-systems. Tivoli Access Manager for Enterprise Single Sign-On
implementations often involve non-functional requirements relating to:
Backup and recovery
Performance and capacity
Change management
The steps involved in producing an implementation plan are:
1. Prioritize the requirements.
2. Map the requirements to Tivoli Access Manager for Enterprise Single Sign-On features.
3. Define the tasks that are involved in using those features to satisfy the requirements, and estimate the effort that is required for each task.
After mapping the requirements to Tivoli Access Manager for Enterprise Single Sign-On features and creating a list of implementation tasks, certain tasks might require a longer implementation time.
2.2.3 Project phases and deployment stages
Based on the priorities of the customer’s business requirements and the levels of effort of the different implementation tasks, split the project into appropriate logical phases to be executed sequentially. Each phase should be deployed in stages.
Most companies use a staged approach to deploying new solutions into their IT infrastructure. We describe four stages here, although some companies might have more and might use different terminology for the stage names. The deployment stages are:
1. Development
During development, the deployment procedures for the current stage are created. This stage involves installing and configuring the product based on the goals of the phase.
2. Test
During the test stage, the test group receives the software and procedures from the development group and executes the documented deployment procedures. The test group reports any issues that it encounters to the development group, who updates the procedures. This cycle continues until the test team is satisfied with the reliability of the deployment procedures.
3. Pilot
The pilot stage involves deploying the solution to a relatively small number of users to address any issues in the configuration and deployment procedures.
The software is deployed into a production environment and, thus, is typically performed by a group other than the test group. Solutions involving software distribution to clients can be particularly costly to redeploy to a large number of seats. The pilot stage is important in those types of solutions. This stage can discover issues that are not discovered during the test stage.
4. Production
Production deployment takes place when the pilot phase has proven the viability of the solution. The same procedures used in the pilot phase are used in the production deployment. However, production deployment includes the entire scope of users of the solution.