In AJAX applications, using Spring security, handling session time out is a bit tricky. The problem is summarized here. Fortunately with DWR it is easy. DWR provides a way to handle errors, exceptions etc globally. Check  more on this here . As mentioned in the doc, you can use ‘textHtmlHandler’ to handle session time out. Here is the snippet,

dwr.engine.setTextHtmlHandler(function() {

I was upgrading my application from Spring 2.5.6 + Spring Security 2.0.x to the latest 3.0 RC releases. After modifying my Maven pom.xml files to accomodate for the new artifact naming conventions, I still couldn’t get my application context to load due to a SAX exception:

org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 37 in XML document from class path resource [security-config.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'security:authentication-provider'.

I found myself spending almost an hour trying to figure out what’s wrong with my configuration file. Was I missing a JAR file? no, everything seems to be in its right place (you WILL want to make sure that you’re including spring-security-config.jar, though!), Eclipse didn’t detect anything wrong with the config file. In my despair, I turned to Security Namespace Configuration chapter of the Spring Security 3 reference manual. There I noticed the following paragraph:

  <authentication-manager>
    <authentication-provider>
      <user-service>
        <user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
        <user name="bob" password="bobspassword" authorities="ROLE_USER" />
      </user-service>
    </authentication-provider>
  </authentication-manager>

Turning to my own configuration file, I saw this:

<security:authentication-provider user-service-ref="userService">
   <security:password-encoder ref="passwordEncoder">
      <security:salt-source user-property="username"/>
   </security:password-encoder>
</security:authentication-provider>

<security:authentication-manager alias="authenticationManager"/>

Apparently, while in Spring Security 2.x the authentication-provider tag used to be a root-level citizen, now it must live inside the authentication-manager definition.

I hope this will save some other folks some time when migrating to the 3.x Spring stack.

Yesterday I got Struts working in separate sub folders of my domain.
The reason for wanting to do this is so that Spring Security can require specific roles to access the contents of those folders – and this is how I did that.

The simple bit is protecting the folder, by adding the /admin URL pattern to the applicationContext.xml:

    <security:http>
        <security:intercept-url pattern="/login.jsp" filters="none" />
        <security:intercept-url pattern="/bare/**" filters="none" />
        <security:intercept-url pattern="/**" access="ROLE_USER" />
        <security:intercept-url pattern="/admin/**" access="ROLE_ADMIN"/>
        <security:form-login login-page='/login.jsp' default-target-url='/index.action' always-use-default-target='true' authentication-failure-url="/login.jsp?error=true" login-processing-url="/j_security_check" />
        <security:logout/>
        <!--<remember-me/>-->
    </security:http>

That’s all that’s needed to protect the folder, but it would be a pretty poor UI that invites users to do things that they aren’t allowed to do – so I wanted to change the links to the admin area to only be displayed if the user is in the ROLE_ADMIN role.
Firstly I had to add the Spring Security taglib to my project by changing the maven pom.xml:

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-taglibs</artifactId>
    <version>2.0.4</version>
</dependency>

Then in my jsp file (which happened to be the main decorator jsp file) I use the taglib:

<%@taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
...
                    <sec:authorize ifAllGranted="ROLE_ADMIN">
                        <li><a href="users-list.action">Users</a></li>
                    </sec:authorize>
...

Overview

My current project is using Liferay 5.2.3 as a Portal container and Spring Security 3 to secure portlets. We are not using Liferay’s built-in permission systems as we expect to deliver our portlets on many different portal platforms. Therefore we decided to use Spring Security, specifically the 3.0 version, as Spring 3 supports the JSR-286 specification.

In the RC1 version of Spring Security 3.0 (SS3), the Portlet jar was dropped that was available in v2.0.5 (spring-security-portlet-2.0.x.jar).  That leaves us with a dilemma when it comes to securing portlets using SS3.  To implement security in a portlet in a JSR-168 context one would have to re-implement everything in the portlet jar to use an interceptor based way of adding an Authentication to the SecurityContext.

Rather than taking that path, Spring 3 supports JSR-286 portlet specification which allows for portlet filters.  Since a common way to implement security is through security filters, a portlet filter method seems like a viable alternative.  There is one main issue with using portlet filters in that Spring cannot be used to create or inject dependencies into the portlet filter.  (Maybe it can but I wasn’t able to get it to work).

Thus, I’ve created a PortletSecurityFilter filter that more or less follows the SS3 security process used in the Servlet side implementation (AbstractAuthenticationProcessingFilter).

What’s the point of doing this?  Well, we need to deploy our portlet to multiple portal containers.  Thus, if we use SS3 we can easily control our portlet roles and not have to rely on the portal implementation.

Process

The whole point of this exercise is to push an Authentication into the SecurityContext for SS3 to use later when verifying Role information.  We’ll create a PortletSecurityFilter to accomplish this push.

Warning, many might think of this as a hack to fool SS3.  If you’re okay with that then keep reading.

Portlet Lifecycle Location

The first question is in what portlet lifecycle should the filter live?  That depends but the best location is during the Action Phase.  Adding the filter at this point sets the SecurityContext early enough for both the Action and Render phases meaning SS3 will work for both annotation driven security as well as jsp rendering security.

PortletSecurityFilter

Below is the code for the PortletSecurityFilter.  Note that you will have to implement your own AuthenticationDetailsSource and AuthenticationManager for this to work.  You’ll notice this also throws the Authentication token onto the PortletSession for use in later requests.

package com.your.package.name;

import java.io.IOException;

import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletException;
import javax.portlet.PortletSession;
import javax.portlet.filter.ActionFilter;
import javax.portlet.filter.FilterChain;
import javax.portlet.filter.FilterConfig;
import javax.portlet.filter.PortletFilter;

import org.apache.log4j.Logger;
import org.springframework.security.authentication.AuthenticationDetailsSource;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;

/**
 * Implements security behavior for Spring Security 3.0.  Adds an Authentication to the
 * SecurityContext and to the PortletSession.  Spring Security picks up the
 * Authentication when it meets annotated methods with the @Secured annotation.
 */
public class PortletSecurityFilter implements PortletFilter, ActionFilter {

    private static Logger logger = Logger.getLogger(PortletSecurityFilter.class);
    private static final String SECURITY_TOKEN = "SECURITY_TOKEN";

    private AuthenticationDetailsSource authenticationDetailsSource = new PortletAuthenticationDetailsSource();
    private AuthenticationManager authenticationManager = new PortletAuthenticationManager();

    @Override
    /**
     * Follow the Spring Security method for an AuthenticationFilter.
     * @see AbstractAuthenticationProcessingFilter
     */
    public void doFilter(ActionRequest request, ActionResponse response, FilterChain chain) throws IOException, PortletException {
	if(request.getUserPrincipal() == null) {
	    // If no UserPrincipal from Portal stop the chain here.
	    return;
	}
	Authentication auth = (Authentication) request.getPortletSession().getAttribute(SECURITY_TOKEN);
	if(auth == null) {
	    PreAuthenticatedAuthenticationToken authToken = new PreAuthenticatedAuthenticationToken(request.getUserPrincipal(), request.getRemoteUser());
	    setDetails(request, authToken);
	    auth = authenticationManager.authenticate(authToken);
	}

        if(auth.isAuthenticated()) {
	    successfulAuthentication(request, response, auth);
	    chain.doFilter(request, response);
	    return;
        }
    }

    /**
     * Default behavior for successful authentication.
     *
     *	Sets the successful Authentication object on the {@link  SecurityContextHolder}
     *	Sets the Authentication onto the PortletSession
     *
     *
     * @see AbstractAuthenticationProcessingFilter
     * @param authResult the object returned from the  attemptAuthentication method.
     */
    protected void successfulAuthentication(ActionRequest request, ActionResponse response,
            Authentication authResult) throws IOException, PortletException {

        if (logger.isDebugEnabled()) {
            logger.debug("Authentication success. Updating SecurityContextHolder to contain: " + authResult);
        }
        SecurityContextHolder.getContext().setAuthentication(authResult);

	PortletSession session = request.getPortletSession();
	session.setAttribute(SECURITY_TOKEN, authResult);
    }

    /**
     * Implementation of setDetails.
     *
     * @see UsernamePasswordAuthenticationFilter
     * @param request that an authentication request is being created for
     * @param authRequest the authentication request object that should have its details set
     */
    protected void setDetails(ActionRequest request, PreAuthenticatedAuthenticationToken authRequest) {
        authRequest.setDetails(authenticationDetailsSource.buildDetails(request));
    }

    @Override
    public void destroy() {
	System.out.println("Action filter destroy.");
    }

    @Override
    public void init(FilterConfig arg0) throws PortletException {
	System.out.println("Action filter init.");
    }
}

portlet.xml

The next step is to add this portlet filter to the portlet.xml file.  After you have declared your portlets, insert the following filter declaration:

Spring Security 3.0 Configuration

We have to enable SS3 by creating an applicationContext-security.xml file.  Basically, all we really have to do is enable secure annotations so if you don’t want to create a new file than just throw this into your current applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
 http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"

>
<security:global-method-security secured-annotations="enabled"/>
<security:authentication-manager alias="authenticationManager" />

</beans>

web.xml

Finally, if you added a new applicationContext than you’ll need to add that to your web.xml as a new contextConfigLocation.  That path will depend on where you put the file but one path might be:

/WEB-INF/context/applicationContext-security.xml

Add Security

Now all you need to do is add @Secured notations to your protected services or <security:authorize> tags to your jsp.  Assuming you created an AuthenticationManager that added the proper GrantedAuthorities than your security should now work.

I did this with Liferay portal v5.2.3 and successfully secured my portlet outside of Liferay.  Of course Liferay provides you with methods to expose your portlet permissions and administer them through Liferay control panel but we did not want to use that method.

In this post, as mentioned earlier, I will explain how my spring security 2.0.5 ACL (access control list) enhancement of the acegi security plugin 0.5.1 for Grails can be configured. My work bases on Stephan February’s solution for the 0.3 plugin version and acegi security. Apart from the implementation changes within the plugin, the plugin configuration only has minor changes. This is the reason why it is strongly advised to read Stephan’s blog post before continuing with this article as I will only mention major differences between the configuration of his plugin version and mine.

One difference in my version is the possibility of applying ACLs to method parameters (see 2.1 for an example):

For this to work custom voters have to be defined. A custom definition for the example of Stephan’s blog post looks as follows:

springSecACLVoters = [ //this map must be called 'springSecACLVoters'
			aclReportWriteVoter: [// custom beanName
			domainObjectClass: 'Report', // which type of domainclass will be secured
			roleName: 'ACL_REPORT_WRITE', // under which name the voter should be referenced later? Must start with 'ACL_'
			permissions: [ org.springframework.security.acls.domain.BasePermission.ADMINISTRATION,
			org.springframework.security.acls.domain.BasePermission.WRITE] // which concrete permissions will be checked if 'ACL_REPORT_WRITE' is specified
			],
			aclReportDeleteVoter: [
			domainObjectClass: 'Report',
			roleName: 'ACL_REPORT_DELETE',
			permissions: [ org.springframework.security.acls.domain.BasePermission.DELETE]
			]
	]

I added comments in the corresponding lines to describe the single options in detail. As you can see more than one voter can be defined as long as the map name is ’springSecACLVoters’ and the map is defined in SecurityConfig.groovy. Please note that if you do not need method parameter checking with ACLs you can simply omit the map configuration of voters.

Aside from the definition of custom voters and for applying ACLs to method parameters I added three other options to SecurityConfig.groovy:

useAcl = true // defaults to false, optional
aclClassIdentityQuery="SELECT @@IDENTITY" // this query is for MySQL, default is 'identity()' for hsqldb, optional
aclSidIdentityQuery="SELECT @@IDENTITY" // this query is for MySQL, default is 'identity()' for hsqldb, optional

If you want to use ACL extensions in general useAcl must be specified and set to “true”. Furthermore the enhancement uses the default JdbcMutableAclService implementation of Spring. For this reason you must have the possibility to change its identity queries (look here) to match your database. This can be done with the two corresponding options. The code snippet above shows working example values for hsqldb and MySQL.

Apart from feature and configuration changes the infrastructure of the plugin did also undergo a change since Stephan’s version: Because of the move of the ACL domain classes into the plugin domain directory the Gant target “CreateAclDomains” is no longer needed.

Therewith the description of the plugin configuration is complete. Some issues however remain to be done:

1. Calling of acl security functionality when using ‘run-app’ may raise a class not found exception which will not be raised when ‘run-war’ is used. I have to examine this more precisely and eventually file a bug report.
2. Test cases should be developed before a possible integration of the code into the main acegi security plugin tree. I am in contact with Burt Beckwith to get this working.
3. I have to upload the code to the GRAILSPLUGINS-723 JIRA task so that Burt Beckwith can decide on a possible integration into the acegi plugin version control tree. I will do this within the next week as I am very busy at the moment.

I hope this helps somebody
Feedback is greatly appreciated

Regards,
Phillip

Jump to other parts of this series:

• Integration of Spring Security into Grails – plugin approach 3
• Integration of Spring Security into Grails – plugin approach 2
• Integration of Spring Security into Grails – plugin approach 1
• Integration of Spring Security into Grails – Spring approach
• The Decision

This blog post describes problems and challenges when porting Stephan February’s solution from acegi security and acegiSecurityPlugin 0.3 to acegiSecurityPlugin 0.5.1 and Spring Security 2.0.5.

One issue was the fact that the whole API names changed from acegi security to spring security and that few api calls changed. Also the libraries had to be changed to work with Spring Security 2.0.5. In this case the grails maven project of the “Spring Way” mentioned before was of great help because maven’s calculated dependencies could simply be copied to the plugin. In this way all Java method.invocation errors went away magically . Regrettably the domain classes of Stephan’s solution could not be used any further because the whole schema had changed from Acegi security to Spring Security. That is why I decided to continue the usage of the standard JDBCMutableAclService of Spring in combination with a simple Spring bean which controls the deletion and creation of schemata with plain SQL commands.

Apart from these issues I learned to work with the Grails plugin and the Spring Security API and digged deeper into interceptor technology, expando meta classes, the Grails Bean Builder DSL and Spring Security as a whole.

I already mentioned that our Image Site makes use of very fine grained permission control for which reason it was not acceptable to us that Stephan’s solution did not support applying ACLs (Access Control Lists) to method parameters. For example this could turn out to be very useful if a user wants to delete an image and the deletion method is able to check whether the user has the correct permission on the given image object. This is the reason why I tried to implement applying ACLs to method parameters. Details of the implementation and arising problems will be subject to my next blog post.

Regards,
Phillip

Jump to other parts of this series:

• Integration of Spring Security into Grails – plugin approach 3
• Integration of Spring Security into Grails – plugin approach 2
• Integration of Spring Security into Grails – plugin approach 1
• Integration of Spring Security into Grails – Spring approach
• The Decision

In the last post of the security layer we decided to integrate Spring Domain Object Security the ‘Spring Way’ into our Grails application. This means that I tried to integrate the security concept without implementing or enhancing Grails or the acegi security plugin. Testable functionality was provided by the contact sample application of Spring Security. This was achieved by using a plain spring configuration file which was referenced from grails-app/config/spring/resources.xml

As we planned to use MySQL as our datasource several changes had to be done to the default configuration. First I needed to provide a different database schema which luckily could be found on Jim Bernatowicz’ Website. Apart from this the identity queries of Spring’s JdbcMutableAclService had to be adapted like this to support MySQL:

<bean id="aclService" class="org.springframework.security.acls.jdbc.JdbcMutableAclService">
    <constructor-arg ref="dataSource"/>
    <constructor-arg ref="lookupStrategy"/>
    <constructor-arg ref="aclCache"/>
    <property name="classIdentityQuery" value="SELECT @@IDENTITY"/>
    <property name="sidIdentityQuery" value="SELECT @@IDENTITY"/>
</bean>

Another problem I faced was that grails run:app threw errors when trying to find some security classes. Strange to say grails run:war worked perfectly. As we did not need grails:run-app functionality I decided to postpone this problem.

Apart from these issues this solution worked, but only for Java classes. An integration of Groovy classes into Spring like http://www.javabeat.net/articles/46-integrating-spring-and-groovy-1.html seemed heavy weighted and cumbersome to me. For this reason and with more Spring Security insight I decided to look deeper into the plugin approach of Stephan February and port it to the version 0.5.1 of the acegi-security plugin which will be part of the next blog post.

Regards,
Phillip

Jump to other parts of this series:

• Integration of Spring Security into Grails – plugin approach 3
• Integration of Spring Security into Grails – plugin approach 2
• Integration of Spring Security into Grails – plugin approach 1
• Integration of Spring Security into Grails – Spring approach
• The Decision

As you probably already know when reading this blog our project consists of building an image managing website based on Grails with fine grained access control.  Therefore we need access control not only on role level but on object level. This means that we have to define access rights for a dynamic set of roles each with a dynamic set of users. UserA e.g. may have ReadRights on ImageA but AdminRights on ImageB and UserB may have ReadRights on ImageB but AdminRights on ImageA. In this case a role based approach needs to define a role for each combination of permission and image. Because normal role based approaches are not developed for millions of roles we needed a different approach.

As we did not have enough time to implement a whole security system by ourself we decided to look into Spring Security which we had in mind because of the acegi security plugin for grails. Spring Security has several advantages which were for us in short:

• very flexible because security access can be defined on method level
• LDAP, RemeberMe and OpenID authentication
• long history (acegi security base) and thus a hopefully stable approach

Because of the use case mentioned in the beginning of this post the basic role based approach in “normal” Spring Security was not enough. Domain object security however seemed to be exactly what we needed.  Some reasons for using domain object security in our case are:

• For each domain object instance (eg picture number 23) it is possible to define an own ACL (Access Control List) which contains ACEs (Access Control Entries). This way each object instance has its own list of principals (users) which again have its own permissions (read, write, etc.)
• White and black ACEs are supported (either restrict or enhance permissions)
• Furthermore inheritance of ACLs is supported
• Performance -> “one of the main capabilities of the Spring Security ACL module is providing a high-performance way of retrieving ACLs”

The only problem seemed to be that the Acegi Security Plugin for Grails did not support domain object security and that is why we decided to integrate Spring Security the spring-way into grails. How I solved this will be mentioned in the next post.

Regards,

Phillip

Jump to other parts of this series:

• Integration of Spring Security into Grails – plugin approach 3
• Integration of Spring Security into Grails – plugin approach 2
• Integration of Spring Security into Grails – plugin approach 1
• Integration of Spring Security into Grails – Spring approach
• The Decision

Some days ago, I tried to integrate JSFUnit into a Spring based JSF application. I stumbled over the problem that the test crashed after a successful login. The stacktrace said, that the session was invalid.

The problem is that Spring Security invalidates the session after a successful login. Therefore I created a maven test profile which modified the spring security configuration to use the session-fixation-protection attribute of the http element.

<http auto-config="true" access-denied-page="/login.html" session-fixation-protection="none">

Links

http://static.springsource.org/spring-security/site/docs/2.0.x/reference/appendix-namespace.html#session-fixation-protection

A Spring Security week for me !

We have a Java Work Group in my work place, and last month I volunteered to do a presentation on Spring Security. Spring Security is a behemoth now. The most recent download (v 3.0.0M1) had the product documentation at 200+ pages. This session was just to give every one an overview. I used a number of sources to put this together, it’s all listed in the last slide. Ben Alex’s video presentation was extremely useful to understand the concepts…

This Post was my overdue subject, I wanted to help with a sample Application using Cairngorm, Spring BlazeDS Integration & Generic DAO.

This might be a heavy subject as it deals with many subjects:

• Cairngorm with UM Extensions , from Universal Mind
• Spring BlazeDS Integration, from Spring Source
• Spring, from Spring Source
• Hibernate
• Generic DAO, from IBM.
• Spring Security 2.0, using MySQL.

The Source is available at the link: cairnspring

How to use the source effectively?
it is simple, steps below:

1. Download, Source and Libs
2. Unzip both and import “CairnSpring”, to your Eclipse
3. Paste the lib files to “CairnSpring\WebContent\WEB-INF\lib” folder
4. Import the “db.sql” into your MySQL Db, (change mysql port to 3036, else can be configured to default in “CairnSpring\WebContent\WEB-INF\config\jdbc.properties” file)
5. In Eclipse, Window -> Preferences -> Web and XML -> XML Catalog -> Add User Specified Entries with below values
   Location : CairnSpring/WebContent/WEB-INF/config/spring-flex-1.0.xsd
   KeyType : Namespace Name
   Key : http://www.springframework.org/schema/flex/spring-flex-1.0.xsd
6. Start the Tomcat Server with CairnSpring instance (the server host and port can be configured in file “CairnSpring\flex_src\Server.properties”)

Ich arbeite mich zur Zeit ein wenig in verschiedene Sicherheitsframeworks für Java ein und bin gerade dabei Spring Security genauer unter die Lupe zu nehmen.

Allerdings gab es bereits Probleme beim Deployen der Beispielanwendung aus dem Quick Start Guide.

Der Tomcat Application Manager gab nachdem Installieren nur ein sehr hilfreiches: FEHLER – Anwendung mit Kontext Pfad /tutorial konnte nicht gestartet werden von sich.

Das Systemlog führte einen dann schon eher auf die richtige Fährte:

[ERROR,[/tutorial]] Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener java.security.AccessControlException: access denied (java.util.PropertyPermission tutorial.root read)
...
SEVERE: Error listenerStart
SEVERE: Context [/tutorial] startup failed due to previous errors

Interessanterweise landete die oberste Meldung nicht in den Tomcat Logs sondern nur in der /var/log/syslog. Die SEVERE Meldungen sind auch in den Tomcat Logs zu finden aber eben nicht annähernd so hilfreich.

Um nun nicht die ganze Beispielanwendung untersuchen und die einzelnen Regeln definieren zu müssen, reicht es für Testzwecke aus die Sicherheitsprüfung im Tomcat zu deaktivieren. Für den 5.5er Tomcat untern Debian, wird dies in der /etc/default/tomcat5.5 mit dem Eintrag TOMCAT5_SECURITY=no erreicht.

hth

It seems like there’s very little support (in terms of documentation) for using Spring Security in a Swing (or general Desktop) application. All the documentation I could find assumed that Spring Security was going to be used in a web application.

However, it’s very possible to use the security framework in a Swing application – a little custom code is required, but then, that is only to be expected!

Essentially what we did is create a LoginUtils class, which had an authenticate(username, password) method. This referenced the Spring AuthenticationProvider (we’re using a custom LDAP AuthenticationProvider, but you can use whichever suits your needs).

This is what the code looks like:

public Authentication authenticate( String username, String password )
 {
 UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken( username, password );

 Authentication auth = _authProvider.authenticate( token );
 if (null != auth)
 {
 SecurityContextHolder.getContext().setAuthentication( auth );

 _eventPublisher.publishEvent( new InteractiveAuthenticationSuccessEvent( auth, this.getClass() ) );

 return auth;
 }
 throw new BadCredentialsException( "null authentication" );
 }

You can then call this method from wherever you want in your application (for example, from a Login action) and your user will be logged in.

Both _authProvider and _eventPublisher are dependency-injected properties.

Notice the _eventPublisher.publish(…) call.  You do not need this if you have nothing listening out for those events. However, if you do not publish them then they will not be published, so it’s worthwhile doing – particularly if you’re writing a security framework!

The other important thing is – and this is something which caught me out first time round – is that the SecurityContextHolder by default uses a ThreadLocal pattern. For a Swing application you will want the Global pattern. Put this somewhere in your code (i.e. a static initializer, or your main method):

SecurityContextHolder.setStrategyName( SecurityContextHolder.MODE_GLOBAL );

This means that the Authentication object will be available to your entire application – if you don’t do this, objects on a different thread to the one you logged in on will not be able to ’see’ your credentials. For a while I couldn’t figure out why my Authentication object was coming back as null, until I realised!

Note: this post is application to Spring Security 2.0.4. At the time of writing, version 3 is only at milestone 1 so I have not tried it yet!

I have been reading spring security over the past few days and have come across a few link which will be helpful to you guys.

You will find some documentation which i will come up with on my blog soon.

I the mean while go through

http://static.springsource.org/spring-security/site/reference/pdf/springsecurity.pdf

http://grzegorzborkowski.blogspot.com/2008/10/spring-security-acl-very-basic-tutorial.html

So high school musical huh? Hahahaha.
Yesterday, after presenting our iBatis, Struts and Spring Frameworked CASE 3, our real project was presented to us. I, Joelle Ortiz and Pau Pablo are going to work with Miss Jem, SEER’s External Consultant in doing a Payroll System. They left us an impression that it’s quite a big project but we’re not expected to do the whole thing, just modules.

Since Miss Jem has been the client of one of the CS 192 groups under Ma’am Solamo, I think she expects a lot from us too. *pressure*

We were given another set of materials to study before we actually start on Monday.

CSS and AJAX (JQuery – http://jquery.com/)
Freemarker – http://www.freemarker.org/
jYMSG – http://jymsg9.sourceforge.net/
Spring Security (formerly ACEGI Security) – http://www.acegisecurity.org
Jasper Report interface with Java Servlets
(http://www.cise.ufl.edu/~otopsaka/CIS4301/ReportDemo/ReportFromJava.html)

I predict another challenging week next week (or next month!). I hope we get out of it alive! haha.

Ciao!

-D

Solution:

1.  Suppose the whole login page have 3 steps.

2. Make sure the first step page be accessible for all users, it’s just a simple page for user to input username and password.

3. Put all the remaining steps in to a webflow named loginprocess. after username/password is verified successfully, the page is navigated to the flow automatically.

4. Configure that loginprocess flow is only accessible by role ” ROLE_LOGIN”.

5. Add a customer filter at position: AUTHENTICATION_PROCESSING, override the onSuccessfulAuthentication() method, in this method, set the Authentication into session, and replace it with a temp authentication which only contains “ROLE_LOGIN” role

6. Now user can only access the loginprocess flow, in this flow, user will finish the remaining steps. Before we exit the flow, restore the authentication which is stored into session in the filter.

Some configuration and codes:

Security-config.xml

<security:http auto-config=“false” entry-point-ref=“myAuthenticationFilterEntryPoint” path-type=“ant”>

<security:logout logout-url=“/faces/login/logout” logout-success-url=“/faces/login/login.jspx” />

<security:intercept-url pattern=“/spring/login” access=“ROLE_LOGIN” /> <!–  this should be set before other flow –>

<security:intercept-url pattern=“/spring/**” access=“ROLE_USER” />

</security:http>

<security:authentication-manager alias=“authenticationManager” />

<security:authentication-provider user-service-ref=“securityManager”>

</security:authentication-provider>

<bean id=“myAuthenticationFilterEntryPoint” class=“com.trpoc.login.MyAuthenticationFilterEntryPoint”>

<property name=“loginFormUrl” value=“/faces/login/login.jspx” />

</bean>

<bean id=“authenticationProcessingFilter” class=“com.trpoc.login.MyAuthenticationFilter”>

<security:custom-filter position=“AUTHENTICATION_PROCESSING_FILTER” />

<property name=“authenticationManager” ref=“authenticationManager” />

<property name=“authenticationFailureUrl” value=“/faces/login/login.jspx” />

<property name=“defaultTargetUrl” value=“/spring/login” />

<property name=“filterProcessesUrl” value=“/login/j_spring_security_check” />

<property name=“alwaysUseDefaultTargetUrl” value=“true” />

</bean>

MyAuthenticationFilter

@Override

protected void onSuccessfulAuthentication(HttpServletRequest request,

HttpServletResponse response, Authentication authResult)

throws IOException {

System.out.println(” on successful login . “);

request.getSession().setAttribute(“AUTH”, SecurityContextHolder.getContext().getAuthentication());

SecurityContextHolder.getContext().setAuthentication(new Authentication(){

Authentication auth = SecurityContextHolder.getContext().getAuthentication();

public GrantedAuthority[] getAuthorities() {

// TODO Auto-generated method stub

GrantedAuthorityImpl granted = new GrantedAuthorityImpl(“ROLE_LOGIN”);

GrantedAuthority[] arr = {granted};

return arr;

}

/.. .. .. other codes omittd.

});

}

How to go to the requested URL after login,

Add a new flowHandler,

If access is denied, navigate to login page:

<error-page>

<error-code>403</error-code>

<location>/faces/login/login.jspx</location>

</error-page>

I had a requirement to be able to authenticate against a local windows machine’s user database or active directory. I dug and dug around forever trying to find a pre built solution but found nothing. So I wrote my own AuthenticationProvider

I used spring 2.0.3 and jcifs 1.3.2. Below are my related security beans:

    <beans:bean id="authenticationProvider"
            class="util.NtlmAuthenticationProvider">

        <custom-authentication-provider />
        <beans:property name="domain" value="domain"/>
        <beans:property name="hostname" value="hostname" />
        <beans:property name="userDetailsService" ref=userDetailsServiceImpl"/>
    </beans:bean>

The userDetailsService is a custom service that maps a “windows” user account to an account in the local database. This is where our “roles” are stored. Here is a snippet from the AuthenticationProvider:

public Authentication authenticate(Authentication authentication)
            throws AuthenticationException {
        try {
            log.info("Attempting to contact server: " + hostname);
            UniAddress domainController = UniAddress.getByName(hostname);
            NtlmPasswordAuthentication credentials =
                new NtlmPasswordAuthentication(domain, authentication.getName(),
                (String)authentication.getCredentials());

            log.info("Attempting log into domain: " + domain + " as " +
                    authentication.getName());

            SmbSession.logon(domainController, credentials);

            // populate a authentication object with authorities.
            UserDetails userDetails = userDetailsService.loadUserByUsername(
                (String)authentication.getPrincipal());

            UsernamePasswordAuthenticationToken auth = new
                    UsernamePasswordAuthenticationToken(authentication.getPrincipal(),
                    authentication.getCredentials(), userDetails.getAuthorities());

            return auth;

        } catch (UnknownHostException ex) {
            throw new AuthenticationServiceException(ex.getMessage());
        } catch (SmbAuthException ex) {
            throw new BadCredentialsException(ex.getMessage());
        } catch (SmbException ex) {
            throw new AuthenticationServiceException(ex.getMessage());
        }
    }
}

Instead of using a UserDetailsService you could instead just create a new token (as I did) and pass in some kind of authorities. Return that new object as that informs spring that the user has been authenticated and granted the appropriate authorities.

In spring security series parts 13 to 16, we revert back a bit to take a closer look at how spring security filters work. We clean up our configuration to allow us to have uri level security and method level security in place by part 16.

In subsequent parts of the series, we will continue on to look at the ACL feature of spring security.

part 13
part 14
part 15
part 16

In part 11 , we start looking at spring security’s ACL features. We create the schema and populate the database with test data as well as the ACL tables.

In part 12 , we add code that enables us to see the data entered into our Projects (domain) table and also the corresponding entries in our ACL tables.

see http://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-11

see http://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-12/

In part 9, we use exceptions mappings to control what is displayed when certain exceptions occur within the application.

see http://heraclitusonsoftware.wordpress.com/software-development/spring/simple-web-application-with-spring-security-part-9/