- 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
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.
- 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:
- read
data which is protected due to business or privacy
requirements
- modify
or enter data which could seriously affect the
Institute's business interests.
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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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".
- Standard
Development Environment
Applications
should be developed under standard development
environments.
- 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:
- Use
development tools that support writing and calling
external functions (e.g. in C).
- Minimize
custom changes to purchased software to those required
to make the software work properly with the MIT
infrastructure. Changes significantly increase the
on-going maintenance and upgrade costs to the
software.
- Applications
must not duplicate or use conflicting infrastructure
components.
- Make
use of existing infrastructure components. (See the
document "The
MIT Information Technology
Infrastructure"
for a list of components.)
- Applications
should have the ability to export data from the system
in a non-proprietary format.
Information
[Technology] Policies, Rules and Guidelines Roundup 2002