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
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.
Table of Contents
There are two aspects to securing a web application(or context) within the Jetty server:
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.
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
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.
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:
A user realm that is backed by a hash map that is filled programatically or from a java properties file.
Uses a JDBC connection to an SQL database for authentication
Uses a JNDI defined datasource for authentication
Uses a JAAS provider for authentication
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.
See an error or something missing? Contribute to this documentation at Github!