 |
Infrastructure Requirements for Applications and Systems |
 |
|
Infrastructure Requirements for Applications and Systems |
|
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.
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.
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:
Requirement Description
Optional Supplemental Text
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:
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.
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.
Currently supported desktop configurations may be found in Appendix
A of this document.
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.
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".
Applications should be developed under standard development environments.
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:
 |
Comments about these
pages
Last modified: 06/21/2000 |
Document Hits since August 4, 1998: