Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Identity Server Deployment Guide

Chapter 2
Planning The Deployment

Sun ONE Identity Server 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 Identity Server 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, Identity Server 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 Identity Server 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, i.e.: what is the current cost of 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:

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.


A line-of-business application is one vital to running an organization. They are generally large progams 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 Identity Server 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 Identity Server architecture, services, agents, and APIs is required.

LOB Application Administrators

These individuals are responsible for integration of the Identity Server 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 Identity Server policies. This individual might perform custom programming to enhance the integration between Identity Server 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 availabilty of Identity Server. 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 Identity Server is deployed.

Identity Server Administrator

This individual is responsible for the deployment and maintenance of Identity Server. Typically a dedicated resource, this individual assures the availabiltiy 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 Identity Server 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 Identity Server. Purchasing packaged software allows an enterprise to diminish and distribute the cost and risk of software development across multiple organizations.


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 Identity Server deployments. Using Professional Services, as well as an open discussion with your account team (who can act as an intermediary between Identity Server 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 Identity Server, 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.


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 Identity Server 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 Identity Server 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 inital survey might include gathering information on Business Processes, the IT Infrastructure and Virtual Data.

Business Processes

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

It is imperative to assess these processes as 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 Identity Server deployment.

Additionally, more technical considerations might include:

More information can be found in "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, Identity Server. This includes, but is not limited to, user profiles (employees, customers, etc.), data and service access rules, and other types of corporate data.

Additionally, more technical considerations might include:

More information can be found in "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:

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 Identity Server 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.


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:

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:

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 assesment 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.)

Figure 2-1  Security Requirements Of Data And Services

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 flexability. 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 Figure 2-1.

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 requirments, and map them into logically manageable groups.

Mapping To Authorization

Using the data available from your application assesment, 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 ONE Directory Server. If not, custom plugins 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 machinism, finding common relationships between functional user types and access to specific applications. When completed you should have the following:

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.


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 visability 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 adoptors have been.


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.

Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.