<< previous | next >>

4.4. Develop Technology Infrastructure

• Assemble Existing Constraints and Map Business Requirements to Technology Requirements
• Decide on Mechanisms and Processes
• Perform Initial System Integration(s) in the Test Environment

A critical part of the design or architecture of your infrastructure is ensuring that it supports the business and policy requirements to a sufficient degree. If unacceptable gaps exist, the technology leads must work with the policy and process colleagues to achieve consensus on how to proceed. For example, the authentication technology requirements of a library providing access to resources for all state residents will tend to be very different from the authentication requirements necessary to secure an organization’s payroll and accounts payable operations.

At this stage, there are several basics tasks to be completed. (A more complete description of each of these tasks can be found in the design phase of the Enterprise Directory Implementation Roadmap).

Case Study (PDF) —Tom Barton from the University of Chicago discusses their authentication architecture.

The central authentication service will most likely consist of or be dependent on a set of central services, such as:

These in turn will be used by the applications integrated in the course of the overall project.

Assemble Existing Constraints and Map Business Requirements to Technology Requirements

In addition to identifying the components required, whether existing or new, consider any technology and staffing or organizational constraints and determine what you can and can't easily change. At this point, it's best to understand the spectrum of the business requirements and how they impact your available authentication (and identity management) technology choices before you wade off into making specific product decisions. Consider walking through the following issues:

Decide on Mechanisms and Products

Given the technical requirements identified above, there are a number of vendor and open-source solutions to consider. At this stage, you are deciding on your protocols and products to support. Common mechanisms include:

For more information on these and other methodologies and common practices, refer to the further resources below.

A Request for Information (RFI) from vendors of interest could be done at this stage for either a broader identity management package or authentication system. However, while purchasing an integrated vendor solution will impact the technical work, it does not reduce the identity-related policy and business process work associated with the identification and credentialing functions.

Case Study (PDF) – University of California Riverside

Andrew Tristan explains the authentication approach at UC-Riverside.
Case Study (PDF) – Brandeis University

William Goedicke discusses Brandeis University's identifier practices.

 

Perform Initial System Integration(s) in the Test Environment

Consider any dependencies that have emerged, which must first be acquired or upgraded before another implementation step can occur. These may include:

Run the initial implementation as a limited non-production pilot long enough to fully exercise all initial system capabilities and uncover unexpected wrinkles. Do extensive scaling and load testing. Modify system configuration and documentation as necessary. Make sure logs and related analysis tools are useful and events can truly be parsed, tracked, and audited. And finally, review the utility of documentation and the handling of unusual cases such as de-provisioning those users who, through malfeasance, lose the privilege to access services.

During the [next] stage, you'll work with the application stewards to set a trial run of all the processes and technology components to ensure things are running smoothly before you migrate to production.

<< previous | next >>