Copyright © 1998 Trustees of the
University of Pennsylvania
Web Security Solutions:
Implementing a Web Security Module to Support Secure, Authenticated Applications
CAUSE98, Seattle, WA
December 9, 1998
| Noam
H. Arzt, Ph.D. |
Daryl Chertcoff |
Senior Fellow |
Programmer/Analyst |
| University of Pennsylvania |
University of Pennsylvania |
| Information Systems and
Computing |
Information Systems and
Computing |
| 3508 Market Street |
3401 Walnut Street |
| Suite 252 |
Suite 221A |
| Philadelphia, PA 19104 |
Philadelphia, PA 19104 |
| 215/898-3029 (Voice) |
215/573-3570 (Voice) |
| 215/573-9023 (FAX) |
215/898-9348 (FAX) |
| arzt@isc.upenn.edu |
daryl@isc.upenn.edu |
Introduction
The development of the Internet over the past few years has led to new requirements
for controlling access to files, data and other material made available on campus
networks. Like many institutional networks at research universities, PennNet
(the University of Pennsylvania campus network) is primarily an open network.
Access to most of its resources and material is freely available to anyone on
the Internet. Some providers of information, however, have had reasons to restrict
access to network resources either to members of the university community only
or to specific individuals. Examples include:
- Some schools consider their online courseware to be proprietary and do not
choose to make it generally available on the Internet.
- Certain administrative applications should not be available from off campus,
primarily because access to them is not through encrypted means just yet.
- Local Usenet newsgroups should not be generally available outside of the
campus community.
- Certain applications, like requests for new accounts, need to be made by
authorized individuals only (for budgetary approval).
And there are many others. The subset of these resources that are available
through web interfaces are the topic of this paper.
Initial Methods
Initial strategies for access control to web material used these methods primarily:
- Domain-based restriction – The web allows for access to resources
to be restricted by domain (e.g.,upenn.edu). All attempts to access
a directory of information, for instance, that do not originate from
a computer identified with a "upenn.edu" domain can be prevented from seeing
the material. While this is fairly easy to implement, it prevents access from
legitimate viewers who may be accessing the material from commercial Internet
Service Provider (ISP) accounts that would not have a "upenn.edu" domain associated
with the connections. As more and more contention develops for limited campus
modem pools, more and more users will be forced to access from off campus
providers.
- User-based restriction – The web also allows for discreet pairs
of usernames and passwords to be created and associated with access to directories
of information. This allows users to access material from any computer on
the Internet as long as they know a valid username and password. The problem
with this solution is that it is an administrative burden when scaled to tens,
hundreds, or even thousands of users.
These methods can also be used in conjunction to
restrict access to information both by the location of the user (domain) and
the user's identity (password).
Authentication at Penn
Penn wished to circumvent the administrative nightmare
associated with maintaining separate userames and passwords for different web
applications. For several years the University of Pennsylvania has been using
a unified username space called the PennNet
Authentication System (PAS) to authenticate access to its modem pools and
other network resources. An increasing number of web developers requested to
integrate this campus-wide username/password combination into their applications
and avoid the need to maintain separate username/password pairs.
However, to ensure that these usernames and password
could not be detected and captured as they traveled across the Internet, a system
needed to be developed to provide secure, encrypted access to this namespace,
as well as to optionally provide a facility for maintaining connection "state"
for web applications. Penn developed a generic module based on a three-tier
architecture, deployed a dedicated, secure server, and is migrating authenticated
applications to this new facility. The primary goal was to enable providers
to flexibly use the campus-wide authentication system in their web applications,
while maintaining control of how the authentication system is secured and administered.
Three-tier architecture
The web security module uses a three-tier architecture
to provide application security. This approach has a number of advantages:
- It provides for separation of services that increases
the security of the overall architecture.
- This architecture allows for scalability of the
system when required.
- This architecture fits the distributed nature
of Penn where staff in schools, centers, and departments work independently
and deploy applications on many different servers.
- The web security module can be deployed in conjunction
with just about any authentication system. PAS will likely be replaced over
the next several years with Kerberos or another more standards-based authentication
system.
The three pieces of the architecture are:
- Application server – Application
developers build applications on their own school, center or department servers,
or on the central PennWeb server. This is the primary access point for the
user. Developers use a variety of languages and approaches to develop their
applications, including simple html, JAVA, JAVAScript, and CGI-based programs.
- Web security (websec) server – A central, dedicated authentication
server maintained and operated by the central university networking group
provides secure, encrypted authentication against the common username space
and maintains the state of the user's connection to the application. This
server is operated under the most restricted access rules of any server
on campus and performs this authentication function only. It runs a Secure
Socket Layer (SSL) compliant server. Communications between this server
and application servers are encrypted using 3DES encryption.
- PAS Server – Actual queries for username and password pairs
are made against a central SQL-compliant database maintained independently
through a custom-developed application programmer interface (API). The PAS
and websec servers communicate over a trusted network. Passwords sent over
this link have been hashed before transmission.
The user accesses the application on a Secure Socket
Layer (SSL) compliant browser, typically Netscape 3.n or higher.
Application flow using this model
Using the web-security approach, to access an application
a web user passes transparently to the central web security server. Once authentication
has taken place on the web security server, a token is passed back to the application
provider's webserver, where the application resumes control for the remainder
of the session. If the token is valid, the application can be certain that the
user has successfully been authenticated. The application may then continue
to to check the user's validity (i.e., maintain "state") using the token
on each of its pages. Alternatively, the application may wish to use its own
mechanism to maintain state. Once the application is done with the web-security
token, it explicitly expires (i.e.,removes) it from the web security
server.
Specifically, the steps involved are:
- The user goes to a web page where a particular service or application is
offered.
- If the application that the user wishes to use requires authentication,
he or she will click on a link provided which points to an authentication
page on the web security server. This link will contain a string that specifies
the application for which the authentication will be taking place.
- Upon clicking on this link, the user is transferred to the web security
server and presented with a screen to validate him/herself with a PennNet
ID and password. He or she has only has 45 seconds to do so.
- The web-security module authenticates the user. If authentication fails,
the PennNet ID/Password combination is incorrect, or the time limit has been
exceeded, a screen is returned indicating the problem and the process stops.
The user is given the option to reload the authentication page and start over.
- If authentication is valid, a screen is returned to the user indicating
that authentication has succeeded and asks the to submit the web form to continue
with the application. This form possesses a hidden field which contains a
token. This token has been generated by the security module and stored, along
with other relevant information, in its token database.
- The user submits the form. The token is passed by the browser to a program
representing the first page of the application, located on the application's
server.
With software modules provided by the central computing group, the application
can check the validity of the token by querying the security module's token
database, located on the web security server. If the token is valid, the
application knows that the user has authenticated him/herself for that application.
If it is not valid, either the user has not authenticated him/herself successfully,
the token has explicitly been expired, the token has timed out, or the application
for which the token was created is not the same as the one asking for information
about the token.
- For each successive page of the application, if the developer of the application
wishes to continue to use the token functionality of the security module to
maintain "state", s/he must pass the token back to the web browser as a hidden
field or set a client-side cookie containing the token. Upon arrival to each
new page, the application must check the validity of the token, following
the rules in the above step.
If the developers of the application do not wish to continue using the
token functionality of the security module, they can develop their own method
of maintaining "state", such that for each operation a user performs, they
have the assurance that the user has appropriately been authenticated. This
may be the case for applications which launch client-side programs, such
as JAVA applets.
- Once a user is done with the application or the application is finished
with the security module's token database, it expires (removes) the token
from the token database.
Current applications using the module
Several applications currently use the security
module, with others to follow:
- Online directory
update – This application allows faculty and staff to update their
entry in the campus online email directory.
- Classlists
management – This application allows faculty who are using course-specific
listservs to manage their list parameters and settings through a web interface
instead of traditional listserv commands via email.
- Online Email
account request form – This application allows for email accounts
to be requested for the central timesharing system with appropriate budgetary
authorization.
- Career Services Credentials
System – This application allows students to examine their file of
recommendation letters online.
- Medview
– a service for medical students that provides a single point of access
on the web for Internet resources.
- Soon, anti-virus software which is site licensed
will be distributed using this service.
Next Steps
Several enhancements to the web security service
will be deployed over the coming months, including improvements to the authentication
system (PAS) and deployment of a hardware-based random number generator for
generating tokens.
Copyright © 1998 Trustees of
the University of Pennsylvania