Framework Recommendations for Technologists

Note to the Reader: This section was written by Steven Carmody of Brown University. Please send comments and suggestions to authnframework-comments@internet2.edu.

Where decisions about authentication were once viewed as primarily technical, the infrastructure is now viewed as a problem with much broader ownership within the campus. This re-characterization of the process redefines the role of the Technologist within this project, and this section explains his or her new requirements and responsibilities.

Background

Over the last ten years, the campus technology environment has changed dramatically. The computing environment once consisted of a mainframe with a discrete set of applications, desktop PC's running standalone applications such as word processing, and desktop PCs running terminal emulators. Authentication occurred only when logging on to the mainframe.

Today's environment is much more complicated, more fluid, and more dynamic. Authentication is increasingly viewed as one of a set of core infrastructure services. IT organizations, in their discussions with application vendors, are increasingly trying to separate authentication from the application and convince the vendors that there are standard interfaces available to campus-wide authentication systems. Management of today's application environment is spread across the campus; many departments run servers and applications to support their own core business needs.

Evolving Roles and Responsibilities

As the set of interested players grows, the technologists will have to adapt. Proposed changes may need to be vetted with a larger set of players, each of whom will view and analyze the proposed change from their own unique perspective. Where once the sysadmins and technical managers were free to make decisions about authentication mechanisms (and, implicitly, authentication policy), the decision making process will expand to include a new set of players. Often, these new players will have requirements that run counter to "traditional practice within the institution with respect to authentication," and the group will have to work to achieve consensus. As authentication comes to be perceived as an institutional concern, the decision making process will undoubtedly become more complex.

There are many positive aspects to this change, though. As the broader community, and top administration, become the owners of the authentication process, they should feel a stronger commitment to supporting and funding its creation and operation.

The challenge facing the technologist today is to bring technical order to this distributed, decentralized environment. The technologist's role has evolved in two directions: architect and sysadmin. The architect role is responsible for facilitating the process of developing a campus authentication architecture, one part of an authentication roadmap. This is a group process, and is intended to address the broader needs of the campus. Sysadmins are responsible for maintaining detailed familiarity with products and the functionality they provide, and for ensuring the robust operation of the infrastructure.

What types of responsibilities might technologists be asked to assume in this new model?

1. Identify technical requirements. Refer to a list of possible requirements, courtesy of Mark Bruhn at Indiana University.
2. Evaluate whether a specific technology (and perhaps implementation) is consistent with and supportive of the desired set of policies and requirements.
3. Identify implementation options and constraints for a desired policy.
4. Identify and evaluate the functionality available in a specific implementation (package).
5. Identify implementation costs (both one-time and ongoing) for a particular implementation; this might include hardware, software, services, and staff costs.
6. Implement and support the recommended solution.
7. Be able to communicate technical requirements and constraints to non-technical audiences.

Framework Navigation Recommendations

We strongly recommendation that people read the entire Authentication Framework document. However, the following sections may be of particular importance and relevance to Technologists:

Revision 1.0, December 14, 2004