Permission-Based Authorization

With Spring Security 2.0

By Richard Freedman
Overview
By default, Spring Security 2.0 (formerly ACEGI) bases
it's authorization decisions on user roles. In some
situations, it is preferable to base authorizations on
fine-grained permissions, and to treat roles as “groups
of permissions”.

This approach allows more flexibility in managing the

authorities, for example, allowing an individual
permission to be granted to, or taken away from one or
more roles, administratively, without the need for any
code changes, and without the need to update
individual user credentials.
The Sample Applications
Two sample applications accompany this whitepaper. The first
example is a very basic web application using “stock” Spring
Security 2.0 to secure access to it's URLs. This whitepaper will
describe the changes required to arrive at the second example,
which uses permissions instead of roles.

System Requirements
The requirements for running the included examples are an
installed JDK (1.5 or later), and an installation of Maven. If you
need to install Maven, see http://maven.apache.org/

Each of the sample applications includes a pom.xml, which is

used by Maven to build the application. If you wish to open one
of the projects in Eclipse, navigate to the project directory in your
shell, and type mvn eclipse:eclipse This will generate an Eclipse
compatible .project file.

The Maven project includes an embedded Jetty server, so you

don't need Tomcat or any other server to run the samples. For
each sample, simply type mvn jetty:run at the command line, and
then open http://localhost:8080 in your web browser.

2
 Role-Based Security Example
The Role-Based Security example is the starting point, and uses
a straightforward, “standard” Spring Security configuration. The
example includes no Java code, just configuration and JSP
pages. There are three distinct areas of the application - “public”
(available to all clients, whether logged in or not), “secured”
(available to all logged-in users), and “admin” (available only to
administrators).

Two roles are created, ROLE_USER and ROLE_ADMIN, along

with one user in each role (“user”, and “admin”) - see the
schema.sql file in the project for the requisite SQL Insert
statements.

The three areas of the application are protected via the following
Spring Security configuration in applicationContext-security.xml:

<http auto-config='true'>

<anonymous/>

<intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>

<intercept-url pattern="/*.jsp" access="IS_AUTHENTICATED_ANONYMOUSLY"/>

<intercept-url pattern="/public/**"
access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<intercept-url pattern="/secure/**" access="ROLE_USER, ROLE_ADMIN"/
>
<intercept-url pattern="/admin/**" access="ROLE_ADMIN"/>

<intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />

<form-login
login-page='/login.jsp'
authentication-failure-url="/login.jsp?error=true"
/>
</http>

3
Links appropriate to the user's role are created in the JSP pages
using the Spring Security taglibs. For instance,

<sec:authorize ifAllGranted="ROLE_ADMIN">
<p>You are logged in as an admin</p>
<a href="<c:url value='/public'/>">public folder</a>
<br/>
<a href="<c:url value='/secure'/>">secure folder</a>
<br/>
<a href="<c:url value='/admin'/>">admin folder</a>
<br/>
</sec:authorize>

Converting to Permission-Based Security

Database Schema and Data

The most obvious change to the application to support
permission-based security is the database schema. The schema
is changed so that instead of a single table of user authorities,
users belong to “groups”, and the user authorities are replaced
with group authorities.

In this scenario, the groups are the roles, and the authorities are
the permissions. We create the same roles as before,
ROLE_USER and ROLE_ADMIN, but this time in the groups
table. We also create permissions for these roles – the
ROLE_USER role gets the permission
PERM_ACCESS_SECURED (permission to access “secured”
URLs), and the ROLE_ADMIN role gets this permission and the
PERM_ACCESS_ADMIN permission (permission to access
“admin” URLs). See the schema.sql file in the permission-based
security example for the modified schema and insert statements.

4
Configuration XML
There are three changes required in
applicationContext-security.xml to effect the change to
permission-based security.

The first change is to tell Spring Security that we're using the
new schema with “groups”. We add the following properties to
the “userDetailsManager” bean:

<!-- enable lookup of permissions via user's group -->

<beans:property name="enableGroups" value="true"/>

<!-- disable direct lookup of user's permissions (require lookup via group) -->
<beans:property name="enableAuthorities" value="false"/>

This is the only configuration change that is strictly required.

However, by default, Spring Security requires that authority
names start with “ROLE_”. If you name your permissions this
way, you have noting further to do. However, it is likely that, as in
our example, you will want to prefix your permission names with
“PERM_”, or something similar.

5
To change the authority name prefix, we have to configure a
number of beans, so that we can specify the prefix, including an
accessDecisionManager bean, a roleVoter bean, and an
authenticatedVoter bean. The authority name prefix is set as the
“rolePrefix” property of the roleVoter bean. See the
applicationContext-security.xml file for details.

Don't be confused by the bean and property names – the

roleVoter will be voting on permissions, and the rolePrefix
property is really the permission prefix. These names are just
holdovers from before permission-based security existed.

Finally, the http security configuration (at the top of

applicationContext-security.xml) must be configured to use the
new accessDecisionManager bean – this is done by adding the
attribute: access-decision-manager-ref="accessDecisionManager".

JSP Taglibs
Now that the rest of the application has been converted to
permission-based security, the JSPs must be updated to check
for the permissions instead of the roles. So, for instance, the link
to the “admin” page should be changed from

<sec:authorize ifAllGranted="ROLE_ADMIN"> to

<sec:authorize ifAllGranted="PERM_ACCESS_ADMIN">

6
Summary
Spring Security 2.0 provides the ability, with just a few
configuration changes, to use fine-grained, permission-based
authorization. This fits better with most corporate security
policies, makes authorization management much easier, and
abstracts application code from individual user rights.

About the Author

Richard Freedman is a Consultant at Chariot Solutions. He has
over twenty years of Software Development experience, and has
worked with Java technologies since 1998.

About Chariot Solutions, LLC

Chariot Solutions is an IT consulting firm specializing in
application development and systems integration using Java and
open source technologies. Chariot consultants include some of
the top software architects in the country, all of whom possess a
rare combination of deep technical expertise, applied industry
knowledge and a genuine love for what they do. Chariot's
consulting team has made the company the optimal partner to
design, develop, deploy, integrate, support and tune mission-
critical systems for companies of all sizes. Visit Chariot on the
web at www.chariotsolutions.com.