Jetty Logo
Contact the core Jetty developers at www.webtide.com

private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery

DRAFT

This page contains content that we have migrated from Jetty 7 or Jetty 8 documentation into the correct format, but we have not yet audited it for technical accuracy in with Jetty 9. Be aware that examples or information contained on this page may be incorrect. Please check back soon as we continue improving the documentation, or submit corrections yourself to this page through Github. Thank you.

Chapter 6. Configuring Security

Table of Contents

Authentication
Authorization
Limiting Form Content
Aliased Files and Symbolic links
Secure Password Obfuscation

Authentication

There are two aspects to securing a web application(or context) within the Jetty server:

Authentication

The web application can be configured with a mechanism to determine the identity of the user. This is configured by a mix of standard declarations and jetty specific mechanisms and is covered in this section.

Authorization

Once the identify of the user is known (or not known), the web application can be configured via standard descriptors with security constraints that declare what resources that user may access. See Configurating Security - Authorization

Configuring an Authentication mechanism

The jetty server supports several standard authentication mechanisms: BASIC; DIGEST; FORM; CLIENT-CERT; and other mechanisms can be plugged in using the extensible JASPI or SPNEGO mechanisms.

Internally, configurating an authentication mechanism is done by setting an instance of a the Authenticator interface onto the SecurityHandler of the context, but in most cases it is done by declaring a < login-config> element in the standard web.xml descriptor or via annotations.

Below is an example taken from the jetty-test-webapp web.xml that configures BASIC authentication:

  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Test Realm</realm-name>
  </login-config>
    

The jetty-test-webapp web.xml also includes commented out examples of other DIGEST and FORM configuration:

  <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>Test Realm</realm-name>
    <form-login-config>
       <form-login-page>/logon.html?param=test</form-login-page>
       <form-error-page>/logonError.html?param=test</form-error-page>
    </form-login-config>
  </login-config>
    

With FORM Authentication, you must also configure URLs of pages to generate a login form and handle errors. Below is a simple HTML form from the test webapp logon.html:

<HTML>
<H1>FORM Authentication demo</H1>
<form method="POST" action="j_security_check">
<table border="0" cellspacing="2" cellpadding="1">
<tr>
  <td>Username:</td>
  <td><input size="12" value="" name="j_username" maxlength="25" type="text"></td>
</tr>
<tr>
  <td>Password:</td>
  <td><input size="12" value="" name="j_password" maxlength="25" type="password"></td>
</tr>
<tr>
  <td colspan="2" align="center">
    <input name="submit" type="submit" value="Login">
  </td>
</tr>
</table>
</form>
</HTML>
    

The Authentication mechanism declared for a context / web application defines how the server obtain authentication credentials from the client, but it does not define how the server checks if those credentials are valid. To check credentials, the server and/or context also need to be configured with a LoginService instance, which may be matched by the declared realm-name.

Configuring a LoginService

A LoginService instance is required by each context/webapp that has a authentication mechanism, which is used to check the validity of the username and credentials collected by the authentication mechanism. Jetty provides the following implementations of LoginService:

HashLoginService

A user realm that is backed by a hash map that is filled programatically or from a java properties file.

JDBCLoginService

Uses a JDBC connection to an SQL database for authentication

DataSourceLoginService

Uses a JNDI defined datasource for authentication

JAASLoginService

Uses a JAAS provider for authentication

SpnegoLoginService

SPNEGO Authentication

An instance of a LoginService can be matched to a context/webapp either by:

  • A LoginService instance may be set directly on the SecurityHandler instance via embedded code or IoC XML

  • Matching the realm-name defined in web.xml with the name of a LoginService instance that has been added to the Server instance as a dependent bean.

  • If only a single LoginService instance has been set on the Server then it is used as the login service for the context.

Configuring a HashLoginService

The HashLoginService is a simple and efficient login service that loads usernames and credentials from a java properties file in the format:

See an error or something missing? Contribute to this documentation at Github!