Web programming

Units WEB1P and WEB2P

Java web application security

Introduction

Many web applications require the implementation of a security system - usually ensuring that only authorised users can access specific parts of a web site.

Security has two basic concepts: authentication and authorisation. Authentication is how users prove who they say they are. Authorisation is how access to specific features is allowed or disallowed.

Categories of security mechanism

  1. Container-managed (e.g. Tomcat)
    1. Specified as part of the Java Servlet Specification
    2. However, the implementation is container specific (and therefore not necessarily portable between containers)
  2. Application-managed
    1. Independent of the container
    2. However, you have to write the code yourself (or use some other mechanism)

HTTP authentication

Important to note the facilities that HTTP provides for authentication. These are specified in RFC 2617.

HTTP authentication operates on a challenge/response paradigm. If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code. The client must then resend the request with an Authorization header. To do this, most browsers will prompt the user for a username and password. (Most browsers cache this for the duration of the browser session; some will allow the user to save it between sessions. We leave it as an exercise for the reader as to whether storing a password on the client machine is secure or not!)

Note the distinction between Basic Authentication and Digest Authentication. While the former passes usernames and passwords in clear text (actually in Base64 format, but this is easily translatable), the latter scrambles the password by sending a checksum (by default, MD5) of the username, the password, a given nonce value, the HTTP method, and the requested URI. The nonce value is sent by the server with the 401 response.

HTTP authentication operates within a realm. A realm is essentially the store (e.g. file, database, ...) against which user credentials are checked.

Mechanisms for securing Java web applications

  1. Fundamentals
    1. HTTP authentication (RFC 2617)
    2. Secure Sockets Layer (SSL) (Configuring SSL in Tomcat 5.5)
    3. HTTP over SSL (HTTPS)
  2. Container-managed security (see Java Servlet Specification for details)
    1. Security constraints in web.xml
      1. Authentication - specify how users are to be authenticated
        Basic (using HTTP)
        <login-config>
            <auth-method>BASIC</auth-method>
        </login-config>
        Form-based (see below)
        <login-config>
          <auth-method>FORM</auth-method>
          <form-login-config>
              <form-login-page>/login.jsp</form-login-page>
              <form-error-page>/fail_login.html</form-error-page>
          </form-login-config>
        </login-config>
      2. Authorization - constrain access to specific URLs according to user role
        Restrict access to URL to particular role(s)
        <security-constraint>
            <web-resource-collection>
                <web-resource-name>Admin</web-resource-name>
                <url-pattern>/admin/*</url-pattern>
            </web-resource-collection>
            <auth-constraint>
                <role-name>private</role-name>
            </auth-constraint>
        </security-constraint>
        Define role
        <security-role>
            <role-name>private</role-name>
        </security-role>
      3. Secure transport - insist that certain URLs can only be accessed via HTTPS
        <security-constraint>
            ...
            <user-data-constraint>
                <transport-guarantee>CONFIDENTIAL</transport-guarantee>
            </user-data-constraint>
        </security-constraint>
    2. Authentication methods:
      1. Basic - uses HTTP Basic Authentication
      2. Digest - uses HTTP Digest Authentication
      3. Form - presents a login form to the user (OnJava article by Dion Almaer)
        <form method="POST" action="j_security_check">
            <input type="text" name="j_username">
            <input type="password"   name="j_password">
        </form>
      4. Client certificate - requires digital certificate from client
    3. Tomcat 5.5 standard realms
      1. MemoryRealm - a file (tomcat-users.xml) in the TOMCAT/conf directory
      2. JDBCRealm - specify tables and columns of a database that contain usernames, passwords and roles
      3. DataSourceRealm - similar, but using a JNDI-named DataSource rather than a specific JDBC driver
      4. JNDIRealm - looks up users in an LDAP directory server accessed by a JNDI provider
      5. JAASRealm - authenticates users through the Java Authentication & Authorization Service (JAAS) framework
  3. Application-managed security
    1. Request properties
      1. request.getRemoteUser()
      2. request.getUserPrincipal()
      3. request.isUserInRole(role)
    2. Use session attributes to store the user's identity
    3. Use cookies to store username and password (can be persistent between browser sessions)
    4. Use a security filter
    5. Use a base servlet
    6. Use a custom JSP tag (forward request to a login page if the user is not logged in or does not have authorisation)
    7. Struts facilities:
      1. Use Struts roles (each action has a roles attribute)
      2. Customise the Struts RequestProcessor (specifically the method processPreprocess)
      3. Use a Struts Base Action
  4. Mix and match (e.g. see SecurityFilter for an example which mimics container-managed security in an application-managed way)

Further reading

From the booklist

 

Last updated by Prof Jim Briggs of the School of Computing at the University of Portsmouth

 
The web programming units include some material that was formerly part of the WPRMP, WECPP, WPSSM and WEMAM units.