• Beyond Scope

  The following are beyond the scope of this proposal.

  • Authorization also need but not satisfied within this document

    This document covers only a methodology for adding infrastructure authentication to Web browsers accessing elements requiring authentication within the institution. While some of the server modifications proposed can be simply extended to provide a base level of authorization, this document in and of itself does not seek to provide answers to establishing authorization for services.

• (R1) If passwords go across the network, they must be encrypted

The sending of passwords across the network should be minimized. If they are sent, they must be protected by strong encryption. This will minimize the usefulness of "sniffer" attacks that monitor network packets.

• (R1)Limit exposure of passwords to hosts

Secure handling of user passwords is critical. Ideally users should only type their passwords into system immediately in front of them. The scheme should not require password-handling by every web server that wishes to use authentication. This will minimize the trust that users have to place in web servers they access.

• (R2) Permit non-SSL-encrypted connections where appropriate

An authentication design that requires all connections to use SSL encryption at all times solves some security problems, but at the cost of substantial performance reduction, and of changing all URLs to be https://. The use of SSL encryption should be available when an application or document requires protection of the data stream, but otherwise should not be required simply to support authenticated access.

• (R3) Encrypted stream for data

The data path on the network between the Web server and the client browser must have a method for secure, encrypted transmission. Not every application will require the use of encrypted connections, but it must be available for those that do.

• (R4) Ability to authenticate user within the infrastructure

There needs to be a clear and viable way to identify the browser user in terms of the campus (enterprise) environment. As the campus environment is using Kerberos for general authentication, the authentication should provide identification of a Kerberos principal.

• (R5) Minimize changes to URLs and access methods

As much as possible the scheme should work transparently with existing URLs (http://host/ and https://host/). Adoption of the scheme will be much more difficult if users are required to create new URLs for their authenticated pages.

• (R6) Permit user-written, untrusted applications to co-exist on the same server

In some server environments it is attractive to support simple web-based applications that are "user-written." Such applications are not reviewed by professional staff, are not monitored for security or performance, and can be installed by ordinary users on a multi-user system. In particular, such applications may be actively hostile to other applications running on the same server. Providing support for them means protecting applications on a server such that a rogue application cannot compromise another by reading its files or environment variables, spoofing its operations, etc.

• (R7) API for access to authentication information via CGI programming

Programmers need a simple API for calling the web authentication module. A simple set of calls for getting the authenticated Kerberos principal is needed.

• (R8) Placement of authentication information into environment variables

For CGI scripts, the results of authentication should be accessible via environment variables if the server is capable of overseeing the web authentication process. This eliminates the need for the CGI programmer to use the web authentication API.

• (R9) Support easy-to-use secure access control for static documents

Many people who make documents available via the web would like to control access to them to a limited set of users. Currently, this is done using HTTP Basic Authentication, which requires username/password management by the document supplier, and is as insecure as any other method that sends passwords in the clear. This also sometimes done using a non-advertised URL which is otherwise unprotected; this is obviously insecure, and requires document users to remember the URLs.

To make this capability as widely accessible as possible, it should work without requiring programming or password management by the document provider. Ideally, it should use the existing authentication infrastructure and require no more than putting a list of authorized usernames in the appropriate location (similarly to the current .htaccess file usage). Use of access control should be independent of the use of encryption on transmitted documents, which imposes unnecessary overhead on applications that don't require this level of protection.

• (R10) Maintain authenticated status in some manner

The use of authenticated status is often tied to the notion of a "session" with a service. These "sessions" span multiple HTTP transactions and programmers need a method of maintaining the authentication of the browser user across the span of the "session".

• (R11) Applicable across browser implementations and desktops (with defined security restrictions)

The authentication method supplied needs to be usable across browsers with the restriction that desktops that are without the installed infrastructure security elements (ie, to authenticate requires that you submit a password over the network) must have a browser capable of the established connection encryption mechanism (eg, SSL).

• (R12) Accomodate identification through either SUNet ID or UnivID/PIN mechanisms

This mechanism needs to allow for the establishment of authentication through either the preferred SUNetID or the legacy UnivID/PIN methodology.

• (R13) Should be able to apply to departmentally-maintained servers as well as centrally maintained services (with some defined restrictions)

Departments should be able to take advantage of the deliverables within the limits of operating system and established security level requirements.

	( $status, $auth_id, $auth_age, $ident_type, $ident_method ) =
		&get_local_auth ( $lifetime, $token_loc );

	&get_remote_auth ($return_url, $ident_type, $token_loc,
		$formcall_method, $return_method );

	$lifetime	-	the allowed lifetime in seconds of the
				authentication

	$token_loc	-	where the token for authentication can
				be kept (any combination of cookie, 
				embedded in the url with @@, path_info,
				or query_string as represented by "c", 
				"e", "p", "q"

	$status		-	a result status on the call's actions.
				This is presented in the form of:
					Numeric code:Error string
				(See Status Codes)

	$auth_id	-	if authentication was successful, a
				SUNet ID or Univ ID (as indicated by
				$ident_type) will be returned

	$auth_age	-	the time (in seconds (?)) since the
				authentication action occurred

	$ident_type	-	the form of identification that was
				returned
				(See Identification Types)

	$ident_method	-	the manner in which authentication was
				established
				(See Authentication Methods)

	$return_url	-	the URL that the authentication service
				should redirect the client browser to
				after authentication is completed

	$ident_type	-	the form of identification that is 
				desired - uses the Identification Types
				with the addition of the key "any"
				(See Identification Types)

	$token_loc	-	where the token for authentication should
				be put (any combination of cookie, 
				embedded in the url with @@, path_info,
				or query_string as represented by "c", 
				"e", "p", "q"

	$formcall_method -	whether the authentication service
				should be called by a redirect or to 
				prompt the user with a form button
				indicating authentication is required

	$return_method	-	whether the authentication service
				simply redirects back to the $return_url
				or verifies authentication to the user 
				with a hyperlink pointing back to
				$return_url 

200 : Success

301 : No return URL provided

400 : No Auth Found

500 : Auth Unsuccessful

600 : Auth Expired

701 : DES operation failed

702 : Open of srvtab failed

The 300 codes indicate a failure from the calling services. For example, the 301 code indicates that the calling service failed to provide a return URL for the web authentication service to redirect back to after authentication is completed.
The 400 code indicates that no tokens were found and that no callback mechanisms responded for the client.
The 500 code indicates that a token was found that either didn't match the results of a responder on the client or that was unusable.
The 600 code indicates that the token found was outside the time boundaries of the requested $lifetime and, if a callback was successful, it too was outside the boundaries of $lifetime.
The 700 codes deal with internal configuration or setup errors.

The Webauth Token

The webauth token consists of six colon-separated items. These items are:

User (principal) or UnivID

Indicates the authenticated principal name or confirmed UnivID.

create_time

Indicates the time at which the principal was authenticated. (This can vary dependent upon whether the authentication method was via responder or proxy.)

Identification Type

Indicates what type of User is being provided.

client_IP

Indicates the IP address of the actual authenticating client (used in particular with proxy authentication).

Authentication Method

Indicates which authentication method (responder, proxy, etc.) was used to establish the User.

Data

To be determined. Placeholder field for possible use with session state requirement.

The webauth token is DES-encrypted in the web service key and then converted to base64. It is then prefixed with either a local: or a remote: tag to indicate that the web service (local:) itself created the webauth token or the proxy authentication service (remote:) did the creation.

Identification Types

The web_auth package can establish identification for the following recognized types:

UnivID

a numeric University ID

SUNet ID

the "person" (aka principal) SUNet ID type

Authentication Methods

The web_auth package establishes authentication by the following recognized methods:

Leland Agent

Using the current version of MacLeland

S/Ident

Using the versions of Mac/PC/Unix responders that utilize the S/Ident protocol

Proxy

Using the redirect method to the proxy authentication server that prompts the client for a username/password pairing

Client

Using tools such that the client actually establishes its own authentication token to pass for get_local_auth

Modified Server Options

Integration of the WebAuth process into an Apache server module is expected as well (in particular, this work will be done for the WWW-Leland Web services) but the deliverable is anticipated after the delivery of the general base WebAuth module.

Integration will produce the following service extensions:

File Access Control

This allows users to base authentication simply upon the existing .htaccess control method by simply adding a new AuthType.

• AuthType StanfordAuth

The server is modified to recognize the AuthType StanfordAuth which allows for htgroup files and require statements in the access control file for a directory to contain the authenticated user's identity rather than having to maintain a separate and unique passwd file. require valid-user would then indicate an authenticated client browser session.

Environment Variables

For CGI programmers using a modified server, the authentication process built into the server will set several environment variables. The standard variable that gets set is the standard REMOTE_USER, with several WebAuth specfic SU_AUTH_* type variables also being established:

SU_AUTH_AGE

how old the current credential is

SU_AUTH_USER

same as REMOTE_USER but specific to the webauth setup

SU_AUTH_METHOD

by what method the user was authenticated

SU_AUTH_TOKEN

If authentication has been previously established and the client browser is passing the webauth token in a cookie, SU_AUTH_TOKEN is set with the encrypted webauth token.

Note: Indeed REMOTE_USER should not be assumed for the API, but rather assume SU_AUTH_USER so that there can't be any mistake about what kind of authentication the user established, as REMOTE_USER may be set through a variety of methods.

Long Term Expectations

The use of personal digital certificates for authentication is anticipated in the future and will require modifications to the infrastructure and service delivery for integrated functionality. Actual specifications are currently still too unclear to provide a full impact analysis.