• View
• Edit
• History
• Print

AuthAndSession

IMPORTANT NOTE : as of v1.3.5, all this has been removed from WebFacets (I choose to remove it before people starts using it really). The ProfileLoaderFilter is not a very good answer to the authentication problems, it's very basic, so you should instead use Acegi if you want to have a really nice authentication mechanism back your facets ! Check out the docs here.

WebFacets includes an optional user session management module, which provides transparent mechanisms for automatically associating user profiles to incoming requests. Using this module allows to obtain the currnt profile from anywhere in the web tier and use it to retrieve/execute facets. The authentication process itself is up to you, the system only handles loading of a profile for an incoming request if possible (based on some cookie), and binds it as a request attribute.

NOTE

You can find examples of use in the ReflectionFacets? project (have a look at the demo).

This module has not been heavily tested, and should not be used in critical projects. For more advanced security stuff and integration with "J2EE security standards", have a look at the following pages :

• WebFacets and Container Managed Security (JAAS) (TODO)
• WebFacets and Acegi

The Problem

Many applications require authentication before the user can access all or parts of the WebApp. Most of the times, you have to enter a login/password or such stuff to access your private data, perform operations on them etc. Since this is pretty close to the whole profiles story (and also because I need this feature in an app I currently develop ;-P), I've chosen to include a small (and optional) authentication module to WebFacets.

Basically, it should allow stateless/long-term sessions, based on a long-term cookie mechanism. Of course, the authentication process itself is up to you, there is no restriction for this. The Authentication and Session features simply manages the cookies etc. for you, nothing more.

Using a filter : ProfileLoaderFiler

Cookie handling etc is done transparently via a new Servlet Filter (class ProfileLoaderFilter). Basically, its role is to :

• check if a cookie is there in the incoming request
  • if no cookie is found, then redirect to a login screen (customizable)
  • if the cookie is found, check if we already have a profile associated to it
    • if no profile exist for the cookie then redirect to a login screen (the session isn't valid on the server)
    • if a profile is found for the cookie, then bind it to the request and continue filter chain (the user has a session on the server : cookie + profile)

The filter is already functional, only a small bit of configuration has to be done (see below) to get it working.

The filter uses another component to store the (Cookie, profile) associations. This one has to implement the IProfilesAndCookies interface, and be declared in the Spring context (a basic "in-memory" implementation of it is provided - InMemoryProfilesAndCookies).

Filter Configuration

The ProfileLoaderFilter is configured via init parameters in the DD (web.xml). Here are the options :

• loginUrl : the URL of the login form (e.g. /auth/login.jsp) ;
• excludeList : a comma-separated list of path fragments - allows some paths to bypass authentication (e.g. "public area").

NOTE

You can also extend the filter if you need more than this...

Here below is an example web.xml fragment (from the ReflectionFacets? demo) :