|
About CSE Secure Web Service |
|
 CSE Home |
About Us |
Search |
Contact Info |
1 April 2009
What
Do I Need to Know?
|
|---|
A "secure" web service is provided that makes it both safe and increasingly useful for a user to type their CSE username and password to a web browser. For example, we use the secure service to allow CSE users to access MVIS (visitor schedules and room reservations) from remote locations. We can use the same service to enhance the level of a limited realm of service to non-CSE users as well. The enhanced services are based upon technolgies called "TLS" and "Kerberos 5". This document was written to explain the highlights of the service to our users.
The host named weblogin.cs.washington.edu has been
configured to run a special web service that supports TLS - Transport
Layer Security (nee SSL- the Secure Socket Layer). The service was
deployed to allow the CS Laboratory to provide web services both with
a higher level of security and with a greater richness of
authentication and authorization mechanisms.
This document outlines the technical underpinning of the service, explains how we expect it to enhance the level of web services we can provide, and what we additionally hope to achieve in the near future.
TLS provides access to web services over an encrypted channel, which means that it is not practically possible for even a determined foe to monitor the web conversation. TLS is the same technology that's used by internet commerce to make transmission of such sensitive data as credit card numbers and banking information over the Internet safe.
 |
 |
 |
| IE Secure |
Netscape Secure |
Netscape Insecure |
|---|
You can tell when you are using TLS because the URL for the resource will start with "https" instead of "http". Additionally, browsers add a little padlock icon to the browser frame when you are accessing an TLS-secured site.
A web server proves its identity to a web browser by providing a "server certificate" as part of the setup of an TLS connection. Typically, such a certificate has been signed-- vouched for-- by a certificate authority (CA) that your browser has been preconfigured to recognize. In such cases, the certificate is silently validated and accepted.
In contrast, the server certificate on most CSE servers has been signed by the University-local "UW Services CA." The fact that your browser is not preconfigured to accept certificates signed by UW Services CA means that you will be shown a series of informational dialog boxes during the TLS conversation setup. The dialog boxes allow the opportunity to reject, temporarily accept, or permanantly accept the certificate. In order to access TLS services on many CSE web servers, you will need to at least temporarily accept this UW-signed certificate. We recommend that you accept them permanently (unless, like us, you have a "thing" for dialog boxes).
(By authentication, we mean "determining user identity." By authorization, we mean defining which users are permitted to access a resource.)
In order to allow CSE users to access resources that must not be shared with everybody that browses our web, we have long employed some simple authentication and authorization mechanisms.
One such mechanism has been to allow access to some resources only from hosts on our local networks. We refer to such mechanisms as "hostname-based." The room reservation system is an example of such a resource. This mechanism is losing utility as more and more CSE users work from remote locations using third-party network service providers (ISPs).
A second mechanism has been using made-up usernames and passwords. We refer to this as "basic authentication." We haven't used real usernames and passwords because it is dangerous to pass such information over unsecured channels. This has limited the utility of this mechanism to the protection of only lightly-secured resources.
With the provision of the TLS service, it becomes safe for users to provide their actual user names and passwords over the network. The TLS service we have deployed has the capability of checking those usernames and passwords against our existing kerberos 5 authentication service.
With TLS/SSL, we can practically offer authentication based upon CSE usernames and passwords. That allows us to designate resources as authorized for use by specific members of the CSE community.
By specifying groups of users, we can also replace some instances of password-based by less secure and convenient "basic" authentication. For example, we can create resources for which only CSE faculty, administrative staff, or technical staff are authorized users.
It also becomes practical to suggest to outside users that they provide personal information to us over the network, perhaps to apply for admission to our educational programs.
Still hungry for details? Strap on your beanie cap, pop the top of a can 'o Jolt, and browse to
 |
Computer Science & Engineering University of Washington Box 352350 Seattle, WA 98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to webmaster] |