The security framework provides the means to authenticate users and control access to restricted resources based on user roles. Here, the authorization rules extend beyond those provided by the J2EE platform. Also, it should be possible to implement security aware functionality without being dependent on J2EE specific APIs. Hence a security framework is provided.



  1. It shall be possible to restrict the viewing and/or modification of content to autheticated users.
  2. It shall be possible to log out of the apolication.
  3. Once a user is authenticated, the user identity shall be available in all parts of the application.
  4. It shall not be possible to view or modify content that a user is not allowed to by constructing certain HTTP requests.
  5. It shall be possible for some parts of the application to be publicly accessible while others can only be viewed by authenticated users.
  6. It shall be possible to integrate seamlessly with standard J2EE security.
  7. It shall be possible to use security APIs without depending on J2EE-specific APIs.


  1. It shall be possible to check whether an operation on a specific resource is allowed or not.
  2. Authorization shall at least support authorization based on group and resource where any user can be a member of one or more groups.
  3. The authorization framework shall at least support resources identified by a path and a type, where one authorization rule can explicitly grant or deny access to a set of resources to a single group for all resources below a given path.
  4. The authorization framework shall at least support the following operations: reading a resource, modifying a resource, and deleting a resource.
  5. The authorization framework shall be extendible with new types of resources and operations.


We assume that the application server and database environments are such that information cannot be altered by third parties.


We assume that the application server and database environments are configured and secured appropriately to guarantee confidentiality.


To cover the authentication requirements the following design principles are used:

  • JAAS authentication is used. As a result, after authentication, the JAAS APIs can be used to obtain the user identity everywhere in the application without needing to pass information through the argument list.
  • A servlet filter is used which filters all incoming requests to the application and which logs in using JAAS (and logs out after the the request is processed), provided user credentials are available. The user credentials are stored in the HTTP session.
  • Form based authentication is used obtain control in how to format the login page and to provide good integration with the application server environment.
  • J2EE declarative security is used to control access to pages. Currently, with Tapestry 3, no control over the URL space is possible so that currently the entire Web application requires an authenticated user. This restriction will be removed once we migrate to Tapestry 4 that allows more control over the URL space.
  • A ProtectedPage, base class is used for all pages that can only be viewed by authenticated users which extends the Tapestry BasePage class and checks whether the user is logged in. If not an error is generated.
  • Using a tapestry component, all pages will show a logout link in case the user is logged in. The logout will remove the user credentials from the session and will therefore logout.


Package Overview

The authentication packages are org.wamblee.security.servlet and org.wamblee.security.tapestry. The first package contains general security related functionality for use in web applications. The tapestry package contains specific security related support for the Tapestry web application. An authorization framework is contained in the org.wamblee.security.authorization package. Security depends on user management.

Package overview.

Authentication for the Web App.: Package

The AuthenticationFilter is a servlet filter that takes care of executing requests as an authenticated Subject using Subject.doAs() when a Subject is available. The Subject is made available in the application server as part of the FORM based authentication. To retrieve the authenticated subject, the SubjectLocator is used. This interface has one implementation for JBoss that retrieves the Subject from the JBoss security manager. This retrieval is done using OGNL (Object Graph Navigation Language) to avoid dependencies on JBoss-specific classes in the code.

Authentication filter.

Authentication in Tapestry: Package

A subclass of BasePage called ProtectedPage is provided that represents pages that require an authenticated used. This class implements the PageValidateListener interface from Tapestry so that its pageValidate() method is called before the page is rendered. The pageValidate() method checks whether the user is logged in and if not throws an exception. This design is possible since J2EE declarative security is used in such a way that this situation can only occur in case of programming and/or configuration errors. .

Security in Tapestry.

Authorization: Resource and Operation

There is no special class to represent a resource. The resource on which some operation is requested (or a representation of this resource) is used instead. The framework defines four operations for reading, writing, creation, and deletion, as well as one operation type which groups these four.

Representation of an operation on a resource.

Authorization: Result of authorization

The result of an authorization is defined as an enumerated type with the values:

  • GRANTED: the operation is granted.
  • DENIED: the operation is denied.
  • UNDECIDED: when an authorization rule applies to the resource type but does not match.
  • UNSUPPORTED_RESOURCE: When an authorization rule does not apply to the specified resource type.
Result of authorization.

Authorization: Authorization Rule

The basic ingredient for the authorization framework is a single authorization rule. To check whether an operation is allowed on a resource, a number of rules are consulted in a specified order using their isAllowed() method. A rule also provides an interface for getting the supported resource types to which it applies. In case a rule applies it returns GRANTED or DENIED, otherwise, it returns UNDECIDED or UNSUPPORTED_RESOURCE. An authorization rule must be persistent.

Authorization rule.

The UrlAuthorizationRule is a fully parametrized abstract base class for other concrete rule implementations. It is constructed with a number of rules to determine if a rule matches, as well as a result to return in case the rule matches. Specifically, for a rule to apply, the following conditions must hold:

  • The type of resource must be a subclass of a specified class.
  • The user must match as specified by the UserCondition.
  • The path of the resource must match as specified by the PathCondition.
  • The operation on the resource must match as specified by the OperationCondition.

To use the UrlAuthorizationRule, a subclass must be implemented which implements the getResourcePath() method to return the path for a given resource.

User condition.

Two types of user conditions are implemented: AnyUserCondition which matches any user and GroupUserCondition which matches in case the user is part of a specified group.

Path condition.

Only one type of OperationCondition is implemented which checks if the operation is a subclass of a given operation type.

Operation condition.

Authorization Service

The authorization service provides the interface for authorization (isAllowed()) as well as methods for managing the authorization rules. The service works by checking each authorization rule in turn until one rule returns GRANTED or DENIED. If none of the rules match, then the service returns the result DENIED. The service therefore never returns any other result than GRANTED or DENIED.

Authorization service.

The implementation of an authorization service that uses persistent storage for storing the rules is done in two steps:

  • DefaultAuthorizationService is a basic POJO which implements the logic for authorization. It uses the UserAccessor to obtain the currently logged in user information from user management and security.
  • PersistentAuthorizationService which decorates the service and takes care of caching, persisting, and regularly updating the authorization info w.r.t. persistent storage. This is required as a performance optimzation.

This design separates the logic for implementation of the authorization rules from that of persistence and caching.


Authentication Filter Login

The authentication filter intercepts all requests to the web application. In case no user identity is available the request is simply forwarded. Otherwise, the user is logged in using JAAS and the request is forwarded using Subject.doAs().

Authentication filter and login.

Accessing a Protected Page

The sequence diagram shows a scenario where an attempt is made to access a protected page. It obtains the Subject using JAAS API calls and if there is no subject, an exception is thrown.

Accessing a protected page.

Authorizing an operation on a resource

To check whether an operation is allowed on a resource, the authorization service checks each rule in order until one rule returns GRANTED or DENIED. Thus the first rule that applies determines the result. If no rules match, DENIED is returned.

Authorizing an operation on a resource.

Authorization logic of

The UrlAuthorizationRule works by first checking all conditions to see if it applies. If it applies it returns the configured authorization result. Otherwise, it returns UNDECIDED (or UNSUPPORTED_RESOURCE) if it does not apply to the specified resource.

URL authorization rule.

Design Rules

  • To use the UrlAuthorizationRule, the user must provide a subclass that implements the getResourcePath() method to obtain the path to the resource.