J2EE Security – Web Tier Security

Web – Tier Security

Web – Tier Security involves security provided by web containers for components, such as servlets, JSP and Java Server Face pages. Web containers enforce security in a manner that is transperent to web components

We can implement web – tier security by defining and mapping security roles and specfying  security constraints. A security constraint defines authentication rights to access a web resource collection, which is a list of Uniform Resource Locator (URL) patterns and HTTP methods that describe a set of resources to be protected. If a user tries to access a protected web resource, the web container authenticates the user. The web container accepts a user request only after the user is successfully authenticated.

Web-tier security is configured when the application is deployed to a web container. We can use deployment descriptors and annotations to declare and relay security information to the application deployer.

Web-Tier Authorization

Web-tier authorization involves declaring security roles and specifying security constraints by using both depoyment descriptors and/or annotations. Web-tier authorization requirements are defined in the web.xml deployment descriptor file. The web-app element contained in the descriptor is the root element for web-based applications element contains the following sub-elements:

1. security-role-ref contains the declaration of a security role reference. A security role reference defines a mapping between the name of a role that is called from a web component using the isUserInRole method and the name of a security role that has been defined for the web-based application. This element is contained within the servlet element, so that the roles defined in one servlet might be independent of those defined in other servlets.
2. security-role is used in conjunction with the security-role-ref element to map roles defined in code to the roles for the application.
3. security-constraint is used to define the access privileges to a collection of resources using URL mapping. The following elements are parts of a security constraint:
3.1 web-resource-collection — Describes a URL pattern and an HTTP method pair, which identify resources that are to be protected. 
3.2 Auth-constraint — Indicates which users in specified roles are permitted access to a resource collection.  
3.3 user-data-constraint — Specifies network security requirements, such as confidentiality and integrity. If a transport guarantee of INTEGRAL or CONFIDENTIAL is declared, all user name and password information is sent over a secure connection using HTTPS.
3.4 login-config — Specifies the user authentication method to be used for access to web content, such as basic, form-based, digest, and client certificate.

The code example shows the elements in a deployment descriptor file that are used to declare security for web resources. In this code, security constraints are defined for SalesInfo and access restricted to the GET and POST methods. Also, the network security requirement is set to CONFIDENTIAL to enable HTTPS. Only a user with the role manager has access rights.

<!– SERVLET –>
<servlet>
 <servlet-name>catalog</servlet-name>
 <servlet-class>com.mycorp.CatalogServlet</servletclass>
 <init-param>
  <param-name>catalog</param-name>
  <param-value>Spring</param-value>
 </init-param>
 <security-role-ref>
  <role-name>MGR</role-name>
  <role-link>manager</role-link>
 </security-role-ref>
</servlet>

<!– SECURITY ROLE –>
<security-role>
 <role-name>manager</role-name>
</security-role>

<servlet-mapping>
 <servlet-name>catalog</servlet-name>
 <url-pattern>/catalog/*</url-pattern>
</servlet-mapping>

<!– SECURITY CONSTRAINT –>
<security-constraint>
 <web-resource-collection>
  <web-resource-name>SalesInfo</web-resourcename>
  <url-pattern>/salesinfo/*</url-pattern>
  <http-method>GET</http-method>
  <http-method>POST</http-method>
 </web-resource-collection>
 <auth-constraint>
  <role-name>manager</role-name>
 </auth-constraint>
 <user-data-constraint>
  <transport-guarantee> CONFIDENTIAL</transport-guarantee>
 </user-data-constraint>
</security-constraint>

<!– LOGIN CONFIGURATION–>
<login-config>
 <auth-method>BASIC</auth-method>
</login-config>

Web-Tier Authentication
Web-tier authentication can be implemented in the following ways:

HTTP basic authentication
Form-based authentication
HTTPS client authentication
Mutual authentication 
 

HTTP Basic Authentication

In HTTP basic authentication, the server requests and validates a user name and password from web clients. When basic authentication is declared, the following occurs:

1. A user requests access to a protected resource through a web client.
2. The web server sends an HTTP challenge back to the client.
3. The client then prompts the user for a user name and password.
4. When the user enters a user name and password, the client sends this data back to the web server.
5. The server authenticates the user in the specified realm, assigns an identity to the user request, and retrieves the user’s security roles to verify that the user belongs to one of the roles defined in the auth-constraint element of the deployment descriptor for authorization. If successful, the server returns the requested resource. Otherwise, the server communicates a failure through 401 or 403 HTTP error messages.
HTTP basic authentication is not secure. It sends user names and passwords over open networks as text using simple base64 encoding. Also, the target server is not authenticated. In addition, the authentication data is not held in the HTTP session. Therefore, if the session times out or becomes invalid, the user remains logged in.

HTTP basic authentication is also not flexible. In HTTP basic authentication, a user cannot logoff. Instead, the user has to close all instances of an application client. If the user cancels a login, a 401 HTTP status is returned to the client from the server. The application also has no control over the number of user login attempts, and we cannot change the appearance of the login window.

However, we can achieve confidentiality in HTTP basic authentication by secure transport mechanisms, such as SSL, or by providing security at the network level using Internet Protocol Security (IPSec) protocol or virtual private network (VPN) strategies.