Members
Technology Policies and Standards
Enterprise Architecture Guide
ITAG Services
Works in Progress Wiki
Contact Us
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 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
Standards Are Required to Ensure 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 MITnet machines are accessible world wide via the Internet
- some members of the MIT community need world wide remote access to MITnet
- not all applications on MITnet are available to the entire Institute
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.
Each requirement identified in this document includes a requirement name, description and optional supplemental text in the following format:
- Requirement Name
Requirement Description
Optional Supplemental Text
Application Requirements
The Enterprise Architecture Guide (EAG) gives a more comprehensive overview of the MIT technical environment and its implications to developers.
Consistent with the EAG, these are the current MIT
application requirements:
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. |
|
|
| 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 |
|
|
| 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 Schiller's 12/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. |
|
|
| 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. |
|
|
| 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). |
|
|
| 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. |
|
|
| 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. |
|
|
| Client applications must run on all currently supported desktop configurations |
| For information about current and future supported applications, contact itag@mit.edu |
|
|
| Server software must support one of the standard server platforms. |
|
For information
about current and future supported applications, contact
itag@mit.edu. |
|
|
| Applications needing to use relational databases must use MIT's standard database server technology and data models. |
|
For information about
current and future supported applications, contact
itag@mit.edu. 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" |
|
|
| The development environment should be appropriate to the desktops being supported. This usually means a cross-platform tool. |
|
|
| /T teams need to follow the I/T development guidelines for internally developed and purchased vendor products. |
|
I/T development guidelines include the following:
|
