Chapter 2 Planning The Deployment

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 organizational boundaries. To ensure proper control over corporate resources, appropriate planning of the deployment process is required. This chapter offers information on how to plan the deployment. It contains the following sections:

Defining Resources

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

Human Resources

It is important to be savvy to the various business and political relationships within an organization. A team of individuals should be assembled with a direct and/or matrixed reporting structure. Typically, Access Manager deployments have small teams that might consist of a project manager and a couple of dedicated System Administrators. These 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 is often augmented by virtual team members consisting of Sun Professional Services resources, and LOB Application Administrators which phase in and out as required. While this may or may 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. This 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 will help define a concrete ROI as the deployment team attempts to shore up executive support. Other company issues that might be relevant include:

Who benefits from the identity management deployment?

What organizational problems does an identity management solution solve?

How does the company address internal issues that may slow the deployment?



Note	It is often required that identity management concepts and the value of an Access Manager deployment be sold. A business and technology evangelist can passionately sell the new infrastructure to executives, helping to drive demand for integration and aid in the acceptance and ultimate success of the infrastructure changes.

Team Lead

One person should be chosen as the party responsible for the project’s success. This team lead must be clearly in charge and have the authority to make the project’s goals happen. This may be a logically distributed role, perhaps between a technical lead, a project manager, and an executive head. However this role is defined, their goal is to show continued progress and demonstrated success throughout the deployment process to maintain executive sponsorship.

Project Management

This individual is responsible for the coordination of timelines. They will maintain 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 be a strong communicator and politically savvy. They must balance the needs of the internal customers with the availability of resources in order to support new applications joining the environment.



Note	A line-of-business application is one 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

This individual 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 its deployment schedule. With this information, the systems analyst formulates a plan on how the application will be integrated into the deployment in order to meet their customer’s requirements. They 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 required.

LOB Application Administrators

These individuals 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. This individual might perform custom programming to enhance the integration between Access Manager and their application (for example, session coordination). Finally, they are generally responsible for QA and the regression testing of their application within the newly-deployed environment. This individual is a technical specialist with intimate knowledge of, and control over, the LOB application.

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

This individual is responsible for the deployment and maintenance of Access Manager. Typically a dedicated resource, this individual assures the availability of the common services, provides necessary enhancements to the infrastructure in general and configures policies and roles in particular. They typically help support integration efforts by developing guidelines, and offer technical support to 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. This individual 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; changes that might be required to support the identity management infrastructure.

Hardware/Datacenter/Network Administrator

Large organizations typically find economies of scale by separating hardware, operating system, datacenter and/or 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 individuals aware of project milestones and requirements will 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.



Note	An independent software vendor 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 (IBM, Hewlett-Packard, Apple, Microsoft, etc.) encourage and lend support to ISV. Sun Microsystems makes platforms and software products.

It is in the best interest of all parties involved for ISV to develop cooperative relationships and drive successful deployments. Engage Sun Professional Services and other ISV to help bootstrap the project, and impart knowledge they have gained from previous Access Manager deployments. Using Professional 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) will 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 which will be delivered and maintain communication with the technical resources of all parties. Your legal counsel can also help to establish a level playing field 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 is defining where it wants to be after the deployment of Access Manager 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:

Implementation of a scalable infrastructure to meet the expected increase in digital identities (employees, partners, and customers).

Consolidation of the creation and management of identity profiles with each group controlling their own data.

Cost reduction through vendor consolidation, user self-management and related administration costs.

Improvement of security through immediate identity profile termination.

Improved transparency of security models and access rights.

Condensing timeframes required for access to critical systems.

Removal of user rights to critical systems as roles or affiliation within the organization change.

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.

Users provide feedback on the applications with which they work on a daily basis.

Human resources provides information on hiring and termination processes.

Support personnel offer insight into problems that cross organizational boundaries.

Application administrators and developers can provide technical information on the line-of-business (LOB) applications to be integrated into the deployment.

Network administrators have knowledge of the organization’s technical baseline for performance and standards.

Business Processes

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

Issuing payroll.

Purchasing and accounts payable.

Authorizing employee travel.

Departmental budgeting.

Terminating employees.

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

Do the current processes cause delays?

Are there a number of different processes that perform the same function?

Can processes be standardized across business unit boundaries?

How complex are the processes? Can they be consolidated and/or simplified?

Can the current processes handle organizational changes?

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.

What applications will leverage Access Manager?

Applications might include critical internal applications such as those for human resources and accounting, or less-critical employee portals. Also leveraging the functionality of Access Manager might be external business-to-business applications that deal with both confidential financial information and less confidential sales material, or business-to-consumer shopping carts that are concerned with credit card data and purchase histories.

What systems will leverage Access Manager?

This includes the hardware on which the applications are being deployed as well as their operating systems. An Access Manager deployment, at the minimum, includes a web container to run the application, a Sun Java System Directory Server (or existing data store) and the Sun Java System Access Manager application itself. It will likely also include additional hardware servers which run their own web containers. They contain corporate resources and on which Access Manager policy agents may be installed for purposes of security.

What Access Manager services will each department leverage?

This includes the default and custom services integrated within Access Manager. Role and policy strategies will have to be mapped and defined for each department. Authentication modules need to be assessed and custom services, if any, need to be developed.

Are there incompatibilities in the infrastructure?

Does the current system experience slowdowns? Down time?

Are the applications sufficiently secure?

Are there virus control procedures?

Can applications be customized based on user entitlements?

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. This includes, but is not limited to, user profiles (employees, customers, etc.), data and service access rules, and other types of corporate data.

What assets will Access Manager be protecting?

Access Manager secures access to all types of data and services. An administrator can regulate who can view and/or configure Access Manager data as well as control access to applications, portals and services.

What users will leverage Access Manager?

Users might include employees, business partners, suppliers, and current or potential customers. Each user will have a profile which includes, at a minimum, their user ID and password. Employees will undoubtedly have larger and more confidential profiles than customers signing in for a look at external sales information.

What data will be accessible?

Data might include public information, internal information, confidential information, and restricted data. This might also include sales information on an external website, confidential employee profiles, access rules which protect corporate resources, server configuration information and federated customer profiles. This data may or may not be stored on Directory Server.

What is the authoritative source of the data?

There are often multiple schemas that define different types of data. These definitions need to be reconciled within your deployment. Be aware of data ownership issues, allowing the various LOB applications to maintain control over their data, where appropriate. It is imperative to balance the demands of the satellite groups in order to provide service that is representative of the overall enterprise as all services are critical to the larger organization.

Is the same information defined in multiple attributes?

Do users have multiple cross-organizational profiles?

Are the data stores located in front of the firewall?

Is the data consistent across different data stores?

How often is new data added, or existing data modified?

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:

Are of particularly high value to the organization.

Would naturally benefit from integration into a single sign-on infrastructure.

Are indicative of standard programming and deployment platforms within your organization.

Are generally receptive to the identity management infrastructure.

Are currently in the early process of deployment or refactoring, and might logically have timelines that coincide with the Access Manager deployment.

You might develop a spreadsheet which 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 it’s integration. This 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 be a green screen application (one with a text-based interface) driven off a mainframe. In this case, it would be advantageous to integrate other applications while waiting for a refactoring/architecture of the mainframe application. The following sections detail types of information that can be gathered when evaluating your organization’s applications.

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:


Note	This step also helps in determining the resources that will be protected.

What operating system (including version) do the applications run on?

Which web containers (including version) do they run in?

With what programming model are the applications developed? (Java, ASP/.NET, C, etc.)

Are there plans to upgrade the applications? If so, what is the timeline?



Note	LOB applications may 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 agents. Be prepared to assess the deployment criteria of these applications and schedule their inclusion based on agent availability. If custom work is required, Java-based applications are typically easier to integrate.

Security Models

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

What authentication mechanisms are currently being used?

Are their special authentication requirements (such as 2-factor authentication)?

Is there a pluggable interface for external authentication mechanisms?

What authorization mechanisms are currently being used?

Can authorization be externalized? Does it make sense to do so?

What user data repositories are being used? Can these be externalized?

Who can access the application? Are there existing roles or groups in place? Under what special conditions are they granted access?

Lifecycle of a Session

An identity’s session lifecycle is an important topic to assess 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 as it will be referred to when working on the application’s integration. More information on this topic can be found in Appendix B, "The User Session Life Cycle."

Customization and Branding

Specific branding or look and feel requirements for the application needs to be considered. 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 as time needs to be scheduled to account for this.

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 will help to simplify the mapping of resources into a security model incorporating authentication and authorization requirements.

Figure 2-1 is a chart reflecting data within a typical organization. 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 website. Tier 4, on the other hand, requires maximum security and might be financial or HR data. Your organization’s categorization may 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 do also. (In reality, there is very little data with high security requirements, and a lot with no security requirements.)

Keep in mind that you are aiming to build functional groupings of data and service types so that authentication and authorization functions can be mapped to them. Too many tiers will inject extra complexity into your process while too few 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 might be appropriate for the data categorized in .

Tier 1 data might be appropriate for anonymous authentication with no access control.

Tier 2 data might require password protection only.

Tier 3 data might require hard token or certificate authentication.

Tier 4 data might require multifactor authentication or might even be data that is not placed on the network.

You should ensure a clean mapping between authentication requirements and the data/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 HR or finance. While not a universally applicable tool, categorizing your data in this manner will help you to understand your security requirements, and 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/roles used across applications. These ideally will map to functional roles within the organization. You should also determine the source of those roles/groups (where does the membership data live and how is it modeled). Ideally, this will exist in Sun Java System Directory Server. If not, custom plug-ins may be required. If a robust grouping model is in place, begin associating each application with existing groups or roles. If not, begin planning a role or group mechanism, finding common relationships between functional user types and access to specific applications. When completed you should have the following:

A clear map of existing roles and groups.

A clear understanding of where that data lives, and who is the authority over its quality and management.

A clear understanding of new groups or roles that need to be created to facilitate your deployment, or to reduce cost/complexity.

A mapping of existing and future grouping mechanisms to your categorized applications.

Notes on additional conditions required by the applications to allow access to a certain group or role.

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

Building Timelines

From the information you have gathered, a preliminary timeline should be built. The following sections detail the steps for a generic schedule of deployment.

Deployment Design

This phase of the timeline is where the concepts, business needs and user requirements gathered heretofore 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 bed database, a set of pre-configured test cases coupled with their expected results. The proof-of-concept can be applied to this test bed 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 certain to be 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 hub application which 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 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 analysis (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. It 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 bed 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.



Note	Sample timelines are not available, as they are variable based upon project complexity, but this process typically takes place in a span of 2-3 months.

Tuning Your Deployment

After you install Access Manager 6 2005Q1, you can tune your deployment for optimum performance using the amtune and related scripts. These scripts allow you to tune Access Manager, the Solaris™ Operating System (OS), the web container, and Directory Server.

The Java Enterprise System installer installs the tuning scripts and related files in the bin/amtune directory.

The amtune script is not interactive. Before you run amtune, you must edit the parameters in the amtune-env configuration file to specify the tuning you want amtune to perform for your specific environment. The amtune-env configuration file includes two major sections:

Performance related parameters that you set to control the tuning.

An internal section that is maintained by Access Manager engineering and should not be modified.

Review mode: amtune reports tuning recommendations but does not make any actual changes to your environment.

Change mode: amtune makes actual changes, except for Directory Server, depending on parameters in the amtune-env configuration file.

The amtune script does not automatically tune Directory Server. Most deployments have applications other than Access Manager that also access Directory Server, so you don't want to make tuning changes without considering how they would affect your other applications.



Note	Before you tune Directory Server, first back up your Directory Server data using db2bak.

When you run amtune, the script creates a tar file that contains the Directory Server tuning script, amtune-directory. Untar this file in a temporary directory and then run the script in review mode. When you are certain that your changes are acceptable for all applications at your deployment, run amtune-directory in change mode.

For detailed information about running the tuning scripts and setting tuning parameters in the amtune-env configuration file, see the Sun Java System Access Performance Tuning Guide.

Previous Contents Index Next
Sun Java System Access Manager 6 2005Q1 Deployment Planning Guide