JSF-Security Project

Introduction

The JSF security project is all about adding a layer of convenience to JSF when dealing with secured applications. The initial problem that the extension solves is to extend the JSF Expression Language (El) syntax to provide a new scope securityScope, which provides access to security related properties is and functions in a simple to use manner from the page. We believe that simple security is effective security. The ease of use of these EL extensions will empower any JSF programmer to secure the application without having to write code.

The extension is designed to be fully pluggable and can adapt to more or less any mechanism that is used for authentication and authorization that the programmer can reach from the FacesContext/Request/Session.

Downloading the Code

The homepage for the project is here on SourceForge. The code can be pulled directly from CVS or downloaded from here.

Using the EL Extensions

Available Expressions

jsf-security provides the following EL expressions for use within JSF. These either return a String, or a Boolean value in the case of the various checks. The EL expressions which take a roleList parameter expect a comma separated list of role names For instance: #{securityScope.userInRole['manager,administrator']}

Expression	Action
#{securityScope.securityEnabled}	Returns a Boolean indicating if security is currently enabled. Returns false if no security is installed, or the user is not yet authenticated
#{securityScope.remoteUser}	Returns the user name of the authenticated user
#{securityScope.authType}	Returns a string indicating the authentication type being used. With container security this will be BASIC, DIGEST etc. Other resolvers e.g. JAAS may return their own meaningful string values
#{securityScope.userInRole['roleList']}	Where roleList is a comma separated list of role names. Returns true if the user is in at least one of the roles. Returns false if the user is in none of the roles, or if the user is not currently authenticated
#{securityScope.userInAllRoles['roleList']}	Where roleList is a comma separated list of role names. Returns true if the user is in all of the roles. Returns false if the user is not in all of the roles, or if the user is not currently authenticated

Installing jsf-security

To install JSF-security:

Unpack the zip or tar file as selected from the options above and locate the jsf-security.jar file (it'll be in the /dist directory)
Include the jsf-security.jar file in your application classpath, for instance WEB-INF/lib
Err... that's it - apart from using the expressions in your app, and of course enabling container security

How does that work then?

The jsf_security.jar contains a faces-config.xml file in it's meta-inf directory. This faces config defines custom <variable-resolver> and <property-resolver> values as below.

  <application>
    <property-resolver>
      com.groundside.jsf.securityresolver.SecurityPropertyResolver
    </property-resolver>
    <variable-resolver>
      com.groundside.jsf.securityresolver.SecurityVariableResolver
    </variable-resolver>
  </application>

The magic of JSF means that this configuration is automatically merged into your overall faces config without you having to carry out any extra steps.

Custom Adapters

By default JSF-security hooks into J2EE container managed security using the J2EEContainerSecurityAttributeResolver. It is possible to plug in an alternative implementation here by a simple configuration change.

Developing a New Adapter

Adapters need to implement the com.groundside.jsf.securityresolver.adapter.AttributeResolver interface. This should be done by extending the AbstractAttributeResolver class. An adapter does not have to support the full range of EL functions defined above, and has to implement the isSupported() function to indicate which functions are actually supported (see Secure By Default).

Secure By Default

If you elect to define your own adapters you should adopt the principle of secure by default. That is, if you elect not to support a particular function, or if you encounter an error condition during evaluation, you should always return a negative outcome. It is better to deign access to a resource that the user should be able to see, rather than give them access to something they should not.

Using a New Adapter

Adapters are loaded into the Application scope and shared by all sessions using that application. Developers should take this into account in their designs.

To load an alternative resolver, the application developer simply needs to define the context parameter com.groundside.jsf.SECURITY_EL_RESOLVER in web.xml. This parameter needs to be set to the fully qualified classname of an adapter that implements the AttributeResolver interface.

$Id: index.html,v 1.4 2005/10/12 10:22:51 drmills Exp $