Message-ID: <1657694967.298256.1368909580239.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_298255_274044305.1368909580238" ------=_Part_298255_274044305.1368909580238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Security realms allow you to secure your web applications against unauth= orized access. Protection is based on authentication (identifying who is re= questing access to the webapp) and access control (restricting what can be = accessed and how it is accessed within the webapp).
A webapp statically declares its security requirements in the web.xml fi=
le. Authentication is controlled by the
lement. Access controls are specified by
<security-role-ref> elements. When a request =
is received for a protected resource, the web container checks if the user =
performing the request is authenticated, and if the user has a role assign=
ment that permits access to the requested resource.
The Servlet Specification does not address how the static security infor=
mation in the
WEB-INF/web.xml file is mapped to the runtime en=
vironment of the container. Jetty does this with the "realm" con=
A realm has a unique name, and is composed of a set of users. Each user = has authentication information (e.g. a password) and a set of roles associa= ted with him/herself.
You may configure one or many different realms depending on your needs. = A single realm would indicate that you wish to share common security inform= ation across all of your web applications. Distinct realms allow you to par= tition your security information webapp by webapp.
When a request to a web application requires authentication or authoriza=
tion, Jetty will use the
<login-config><realm-name> element in the web.xml file to perform an exact match to=
a realm defined in a jetty xml configuration file (or programmatically).=
Realm definitions in jetty xml configuration files are placed in a secti= on like this:
Alternatively, you may define a realm for just a single webapp in a context deployment file:
Jetty provides a number of different realm types from which you can choo= se.
This realm is a simple realm whose autentication and authorisation infor= mation is stored in a properties file. Each line in the file contains a use= rname, a password, and 0 or more role assignments. The format is:
The HashUserRealm is configured with a name and a reference to the locat= ion of the properties file:
You can also configure it to check the properties file regularly for cha=
nges and reload when changes
are detected. The
refreshInterval is in seconds:
In this implementation, authentication and role information is stored in= a database accessed via JDBC. A properties file defines the JDBC connectio= n and database table information. Below is an example of a properties file = for this realm implementation:
The format of the database tables is:
If you want to use obfuscated, MD5 hashed or encrypted passwords the 'pw= d' column of the 'users' table must be large enough to hold the obfuscated,= hashed or encrypted password text plus the appropriate prefix.
The pseudo-sql to set up each of these tables would look like:
A JDBCRealm is defined with the name of the realm and the location of th= e properties file describing the database:
Please also see the page on JAAS authent= ication and authorization with Jetty.------=_Part_298255_274044305.1368909580238--