test

Sun Java System Access Manager 7.1 Deployment Planning Guide

Chapter 2 Business Analysis for Access Manager

Sun JavaTM System Access Manager allows an organization to deploy an identity management solution for employees, contractors, customers, and suppliers. During the business analysis phase of the solution life cycle, you define business goals by analyzing a business problem and identifying the business requirements and business constraints to meet that goal. This chapter contains the following sections:

About Business Analysis

Business analysis starts with stating the business goals. You then analyze the business problems you must solve and identify the business requirements that must be met to achieve the business goals. Consider also any business constraints that limit your ability to achieve the goals. The analysis of business requirements and constraints results in a set of business requirements documents.

You use the resulting set of business requirements documents as a basis for deriving technical requirements in the technical requirements phase. Throughout the solution life cycle, you measure the success of your deployment planning and ultimately the success of your solution according to the analysis performed in the business analysis phase.

Defining Access Manager Business Requirements

This section provides specific business requirements to consider for Access Manager (that is, which business requirements imply a need for an Access Manager solution).

Sun Java System Access Manager is a complex, distributed identity management system that, when properly deployed, secures access to a wide variety of data and services spanning an enterprise’s organizations. To ensure proper control over corporate resources, appropriate planning of the deployment process is required. This chapter offers information about how to plan the deployment, including:

Defining Resources

Because an identity management solution involves a broad variety of systems throughout an organization, proper Access Manager deployment requires a variety of resources. The following corporate resources will be involved or required in the deployment process.

Human Resources

You should consider the various business and political relationships within an organization. A team of individuals should be assembled with a direct or matrixed reporting structure. Typically, Access Manager deployments have small teams that might consist of a project manager and several dedicated System Administrators. These people report to the Team Lead and further up to an owner who has responsibility across a number of related projects and often reports directly to an executive sponsor. This group is often augmented by virtual team members consisting of Sun technical resources, and LOB Application Administrators, which are used as required.

While this structure might not meet your exact needs, it does represent a fairly typical deployment team model. Although not necessarily distinct individuals, the following abstract technical roles representing various skill sets further define a typical Access Manager deployment team.

Executive Sponsors

Successful identity management deployments traditionally cross organizational and political boundaries, which requires buy-in and support from those setting direction for the company. It is critical that executive sponsorship be in place. Planning meetings are an important process for gaining insight from those with a vested interest in the deployment. As the project plan is developed, ensure that its deliverables are inline with the goals of the company as a whole. For example, if cost reduction is a core business driver, collect statistics on current identity management costs and then determine costs such as using the help desk for password resets? Having tangible statistics available can help define a specific return on investment (ROI) as the deployment team attempts to gain executive support. Other company issues that might be relevant include:

Often the identity management concepts and the value of an Access Manager deployment must be related to other executives. A business and technology evangelist can sell the new infrastructure to executives, helping to drive the demand for integration and aid in the acceptance and ultimate success of the infrastructure changes.

Team Lead

A team lead should be chosen as the party responsible for the project’s success. The team lead must be in charge and have the authority to make the project’s goals happen. The team lead might be a logically distributed role, perhaps between a technical lead, a project manager, and an executive. However you define this role, the goal is to show continued progress and demonstrated success throughout the deployment process to maintain executive sponsorship.

Project Management

A project manager is responsible for the coordination of schedules. The project manager maintains a schedule that correlates the availability of services, support provided by the core IT group and the integration of the various line-of-business (LOB) applications. This person must have strong communication skills and understand the political aspects of the company. The project manager must also balance the needs of the internal customers with the availability of resources in order to support new applications joining the environment.

LOB applications are vital to running an organization. They are generally large programs with capabilities that tie into databases and database management systems. They can include accounting, supply chain management, and resource planning applications. Increasingly, LOB applications are being connected with network applications that have user interfaces and with personal applications such as e-mail and address books.

Systems Analyst

A systems analyst is responsible for assessment and categorization of the various data and services to be integrated into the Access Manager deployment. The systems analyst interviews the LOB application owners and gathers details on technical requirements including platform, architecture, and the deployment schedule. With this information, the systems analyst formulates a plan about how the application will be integrated into the deployment in order to meet their customer’s requirements. The systems analyst must be an IT generalist, with broad knowledge of various application architectures and platforms. Detailed knowledge of Access Manager architecture, services, agents, and APIs is also required.

Line-of-Business (LOB) Application Administrators

LOB application administrators are technical specialist with intimate knowledge of, and control over, the LOB application and are responsible for integration of the Access Manager policy agents, or policy enforcement point, into their application. They must clearly communicate the LOB application’s architecture, its integration points, and appropriate schedules. They are typically responsible for defining the access control model represented in Access Manager policies. They might perform custom programming to enhance the integration between Access Manager and their application (for example, session coordination). Finally, they are generally responsible for quality assurance (QA) and the regression testing of their application within the newly-deployed environment.

System Administrators

It is critical that appropriate resources are in place to deploy and maintain the availability of Access Manager. System administrators are required at the following levels. Additional administrators might also include a web container administrator who is responsible for the deployment and performance of the software container in which Access Manager is deployed.

Access Manager Administrator

The Access Manager administrator is responsible for the deployment and maintenance of Access Manager. This administrator assures the availability of the common services, provides necessary enhancements to the infrastructure in general, and configures policies and roles in particular. This administrator also helps support integration efforts by developing guidelines, and offers technical support to the LOB application administrators. An understanding of Java, XML, LDAP, HTTP, and web application architectures is critical.

Directory Server Administrator

Corporate directory services used for authentication and authorization are often already managed by a group within the organization before the Access Manager deployment is even considered. The Directory Server administrator is responsible for the availability of the directory services, as well as for accepting and integrating additions or modifications to the currently defined LDAP schema and identity data, including changes that are required to support the identity management infrastructure.

Hardware, Datacenter, and Network Administrator

Large organizations typically find economies of scale by separating hardware, operating system, data center, and network administration from middleware administration. If this is the case in your company, it is essential that there is clear communication between these various administrators. It may be critical to the deployment’s success to have access to certain machines or to establish certain network configurations; keeping these administrators aware of project milestones and requirements can facilitate a smooth rollout.

Independent Software Vendors

Sun Microsystems and other independent software vendors (ISV) are critical partners in the successful deployment of Access Manager. Purchasing packaged software allows an enterprise to diminish and distribute the cost and risk of software development across multiple organizations.

An ISV makes and sells software products that can run on one or more types of computer hardware or operating system platforms. The companies that make the platforms (for example, Sun, IBM, Hewlett-Packard, Apple, or Microsoft) encourage and lend support to the ISV.

It is in the best interest of all parties involved for ISV to develop cooperative relationships and drive successful deployments. Engage Sun technical services and other ISVs to help bootstrap the project and to convey knowledge they have gained from previous Access Manager deployments. Using technical services, as well as an open discussion with your account team (who can act as an intermediary between Access Manager engineers and your deployment team) can help insure your investment and a successful deployment.

Third Party Affiliates

If you are planning on leveraging the Federation Management capabilities of Access Manager, you will be collaborating with external partners and third party affiliates. Consider an initial deployment of this functionality in conjunction with your own internal deployment. In this case, it is important to involve the LOB application that owns the business functionality that will be delivered and to maintain communication with the technical resources of all parties. Your legal counsel can also help to establish a good relationship between involved parties.

Funding

The core IT group is often responsible for the cost of the deployment project. In fact, it is common to have internal funds transferred from an LOB application to the core group in order to fund portions of the identity management project. But, even when a single LOB application group is providing initial funding, the needs of the larger organization should be balanced with the needs of the funding group.

Setting Goals

By setting goals, an organization defines where it wants to be after the Access Manager deployment is finished. The deployment strategy is to plan a roadmap for reaching these objectives and move towards it. Goals are created by defining the expectations of all involved and getting approval early in the process.

In general, an identity management solution enhances security and improves infrastructure manageability while decreasing costs. More specifically, some common goals (and their benefits) that Access Manager allows an organization to meet include:

Ultimately, these goals, combined with an understanding of the motivation of all groups involved and information gleaned from a site survey, can be used to design an infrastructure for the deployment. In addition, they can be used throughout the deployment process to keep interested parties engaged and encourage project endorsement.

Gathering Information

A site survey can be used to gather information about the applications and data stores that will be integrated into the deployment. In addition, these departmental interviews help to forge an understanding of the motivation of the groups involved by defining their particular functions and goals. Once collected, the information can solidify buy-in from the executive sponsors as well as serve as a design blueprint. The following groups of individuals can help in a site survey:

An initial survey might include gathering information about the following items:

Business Processes

The business processes are the procedures that diverse groups in the organization define to do their job. Processes can include procedures for:

It is imperative to assess these processes because they are generally supported by the applications used by each business unit. Things to consider include:

Any changes to be made to the processes should be initiated prior to the beginning of the deployment.

IT Infrastructure

The IT infrastructure includes all the hardware servers, operating systems, and integrated applications that will be integrated into the Access Manager deployment. Consider the following:

Other technical considerations also include:

For more information, see Evaluating Applications.

Virtual Data

Virtual data is a catch-all phrase for the profiles that will access, the configurations that will be accessible from, and the data that will be secured by Access Manager. Virtual data includes, but is not limited to, user profiles (such as employees or customers), data and service access rules, and other types of corporate data.

Other technical considerations also include:

For more information, see Categorizing Data.

Evaluating Applications

Identity management services are generally provided as a centralized IT function with corporate and business unit applications forming the extended system. Upkeep of this system hierarchy involves a core IT group that manages and maintains the server infrastructure and a satellite group of employees to maintain the LOB applications.

As large organizations often have hundreds (or even thousands) of deployed internal applications, evaluating all of them would be time-intensive and cost-prohibitive. When conducting an application survey, focus on applications that meet the following criteria:

You might develop a spreadsheet that can be used to organize the information from the most promising applications. An overall metric can be developed to compare the value of the application to the complexity of its integration. This metric might be considered an application’s degree of fitness for deployment. An example of a highly fit application might be a web application that delegates authentication to an application server on which an Access Manager policy agent is installed for security. All user information would be stored in an LDAP directory.

An example of an unfit application might have a text-based interface, running on a mainframe computer. In this case, it would be advantageous to integrate other applications while waiting for a new version of the mainframe application.

The following sections describe types of information that can be gathered when evaluating your organization’s applications. This step also helps in determining the resources that will be protected.

Platform Information

General platform information, based on your existing technologies and hardware, can be used to assess the appropriateness of an application as a candidate for integration. Collected platform information might include the following:

LOB applications might also be running third party applications (such as portals, content management databases, or human resource systems). These applications do not always deploy on platforms supported by Access Manager policy agents. If a policy agent is required, determine the deployment criteria of these applications and schedule their deployment based on the availability of a policy agent.

Security Models

It is important to document the existing security models used within the LOB applications. Typically, applications that use external authentication or authorization are candidates for deployment as well as applications that rely on external directory services. Security information might include the following:

Lifecycle of a Session

An identity’s session lifecycle is an important topic to consider when evaluating authentication applications. Make sure you have a clear picture of how a user session is created, managed, and destroyed. Clearly document this process because it will be needed during the application’s integration.

Customization and Branding

Consider any specific branding or look and feel requirements for the application. Often times, it is important to maintain an individual look and feel or to simply maintain consistency of user experience. Ensure that any customization and branding requirements are noted with your application assessment because time must be scheduled for this activity.

Categorizing Data

Having analyzed your applications and categorized them into fitness levels, you must now begin categorizing the data and services offered by those applications. This information will be used to build a security model. The categorization process itself is a procedure of data and service categorization, followed by cataloguing the existing authentication and authorization systems.

The information collected in Evaluating Applications is used for the former portion of the process. A good methodology might be to organize the collected information into various tiers of security. These tiers would indicate the amount of risk associated with data loss, application compromise, abuse, or other illicit types of access. Using well-defined categories can help to simplify the mapping of resources into a security model incorporating authentication and authorization requirements.

The data or service is separated into four levels of security. The X axis is the data or service and the Y axis is the security level associated with it. Tier 1 is illustrated with a minimal amount of security and might be data applicable to a public web site. Tier 4, on the other hand, requires maximum security and might be financial or human resources (HR) data. Your organization’s categorization might have more or less tiers, but this chart shows how typical it is for large amounts of data to have low associated risk, and thus, low security requirements. As risk associated goes up, security requirements also go up. (Usually, there is very little data with high security requirements, and a lot of data with limited or no security requirements.)

The following figure shows the security requirements for data and services within a typical organization.

Figure 2–1 Security Requirements of Data and Services

Security requirements of data and services

Keep in mind that you are planning to build functional groupings of data and service types so that authentication and authorization functions can be mapped to them. Too many tiers can inject extra complexity into your process, while too few tiers might not offer enough flexibility. It is also important to note that there might be data with too much risk to place on the network at all. If relevant, make sure distinctions are made between internal and externally available data. Keep authentication and authorization requirements in mind as you build out these tiers, as well as conditional qualifiers such as such as access time of data and network location.

Mapping To Authentication

With the data categorized according to security level, the next step is to inventory authentication and authorization mechanisms. Using a current list of available authentication mechanisms, associate those mechanisms with the security tiers defined. For example, the following association might be appropriate for the data categorized in the previous figure.

You should ensure a clean mapping between authentication requirements and the data and services categorization. If there is none, look for common criteria between those items that do not match. Don’t hesitate to make multiple charts if logical distinctions occur.

For example, separate charts can be made for intranet and extranet applications. You might also categorize data based upon a functional security domain such as human resources (HR) or finance. While not a universally applicable tool, categorizing your data in this manner can help you to understand your security requirements and to map them into logically manageable groups.

Mapping To Authorization

Using the data available from your application assessment, examine each of the applications to determine a scalable authorization model. Typically, it is best to look for common groups and roles used across applications. Ideally, these groups and roles will map to functional roles within the organization. You should also determine the source of those groups and roles (where does the membership data live and how is it modeled). For example, the data might be in Sun Java System Directory Server.

If not, custom plug-ins might be required. If a robust grouping model is in place, begin associating each application with existing groups or roles. If not, begin planning a group or role mechanism, finding common relationships between functional user types and access to specific applications. When completed, you should have the following items:

With this basic security model (categorization of data, with correlation to authentication and authorization mechanisms), you can now put together a time line to drive your deployment.

Building a Time Line

From the information you have gathered, you should build a preliminary time line. The following sections describes the steps to build a time line for a generic schedule of deployment.

Deployment Design

This phase of the time line is where the concepts, business needs, and user requirements are put in their proper context. A total view of the deployment takes shape. Components are described, technological requirements are defined, and a complete architecture is mapped out. Storyboarding login screens or creating data flow charts are two ways of initiating this design phase.

Proof-of-Concept

A proof-of-concept enables the design to be tested in a business environment. Organizations often have a test case database, a set of pre-configured test cases coupled with their expected results. The proof-of-concept can be applied to this test database, and, if all goes well, the documented results will be equivalent to the new results. A proof-of-concept aims to answer all question posed by the Deployment Design, proving that it meets all needs efficiently and with minimal risk.

It is generally fast allowing for ample time to refine the design based on a limited set of data. There are usually several rounds of proof-of-concept, followed by design refinement. The last round in the proof-of-concept should be integration of some internal applications. Integration of a corporation’s shared services often adheres to a standard model of sign-on by early adopters, followed by general participation and, lastly, the stragglers. Demonstrated success with early adopters makes it easier to use those applications as references for general adoption.

Early Adoption

Mission critical or revenue-building applications should not be chosen as your first application. A less risky strategy is to choose an important application that will not completely disrupt business operations if there are issues during roll-out. For example, a divisional portal serves as a natural staging ground for a single sign-on (SSO) roll out, rather than an accounting system at the close of a fiscal period.

Also, limit the number of applications roll-outs in the early phases so process flaws can be driven out, results demonstrated, and immediate success recognized. Minimizing organizational risk while maximizing visibility is the optimal roll-out strategy. This plan positions the deployment team with the appropriate product experience to take on critical applications.

General Participation

Although the deployment project begins with a single application, the requirements of other internal customers should be assessed at the same time so that a general purpose system can be built. The central IT group should be able to accommodate the diverse criteria and schedules of the satellite groups in order to provide service that is representative of the larger organization. Schedules must have sufficiently large windows, allowing the satellite groups time to build changes and upgrades into their application’s deployment and quality assurance (QA) cycle.

Production Environment

Following the proof-of-concept, the refined design can be replicated into a production environment. The purpose of a production environment is to demonstrate the function of the design in a non-artificial environment, ensuring its proper behavior. The environment is compared to the behavior as observed in the proof-of-concept, and as defined in the deployment design. It is also tested for stability.

An assessment is made and reports are generated. Early adoption applications go live in the production environment as they are ready. Incrementally phase new applications through the test phase and into production. Other applications are incrementally added to the production environment by working them through the proof-of-concept cycle as the early adopters have been.

Sample time lines are not available, because they vary based upon project complexity. However, this process typically takes place in a span of two to three months.

Deployment Road Map

Mapping out your Access Manager integration is imperative to ensuring its success. This process include collecting information concerning hardware, currently deployed applications, identity data, and access hierarchy. Access Manager deployment can be broken down into the following phases:

  1. Identify business objectives such as:

    • Increase operational efficiency.

    • Assure data security.

    • Assure continued productivity by understanding the scope and relationships within the organization and analyzing the behavioral changes needed to support the business objectives.

  2. Develop a high-level technology analysis and map it to the business objectives by listing technology services and tools needed to meet business objectives.

  3. Define initiatives for each technology service such as:

    • Storing employee history and data accumulated through personalization.

    • Accomplishing password synchronization and identity administration through identity management.

    • Realizing enterprise security through the development of role strategies.

  4. Prioritize initiatives based on items such as statistical accuracy, predictability, scope, cost, impact, complexity, behavior, infrastructure, benefit, support, and dependencies.