We have seen enough theory on Authentication and Authorization. Now we will actually get our hands dirty trying it out for basic and digest authentication.

Steps to configure basic/digest authentication can be summarized as:

1. Define the type of authentication (here BASIC/DIGEST)

2. Define roles, users and create mapping between them

3. Define resource collections to which security should be applied

4. Map roles with security constraints

Initial setup

Before configuring security, we will create the basic setup needed along with two servlets and a JSP to test the application.

• Create a Dynamic Web Project with a web.xml file; name it as ServletSecurity.

• Create a servlet RestrictedServlet with url pattern “/RestrictedServlet” that print “Restricted Servlet” to client.

• Create a servlet OpenServlet with url pattern “/OpenServlet” that print “Open Servlet” to the client.

• Create a JSP SimpleJSP.jsp that print “Simple JSP” to client.

• Try executing the servlets and JSPs to see if they are executed and above tests are printed:

  • http://localhost:8080/ServletSecurity/SimpleJSP.jsp

  • http://localhost:8080/ServletSecurity/RestrictedServlet

  • http://localhost:8080/ServletSecurity/OpenServlet

Define the type of authentication

We can specify the type of authentication we want using the <auth-method> element inside the <login-config> element, which is inside the <web-app> element.

<login-config>

  <auth-method>BASIC</auth-method>

  <realm-name>Restricted Access</realm-name>

</login-config>

Define users and roles

Assigning users to roles are specific to Java EE servers:

• Apache Tomcat server, by default, support XML configuration files to store user and role mappings and also JDBC realm (looking credentials from a database).

• Users can be configured in tomcat in the file tomcat-users.xml under the directory <TOMCAT-INSTALL-DIR>/conf.

Create two new roles and then two users belonging to those roles in the file tomcat-users.xml:

<role rolename="administrator"/>

<role rolename="user"/>

<user username="admin" password="tomcat" roles="administrator"/>

<user username="user1" password="tomcat" roles="user"/>

We should also specify the roles we want to use in the application in the <role-name> element inside the <security-role> element, which is inside the <web-app> element.

You may have only one <role-name> element inside the <security-role> element, but you may have any number of <security-role> elements.

We can define two roles we need as:

<security-role>

  <role-name>administrator</role-name>

</security-role>

<security-role>

  <role-name>user</role-name>

</security-role>

Without this if you use the role you will get an error in log that used in an <auth-constraint> without being defined in a <security-role>.

Define resource collections to which security should be applied

Authorization and confidentiality requirements for a specified collection of web resources can be specified using the <security-constraint> element.

<security-constraint>

  <web-resource-collection>

  <web-resource-name></web-resource-name>

  <url-pattern>/*</url-pattern>

  </web-resource-collection>

</security-constraint>

Map roles with security constraints

We can map security constraints with user roles using the <auth-constraint> sub element of <security-constraint> element.

Place this also inside the <security-constraint> element:

<auth-constraint>

  <role-name>administrator</role-name>

</auth-constraint>

Complete security constraint element will now look as:

<security-constraint>

  <web-resource-collection>

    <web-resource-name></web-resource-name>

    <url-pattern>/*</url-pattern>

  </web-resource-collection>

  <auth-constraint>

    <role-name>administrator</role-name>

  </auth-constraint>

</security-constraint>

Deploying and executing the application

Export the project as a war and deploy the application into the tomcat and run the servlet and JSP urls:

• http://localhost:8080/ServletSecurity/RestrictedServlet

Client browser will show a pop-up as:

If you give the user and password for a role with required permission (e.g. admin/tomcat) as defined in the tomcat-users.xml file, you will be allowed to access the servlet and you can see the text.

If you enter a valid user, but from a role which does not have permission (e.g. user1/tomcat), you will get “HTTP Status 403 – Access to the requested resource has been denied” response.

If you cancel the password prompt, you will get HTTP Status 401 with a description that this request requires authentication.

Important Notes and TODOs!

1. The url-pattern /* indicates that the whole application requires authentication.

   1. TODO: Change the pattern to “/RestrictedServlet” and now only RestrictedServlet will be having security constraint, not OpenServlet or SimpleJSP.jsp.

2. Since we have not specified any <http-method> tag inside <web-resource-collection>, this constraint will be applicable for any HTTP Methods.

   1. If we mention <http-method>GET</http-method> and <http-method>POST</http-method>, then this constraint will be applicable to only GET and POST.

3. <role-name>*</role-name> denote all authenticated users belonging to all roles in the application

   1. TODO: Change the web.xml to allow all authenticated users to access the OpenServlet.

4. Omitting all <role-name> elements will grant access to all users irrespective of whether they are authenticated or not.

   1. TODO: Change the web.xml to allow anyone to access the SimpleJSP

Confidentiality and data integrity are configured using <transport-guarantee> sub element of <user-data-constraint> element, which is a sub element of the <security-constraint> element. Default is NONE, which is equivalent to having the below code in the <security-contraint> element:

<user-data-constraint>

<transport-guarantee>NONE</transport-guarantee>

</user-data-constraint>

We will see <transport-guarantee> in detail in another demo.

Digest Authentication

Just change the value of <auth-method> element inside the <login-config> element from BASIC to DIGEST. Everything else is same for both BASIC and DIGEST authentication.

There will be no difference from outside, but change will be in the way password is actually sent in the response.

We will next see how password is actually transmitted in case of BASIC and DIGEST.