Archive for the ‘IT planning’ Category

School Technology Infrastructure

May 4, 2006

I’ve started compiling what I hope will be a comprehensive list of the essential elements of a school information technology infrastruction. This is very much a work in progress, compiled by reviewing the technology plans of various schools and unerversities.  I’ll start by summarizing the strategic IT plan of Stanford University, found at

Basic Infrastructure

  • Authentication
  • Authorization
  • Backup
  • Calendar
  • Desktop Management
  • Directory
  • Email
  • Identity Management
  • Integration
  • Printing
  • Storage
  • Voice
  • WWW Services
  • Windows Infrastructure

Let’s describe each one at a time:


The goal of an authentication system is to provide a highly stable, centrally administered authentication service both for internal use by IT Services and for use by any and all campus systems that need to authenticate the population of users affiliated with Stanford. We must attempt to balance the following concerns:

  • A set of systems capable of handling the full authentication volume of all university business, tied into university-established notions of identity from the student and HR systems as well as sponsored and guest accounts, and able to centrally handle in a timely fashion withdrawal of authentication capability to terminated employees or abusive users.
  • Use of industry-standard and vendor-supported authentication technology to ease integration with vendor applications and software developed elsewhere while avoiding locking ourselves into any one vendor.
  • A highly secure authentication system that will be able to meet security concerns going forward. The authentication system must never be the weak point in the security of an application and must be sufficient to comply with regulatory restrictions such as HIPAA.
  • Users must be able to authenticate via hosts other than their normal desktops, including mobile devices in the future.
  • Authentication should be external to applications so that authentication mechanisms can be updated or changed to reflect changing requirements without requiring significant application development or surgery.
  • Authentication should be mutual, allowing clients to confirm the identity of the server as well as allowing the server to confirm the identity of the client. This will assist in preventing phishing and man-in-the-middle attacks.

Given the prevalence of the web as a user interface to applications, a trend which is expected to continue, special attention should be paid to standardized web authentication as the place that the most users will interact with the authentication system.

When possible, we will push for the ideal of never letting a user’s authenticator leave their local system under their physical control. This means using network authentication protocols based on a local identity cache rather than sending a password or passphrase to a server for verification. However, we must recognize that there is very little vendor support for such authentication systems at present, particularly in common desktop clients, and most software is still stuck on the model of verifying a password on the server. When it is necessary to send an authenticator to a server, that conversation must always be encrypted. (In other words, the network link shall not be trusted.)

All Stanford users will have to interact with the authentication system to do their daily work. In addition, all application developers and system administrators on campus, inside ITSS and out, represent a key audience for our authentication strategy. If we do not meet their needs, they will develop their own separate authentication systems, which both harms our ability to centrally manage authentication and hurts the consistency of the user experience. The goal is to get as close to universal use of the central authentication services as possible.

The authentication system will be closely tied to any campus identity management or authorization systems, and therefore will be directly affected by any projects in those areas even if those projects are not authentication projects directly.

Enterprise Applications

  • Student Information Systems – enrollment, grade tracking, attendance
  • Business Information Systems – Payroll, Budget, Purchasing, Finance
  • Transportation Management
  • Foodservice Management
  • Library Automation
  • Special Education Management
  • Course Management – authoring, testing, assignments