Web Conference 2004

Writing Perl/CGI Scripts for ITS/ASET Web services

Web Authentication, Authorization and Access Control

What are Authentication, Authorization and Access Control?

Authentication is the process to prove someone's identity is authentic. Anyone can claim to be xyz123, but only one can supply the correct password. Besides password checking, other methods are available for verifying someone's identity such as public key signatures, certificates, SecureID cards, biometric authentication and more. On the Web, there are two popular authentication methods and variations to be discussed below.

Authorization is the process to determine if an identity has the privilege to access specific data, systems or resources. Permission settings such as Access Control Lists, user groups and attributes are examples of authorization methods. It is common for authentication and authorization to be used as buzzwords to describe access control.

Other forms of Access Control exist, such as restricting based on time of day or IP address.

Forms of authentication and authorization used on the Web

Methods of authentication over the Web include:

HTTP Basic Authentication (RFC 2617) - a method which requires a Web browser to supply a username and password in the "Authorization:" HTTP header of the request. The Apache server has documentation on how to secure a Web folder with .htaccess files.

Below is an example .htaccess and .htpasswd file that are used to secure the /.../dce.psu.edu/fs/users/x/y/xyz123/www/secure/ folder allowing the account "safeuser" access with the password "cl0$uRe":

/.../dce.psu.edu/fs/users/x/y/xyz123/www/secure/.htaccess
AuthUserFile /.../dce.psu.edu/fs/users/x/y/xyz123/www/secure/.htpasswd AuthType Basic AuthName "xyz123's secure folder" require valid-user
/.../dce.psu.edu/fs/users/x/y/xyz123/www/secure/.htpasswd
safeuser:2/aw70AHy0uco

When xyz123 authenticates using her (or his) "safeuser" account, the username "safeuser" appears in the REMOTE_USER environment variable and may be read in Perl via $ENV{'REMOTE_USER'}.

Each and every request to files in the secure folder will require the Authorization: header to be supplied (*). If the password is not supplied or incorrect, the server will issue a "401 Unauthorized" status code and a "WWW-Authenticate" header field. The transaction may look like this:

Browser --HTTP==> Web Server
GET /users/x/y/xyz123/www/secure/ HTTP/1.0
Browser <==HTTP-- Web Server
HTTP/1.1 401 Authorization Required Date: Sun, 13 Jun 2004 23:43:04 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.2 OpenSSL/0.9.5a WWW-Authenticate: Basic realm="xyz123's secure folder" Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>401 Authorization Required</TITLE> </HEAD><BODY> <H1>Authorization Required</H1> This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.<P> <HR> <ADDRESS>Apache/1.3.12 Server at test.scripts.psu.edu Port 80</ADDRESS> </BODY></HTML>
Browser --HTTP==> Web Server
GET /users/x/y/xyz123/www/secure/ HTTP/1.0 Authorization: Basic c2FmZXVzZXI6Y2wwJHVSZQ==
Browser <==HTTP-- Web Server
HTTP/1.1 200 OK Date: Sun, 13 Jun 2004 23:43:08 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.2 OpenSSL/0.9.5a Connection: close Content-Type: text/html <html> <body> <p>Here're my secret files...</p> <p><a href="meetingminutes.html">Last week's meeting minutes</a></p> <p><a href="suggestions.html">Suggestions on running a better meeting</a></p> </body> </html>

* - If the HTTP connection is not secured with SSL, it is rather trivial for a network eavesdropper to discover the password. The username and password are encoded in Base64 encoding, which is rather straightforward to reverse. RFC 2617 also defines a second method of passing an encrypted password. However this digest password is marginally more secure. An eavesdropper may not know the password but can easily reuse the digest password to obtain access in what's known as a replay attack. Most who wish to secure sites with HTTP passwords choose to use SSL encryption which uses modern day encryption techniques. This gives the added advantage of also securing the Web pages while in transit over the networks.

One main caveat with HTTP Basic passwords, besides requiring SSL for any real sense of security, is virtually every browser in existance does not provide any way of "logging out" or forgetting the password, be it user or server requested, except for when the user closes the browser and all associated windows.

CGI passwords - A password may be passed over a CGI parameter. The following HTML is a typical way passwords are passed over CGI - notice how the password field prints * instead of your password:

HTML code
<form method=POST action="http://test.scripts.psu.edu/users/x/y/xyz123/www/scripts/secureapp.cgi"> <p>Login:</p> <p>Username: <input type="text" name="username" size="8" maxlength="20"></p> <p>Password: <input type="password" name="password" size="8" maxlength="20"></p> <p><input type="reset"><input type="submit"></p> </form>
HTML code
Login: Username: Password:

HTML code

<form method=POST action="http://test.scripts.psu.edu/users/x/y/xyz123/www/scripts/secureapp.cgi">
<p>Login:</p>
<p>Username: <input type="text" name="username" size="8" maxlength="20"></p>
<p>Password: <input type="password" name="password" size="8" maxlength="20"></p>
<p><input type="reset"><input type="submit"></p>
</form>

HTML code

To login to successive pages, the password could be set in a hidden CGI parameter in dynamically generated pages. However this exposes the password to the browser cache, which can be read later by others. A better way is to use CGI passwords with cookies. Just like HTTP Basic authentication, CGI parameters are exposed to eavesdroppers without SSL encryption.

Cookies - Cookies are a form of data assigned by the server to be returned later by the browser. Not all browsers support cookies and most that do allow the user to elect not to accept specific cookies. However, despite their shortcomings for tracking purposes, they have been a highly usable component in most modern day Web applications that require secure login. Because the cookie can be a temporary authentication value that can be expired by the server - when the server decides to no longer accept a previously assigned cookie, it allows the server to set a true session time-out. It can also preemptively "Log out" a user by request of the user by clicking a "Logout" button. The server just needs a database to track which cookies have been assigned, what accounts they have been tied to, and when they are to time out. Design of a cookie-based authentication system, which is usually accompanied by a CGI password form for user session login, is the responsibility of the application designer.

Cookies can be assigned as below - the cookie values are static for simplicity:

Example Perl code
#!/usr/local/bin/perl use CGI qw(:standard); $cookie_to_send = cookie(-NAME => "sessionid", -VALUE => "tempvalue013427", -EXPIRES => "+15m"); print header(-COOKIE => $cookie_to_send); print <<END; <html> <body> <p>Welcome to the secure application.</p> </body> </html> END
Browser <==HTTP-- Web Server
HTTP/1.1 200 OK Server: Apache/1.3.12 (Unix) mod_ssl/2.6.2 OpenSSL/0.9.5a Connection: close Set-Cookie: sessionid=tempvalue013427; path=/; expires=Mon, 14-Jun-2004 03:19:15 GMT Date: Mon, 14 Jun 2004 03:04:15 GMT Content-Type: text/html; charset=ISO-8859-1 <html> <body> <p>Welcome to the secure application.</p> </body> </html>
Browser --HTTP==> Web Server
GET /users/x/y/xyz123/www/scripts/secureapp.cgi HTTP/1.0 Cookie: sessionid=tempvalue013427

Later on, when the user logs out, the server removes the cookie from the database, and then expires the cookie in the browser by passing a cookie of the same name with an immedate expiration date. You can do this in Perl with -EXPIRES set to "now".

Browser <==HTTP-- Web Server
HTTP/1.1 200 OK Server: Apache/1.3.12 (Unix) mod_ssl/2.6.2 OpenSSL/0.9.5a Connection: close Set-Cookie: sessionid=tempvalue013427; path=/; expires=Mon, 14-Jun-2004 03:10:15 GMT Date: Mon, 14 Jun 2004 03:10:15 GMT Content-Type: text/html; charset=ISO-8859-1 <html> <body> <p>Thank you for using the Secure App. You have been successfully logged out.</p> </body> </html>

Browser <==HTTP-- Web Server

HTTP/1.1 200 OK
Server: Apache/1.3.12 (Unix) mod_ssl/2.6.2 OpenSSL/0.9.5a
Connection: close
Set-Cookie: sessionid=tempvalue013427; path=/; expires=Mon, 14-Jun-2004 03:10:15 GMT
Date: Mon, 14 Jun 2004 03:10:15 GMT
Content-Type: text/html; charset=ISO-8859-1

<html>
<body>
<p>Thank you for using the Secure App.  You have been successfully logged out.</p>
</body>
</html>

As with digest passwords, cookies can limit exposure of the real password, but are still susceptible to replay attacks if SSL is not used.

More info on cookies are available online at a number of sites, including http://www.cookiecentral.com/.

Penn State Access Account login - There are a few means of doing this, including Kerberos modules with Basic HTTP auth. The Basic HTTP authentication mechanism (over SSL) securely passes the password to the Web server which attempts a kerberos login. If the login attempt is successful, the session will be treated identically as if a local password was checked in an .htpasswd file. The successfully logged in username will be present in the REMOTE_USER environment variable.
WebAccess - A new Penn State service to be released for general use in July, uses a technology called CoSign developed by the University of Michgan. This service allows Penn State Access Accounts to be authenticated to various Web sites but only requires the CGI passwords to go to a specific, central server. Other "target" sites obtain notification a user has authenticated via a combination of cookies, CGI parameters and an out-of-bound check. The "Authentication at Penn State" concurrent session at the Web Conference has more information about WebAccess and CoSign. WebAccess will supply target sites the userid of the authenticated user via the REMOTE_USER environment variable just as HTTP Basic authentication in Apache.

<- Back - SQLite

Redirects - Next ->

If you have any questions, feel free to ask me - mailto:jcd@psu.edu

Last update on: Thursday, 17-Jun-2004 11:49:12 EDT