MIT InformationSystems

Infrastructure Requirements for Applications and Systems

construction image

NOTE: This document is subject to change.
Last major revision of principles: June 1997
Most recent minor modifications: March 30, 2000

Please send suggestions to The MIT Information Technology Integration Team.



The MIT Information Technology (I/T) computing infrastructure encompasses the hardware and software components underlying MIT's cross departmental and Institute wide administrative and academic computing systems. The requirements outlined in this document are intended to help I/T teams deploy applications that are compatible with this infrastructure. For additional information on the infrastructure, see the document "The MIT Information Technology Infrastructure".

Use of Requirements

The requirements identified in this document are intended primarily for I/T teams developing or purchasing cross departmental and Institute wide applications and systems, however all I/T teams are encouraged to review the requirements and to carefully consider both short and long term implications of any alternative technical solutions. This document may be incorporated into consulting or development contracts, however MIT's I/T Integration Team reserves the right to remove or modify requirements for those specific contracts.

To ensure compatibility with the MIT architectural infrastructure, exceptions to these requirements may only be granted upon the recommendation of the I/T Integration Team.


Network Security

The MIT network (MITnet) supports administrative, faculty and student use both on and off of campus including collaboration with colleagues at other universities. While many corporations use firewalls to protect themselves from unauthorized network intruders, the unique requirements for MITnet are not compatible with firewalls and thus require stricter network security mechanisms. Vendors often incorrectly assume that firewalls are sufficient.

Firewalls assume that the "bad guys" are outside the firewall and that the "good guys" are inside the wall. At MIT, the identification of "bad" and "good" guys can not be as easily determined since:

Many of the requirements outlined in this document are a direct result of the fact that the MIT infrastructure must provide mechanisms to protect its systems from unauthorized users while providing access to authorized users in many locations.


Document Conventions

Each requirement identified in this document includes a requirement name, description and optional supplemental text in the following format:
  • 1. Requirement Name



    Requirement Description

    Optional Supplemental Text

    Application Requirements

    The current MIT Application Requirements are as follows:
    1. Client/Server Applications on MITnet



      A Client/Server (C/S) architecture must be used for all non-web applications.

      The traditional two-tiered C/S model should be sufficient for most applications, however if the application is complex or the number of transactions between the client and server is large, then a three-tiered architecture may be required. Two-tiered C/S provides presentation level support at the desktop and business processing on a server. In a three tiered approach, the client talks to a "middleware" server that then talks to a backend database server. The "middleware" server may be implemented using a standard TP monitor, or by implementing the server such that it exports an application specific protocol which is used by the client. A significant advantage of the three-tiered model is that the business processing is done on a centrally controlled machine. This provides for increased security and in some case makes it possible to change the business processing logic in the middleware without making changes to the client. Three tiered architectures also provide better scalability and significant performance advantages for more complex applications.

    3. Web Based Applications



      Web Based applications may be used but must follow additional web specific guidelines.

      Web-based applications need to meet the same authentication, authorization, and encryption requirements identified for traditional Client/Server applications in this document. Implementation differences between Client/Server and Web based applications are noted within the requirement descriptions and supplemental text portions of the requirements.

    5. Authentication



      For security reasons, Client/Server and Web based applications must determine if a user is who they claim to be either by using an authenticated Kerberos ID or by using X.509 certificates issued by the MIT certificate server (Certifying Authority).

      While security requirements may vary from application to application, a secure authentication method must be used whenever users can do either of the following:

      All Client/Server applications must use MIT's standard network authentication service, Kerberos. Authentication must take place between the client and server or in the case of three tiered applications between the client and the middleware server.

      For Web based applications authentication is provided through the MIT Certifying Authority, the MIT certificate server. Users must obtain an MIT certificate from the MIT certificate server before accessing a secure MIT web service. See the document "Obtaining Certificates for Accessing Secure Web Services at MIT".

      IP addresses should not be used for either authentication or authorization especially for applications that are available to the entire MIT community. While technically servers can use IP addresses to identify MIT clients, this is not a scalable practice for MIT applications since many members of the MIT community have IP addresses outside of Net 18 (18.*.*.*) and a growing number of users have IP addresses from independent Internet Service Providers (ISP).

      While Client/Server applications can utilize Kerberos authentication directly, Web based applications need to use X.509 certificates. A server that authenticates users based on X.509 certificates does not need to maintain a list of IP addresses, and it can accommodate both on- and off-campus MIT users. (See the transcript of Jeff Schillers' s12/3/96 talk on Web authentication technology.) MIT supports a certificate server that allows a user to get an MIT certificate with their Kerberos ID and password. These MIT certificates should be used by all secure MIT Web based applications.

    7. Authorization



      For security reasons, Client/Server and Web based applications must provide server authorization to determine if an authenticated user is allowed to use services provided by the server.

      Client/Server applications must not rely solely on client based authorization, since this makes the application server and/or database vulnerable to an attacker who can easily bypass the client-enforced authorization checks. Such security attacks are possible via commercially available SQL tools and by modifying and replacing client software.

      For three tiered Client/Server applications the middleware server must be responsible for performing user authorization checks. The backend database server must also be configured so that it will only accept requests from the middleware server or from privileged system administrators. Otherwise, clients would be able to bypass the authorization and data consistency checks performed by the middleware server.

    9. Data Encryption



      Applications that transmit sensitive information including passwords over the network must encrypt the data to protect it from being intercepted by network eavesdroppers.

      Users of an application that has been granted an exception to this requirement must be specifically and explicitly warned against using their Kerberos passwords for that particular application. This is to prevent an insecure application from jeopardizing MIT's entire computing infrastructure, the ramifications of which may be both financial and legal.

      Data Encryption for Client/Server applications is provided by Kerberos. Web applications that require data encryption should utilize Secure Socket Layer (SSL).

    11. Network Protocols



      Client/Server applications must operate on the current MITnet communications protocol (TCP/IP).

      Although MITnet currently also routes AppleTalk, it is not considered a robust nor reliable protocol for Client/Server applications.

    13. Accessible User Interface (Added in November 1998)



      Applications, must be accessible to individuals with disabilities.

      Both internally developed and vendor provided software, must include interfaces, on at least one desktop, that accommodate individuals with disabilities. Exceptions to this requirement are granted, with appropriate documentation, only when there are no compliant packages in the marketplace and when building such an interface is excessively expensive.

    15. Desktop Configurations



      Client applications must run on all currently supported desktop configurations.

      Currently supported desktop configurations may be found in Appendix A of this document.

    17. Server Configurations



      Server software must support one of the standard server platforms.

      Currently supported server configurations may be found in Appendix A of this document.

      Servers other than those run by Network Operations must not collect or store Kerberos passwords.

    19. Relational Databases



      Applications needing to use relational databases must use MIT's standard database server technology and data models.

      Currently supported database configurations may be found in  Appendix A of this document.

      The MIT data models are defined by the MIT Data Administrators. Development teams need to submit proposed application data models with a statement of scope to the MIT Data Administrator for review. The Data Administrator will ensure that the data model is consistent with existing MIT data models. For more information on Data Administration Requirements, see the document "Data Administration Requirements".

    21. Standard Development Environment



      Applications should be developed under standard development environments.

    23. Development Guidelines



      I/T teams need to follow the I/T development guidelines for internally developed and purchased vendor products.

      I/T development guidelines include the following:


    Appendix A

    This appendix summarizes the Integration Team' recommended products. For additional information on the architecture itself, see the document "The MIT Information Technology Infrastructure".
    Information Systems home page | Integration home page

    MIT InformationSystems Comments about these pages
    Last modified: 06/21/2000 

    Document Hits since August 4, 1998: