Implementing your own Spring Security authentication provider is easy with Spring Roo and Spring Data JPA

If you’re using Spring Roo and Spring Data JPA, then implementing your own Spring Security authentication provider in a Spring MVC application is pretty simple to do.

The first thing you need is an entity class that represents the user table in your database.  That’s the table where usernames and passwords reside.  Creating an entity with Roo is easy.  The first thing you have to do after you’ve created your entity is update it to implement Spring Security’s UserDetails interface.  Your resulting entity should look something like this.  This example is very basic.

@RooJavaBean
@RooToString
@RooJpaEntity(table = "USERS", versionField = "")
public class Person implements UserDetails {

    @Id
    private String username;

    private String password;

    public Collection<? extends GrantedAuthority> getAuthorities() {
        // your logic goes here
    }

    public boolean isAccountNonExpired() {
        // your logic goes here
    }

    public boolean isAccountNonLocked() {
        // your logic goes here
    }

    public boolean isCredentialsNonExpired() {
        // your logic goes here
    }

    public boolean isEnabled() {
        // your logic goes here
    }
}

As you can see, there’s not much to it.  Since we’re using Roo, the getters/setters for username and password are created for us.  The UserDetails interface requires us to have a getUsername() and getPassword() method, but since our private fields are called username and password, the required getters are generated by Roo.

Next we need a Person repository.  Creating this repository using Spring Roo is also very easy.  Using Spring Data JPA, the resulting repository interface looks like the following:

@RooJpaRepository(domainType = Person.class)
public interface PersonRepository {
}

Not much to it indeed.  Underneath the covers, the Roo generated ITD takes care of annotating our repository with @Repository and extending Spring Data JPA’s JpaRepository and JpaSpecificationExecutor interfaces.

Now that we have our UserDetails implementation and our Spring Data JPA repository, we need to implement Spring Security’s UserDetailsService interface.  This interface is quite simple in that you only need to implement one method called “loadUserByUsername”.  Simply injecting our newly created PersonRepository, we can very easily return the Person record we find using the username passed to “loadUserByUsername”.  Our repository returns Person instances, but the “loadUserByUsername” method returns an instance of UserDetails.  If you remember, our Person entity implements UserDetails, therefore returning a Person instance from the PersonRepository satisfies our UserDetailsService implementaiton.

@Service
public class MyUserDetailsService implements UserDetailsService {

    @Inject
    private PersonRepository personRepository;

    public UserDetails loadUserByUsername(String username)
        throws UsernameNotFoundException {

        return personRepository.findOne(username);
    }
}

Finally, all we have to do is update the Roo generated applicationContext-security.xml configuration file to use our custom UserDetailsService.

<authentication-manager alias="authenticationManager">
    <authentication-provider user-service-ref="myUserDetailService"/>
</authentication-manager>

That’s basically all there is to it.  In your application, you’ll have your own logic for loading the user’s granted authorities in the Person entity, so I didn’t go into any details there.

Tutorial: Unmarshalling SOAP Maps with JAXB into a List of Objects with a sprinkle of Spring Integration

Back in August, I posted about invoking web services with Spring Integration using XStream marshalling/unmarshalling.  That post was based on a project I had just finished at the time.  Recently, I had to make some changes to that project in order to implement another web service offered by the same provider.  This particular web service was returning a SOAP Map like before, however instead of a simple String key and String value, I had String keys and Map values.  With XStream, this seemed to be not so simple to implement.  After a bit of looking around, I decided to try and swap out XStream for JAXB.  I could have simply added JAXB and used it strictly on the new web service, but it sounded like more fun getting JAXB working across the application with a more sophisticated implementation than what I had done with XStream.  The other thing I wanted to do was unmarshal the Map as a List of Objects because for the most part, the key itself didn’t matter too much and there was a finite list of those keys.  Here’s a sample excerpt of XML being returned by the new web service.

<item>
    <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">mainkey</key>
    <value xsi:type="ns1:Map">
        <item>
            <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">key1</key>
            <value xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">value1</value>
        </item>
        <item>
            <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">key2</key>
            <value xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">value2</value>
        </item>
    </value>
</item>

Register your classes with the JAXB marshaller

In Spring, there’s the convenient OXM namespace for registering various types of XML marshallers.  Here’s how we register the JAXB annotated classes with the JAXB marshaller.

<oxm:jaxb2-marshaller id="jaxbMarshaller">
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.Request"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.StringResponse"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.MapResponse"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.util.StringDataItem"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.util.ArrayDataItem"/>
</oxm:jaxb2-marshaller>

The first thing I did was start writing an API for dealing with Maps that had String values, and then adapted it to handle Map values.

Unmarshalling simple Maps of String values into a List of Objects

This starts with a simple interface I created using Java Generics called DataItem<T>.  Now if anybody’s used JAXB, they know that when unmarshalling XML with JAXB, it can’t handle interfaces, so the objects and their properties need to be concrete implementations that can be instantiated.  Here is the DataItem<T> interface.

public interface DataItem<T> {
    public String getKey();

    public void setKey(String key);

    public T getValue();

    public void setValue(T value);
}

With this interface, we can specify the type of the Map’s value property.  The first implementation of this interface will be StringDataItem. Continue reading

Let’s work together!

Recently I’ve had the opportunity to collaborate on a project with someone that lives on the opposite side of the world.  In Australia to be precise.  It’s been a fun experience and it’s one I hope to repeat.  That being said, if you’re looking to hire a consultant on your current project, then don’t hesitate to contact me.

Head on over to my Developer for Hire page and take a look at my areas of expertise.

-Cheers!

String to Date Converter with Spring’s Conversion Service

Recently I was working on a Spring MVC project.  I had an @RequestMapping where one of the method’s @RequestParam arguments was a java.util.Date type.  I didn’t think much of it as I was writing the method, until when I tested the application, it threw an exception.  I quickly discovered that there’s no String to Date converter registered by default.

So in follow up to my last post where I showed you how to create a JSON collection String to List converter, I’m going to write this quick post to show you how to create a String to Date converter.

public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean {

	@Override
	protected void installFormatters(FormatterRegistry registry) {
		super.installFormatters(registry);
		registry.addConverter(getStringToDateConverter());
	}

	public Converter<String, Date> getStringToDateConverter() {
		return new Converter<String, Date>() {

			@Override
			public Date convert(String source) {
				SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
				try {
					return sdf.parse(source);
				} catch (ParseException e) {
					return null;
				}
			}
		};
	}
}

And that’s all there is to it.  Simply replace the SimpleDateFormat pattern with the pattern you need in your application, register the conversion service in your MVC config as mentioned in my previous post and voila!

Convert a JSON collection from String to List with Jackson using Spring’s Conversion Service

One of the nice features I’ve grown to love recently while using the Spring framework is the Spring conversion system.  Where the Spring conversion system shines in my opinion is in MVC applications.  When you create a Spring MVC application using annotation based configuration, you’ll have something like this in your servlet application context:

<mvc:annotation-driven/>

This line will register Spring’s default conversion service instance using org.springframework.format.support.FormattingConversionServiceFactoryBean which registers default converters and formatters.  This class can easily be extended to provide your own converters and formatter.  When you create a Spring MVC application using Spring Roo, this is done for you automatically.  What you end up with is something like this in your servlet application context:

<mvc:annotation-driven conversion-service="applicationConversionService"/>
<bean class="org.example.ApplicationConversionServiceFactoryBean" id="applicationConversionService"/>

What we’ve done here (or Roo if that’s what you’re using) is register a custom conversion service with id=”applicationConversionService”.  With a Roo managed project, it will manage an ITD with some converters for converting things like composite key types into JSON strings which it also encodes using Base64, which can be useful for referencing an entity ID by a composite key within your MVC application.

Let’s look at creating a custom converter for converting a JSON collection from a String into a List<Type> using Jackson.  Type being whatever type you want, be it your own or other.

public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean {

	private Log log = LogFactory.getLog(this.getClass());

	@Override
	protected void installFormatters(FormatterRegistry registry) {
		super.installFormatters(registry);
		registry.addConverter(getJSONCollectionToListConverter());
	}

	public Converter<String, List<MyType>> getJSONCollectionToListConverter() {
		return new Converter<String, List<MyType>>() {

			@Override
			public List<MyType> convert(String source) {
				ObjectMapper mapper = new ObjectMapper();
				List<MyType> myTypeList = null;
				try {
					myTypeList = mapper.readValue(source, new TypeReference<List<MyType>>() {});
				} catch (Exception e) {
					if(log.isErrorEnabled())
						log.error("Error converting JSON collection to List<MyType>.", e);
				}
				return myTypeList;
			}
		};
	}
}

As you can see, it’s quite simple to register your own converter.

Invoking web services with Spring Integration and XStream marshalling

Recently I had the opportunity to learn a bit about web services.  I had never worked with them before, but naturally my first thought was to use Spring Integration’s web services support because Spring Integration just makes everything so much simpler to do.

One of my main goals was keeping things as simple as possible.  That meant not having to get my hands too dirty converting objects to XML and XML to objects.  So I needed to find an XML marshalling solution that was just plain simple.  I didn’t have much experience with them in the past and I had tried DOM and SAX but found them too verbose.  So I looked at the ones that Spring Integration supported.  I finally settled on XStream because it’s annotation based configuration seemed so simple, and it was.

Before I go on, I should mention that I won’t be posting the full source of the project this tutorial is based on since it was for a client of mine.

Spring Integration configuration for starters

To begin, we’ll look at the Spring Integration configuration.  We’ll first register an XStream marshaller which will convert objects to XML and XML to objects.  Then I’ll define aliases to our objects as well as define which objects are annotated.  The aliases you define make it easier for the XStream marshaller to unmarshall XML responses into specific objects.  The alias or key is essentially the root element of the XML being unmarshalled.  Next the same classes are defined as a list for the annotated classes property.  Annotations that get added to elements of those classes assist XStream in making the XML output from marshalling look “prettier.”  More on that in the next section.

<beans:bean id="xstreamMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller">
	<beans:property name="aliases">
		<beans:props>
			<beans:prop key="request">com.example.Request</beans:prop>
			<beans:prop key="response">com.example.Response</beans:prop>
		</beans:props>
	</beans:property>
	<beans:property name="annotatedClasses">
		<beans:list>
			<beans:value>com.example.Request</beans:value>
			<beans:value>com.example.Response</beans:value>
		</beans:list>
	</beans:property>
</beans:bean>

<gateway id="requestGateway"
	default-request-channel="requestChannel"
	service-interface="com.example.RequestGateway"
	error-channel="errorChannel"/>

<chain input-channel="requestChannel">
	<ws:outbound-gateway uri="http://www.example.com/web-service"
		marshaller="xstreamMarshaller"/>
	
	<service-activator ref="responseServiceActivator"/>
</chain>

<chain input-channel="errorChannel" output-channel="mailChannel">
	<int-mail:header-enricher>
		<int-mail:subject value="${notification.subject}"/>
		<int-mail:to value="${notification.to}"/>
		<int-mail:from value="${notification.from}"/>
	</int-mail:header-enricher>
	
	<object-to-string-transformer/>
</chain>

<channel id="mailChannel"/>

<int-mail:outbound-channel-adapter channel="mailChannel" host="${smtp.server}"/>

Along with the XStream marshaller, I’ve defined a request gateway which will serve as the initial entry point for messages being sent to the web service.  The service interface is just that, a Java interface that defines what kind of message or more specific, what kind of message payload will be sent to the gateway.

public interface RequestGateway {

	public void invoke(Request request);
}

I’ve also defined a couple chains which simply encapsulate elements that share a common input channel but need to be invoked in specific order.  There’s the request channel which receives the messages from the request gateway, which is then sent off on the the <ws:outbound-gateway> element. That’s where the web service invocation actually takes place. Finally the error channel which I’ll use to send notification emails if an exception occurs.  When errors occur in downstream elements, they will flow up to the request gateway which will send them out on the error channel.

Continue reading

Using a different version of Dojo in a Spring Roo generated project

I haven’t yet come across a time when I actually needed to use a different version of Dojo in my own Roo generated project, but if you’re interested in knowing how to do it, follow along.  I actually saw the question asked in an old Spring forum post and decided I wanted to see for myself how it’s done.  The first thing you’ll need to do is download the version of Dojo you wish to use.  Currently the latest release is 1.6.0, so I’ve downloaded that.  If you don’t already have one, you will need a directory called “web-resources” below META-INF in the src/main/resources directory.  By default, a Roo generated app will create an <mvc:resources> element in the webmvc-config.xml file as follows:

<mvc:resources location="/, classpath:/META-INF/web-resources/" mapping="/resources/**"/>

This tells your application to serve up static content mapped with “/resources/**” to either the root of your application or the web-resources directory below META-INF on your application classpath.  The location attribute is a comma separated list of locations, so you can add more if you wish.  To keep things tidy, I’ve created a subfolder within web-resources, called “dojo-1.6.0″ in which I’ll keep the Dojo toolkit.  Here’s what things should look like at this point.

Continue reading