The Grails Spring Security plugin totally rocks. Even though Peter wrote a fantastic chapter on it for Grails in Action, I've always been a bit scared of it (based on some early bad experiences with the raw acegi codebase which *was* pretty insanely complex to get going).

Anyways, I've had cause to revisit Spring Security for a new client project, and had some tricky corner cases to solve. In particular, the app exposes a REST API that needs a special custom security provider. The client is issued an API key when they purchase the COTS product, and (basically) a hash of this key is remoted by a rich client during the authentication process so they can access backend services. However they can also access parts of the app using a normal browser interface with a user password and standard "remember me" features.

So the trick was supporting both a custom auth mechanism for certain URLs (eg /api/**) whilst maintaining usernames and passwords for the rest of the app. Turns out that it's all totally doable. First a disclaimer: I know next to nothing about Spring Security, so there is probably way better ways to accomplish this, so feel free to give feedback about how I could simplify all this so that future googlers can benefit. That aside, here's my crack.

Ok. To get all this custom stuff happening you'll need to implement a few things:

• A custom Authentication object to hold the credentials you scrape from the client's http POST
• A custom AuthenticationProvider which checks the credentials in that Authentication object match with the ones you've got stored against your backend database.
• A custom SpringSecurityFilter which slips into the request pipeline all /api/** URLs and fires when it finds some credentials to use. It will need to extract out the credentials into an Authentication object, then pass it off to the AuthenticationManager which will inturn fire you custom provider.
• Plenty of brain space to hold all that complexity...

Let's start with the easy stuff and define our custom Authentication object to hold our credentials. You really only need a custom one so that your AuthenticationProvider class can answer true to supportsClass(auth), and there's probably good adaptors I could have subclassed. Given I'm doing it all in Groovy, it's very concise to implement the entire interface anyways:

import org.springframework.security.*

class CustomAppTokenAuthentication implements Authentication {
	
	String name
	GrantedAuthority[] authorities
 	Object credentials
 	Object details
 	Object principal
 	boolean authenticated

}      

Ok. We have our "holder" for the credentials that the user is going to present. I'm going to populate the credentials and principal details from the incoming http request. It's the role of the SpringSecurityFilter to do that scraping, then fire off the AuthenticationManager's pipeline of AuthenticationProviders. Here's rough crack at a custom Filter:

import org.springframework.security.ui.*
import org.springframework.security.context.*
import org.springframework.beans.factory.*
import org.springframework.context.*
import javax.servlet.*
import javax.servlet.http.*

class CustomAppTokenFilter extends SpringSecurityFilter implements InitializingBean{
	
	def authenticationManager
	def customProvider
	
	void doFilterHttp(HttpServletRequest request, HttpServletResponse response, FilterChain chain) {
		
		if (SecurityContextHolder.getContext().getAuthentication() == null) {

			def userId = request.getParameter("userId")
			def apiKey = request.getParameter("apiKey")
			if ( userId && apiKey ) {
				
				def myAuth = new CustomAppTokenAuthentication(
						name: userId,
						credentials: apiKey,
						principal: userId,
						authenticated: true
				)
				
				myAuth = authenticationManager.authenticate(myAuth);
				if (myAuth) {
					println "Successfully Authenticated ${userId} in object ${myAuth}"
	
					// Store to SecurityContextHolder
					SecurityContextHolder.getContext().setAuthentication(myAuth);
				 }    
			}
		}
		chain.doFilter(request, response)
	}
	
	int getOrder() {
		return FilterChainOrder.REMEMBER_ME_FILTER
	}
	
	void afterPropertiesSet() {
		def providers = authenticationManager.providers
		providers.add(customProvider)
		authenticationManager.providers = providers
	}
}           

There's a little magic going on here in afterPropertiesSet() where I add my custom AuthenticationProvider (which is going to actually validate the token) to the existing pipeline of AuthenticationManager providers. I was hoping to do that via configuration, but couldn't find out how. Ideas?

With all that in place, the actual logic of firing the request is pretty straightforward. If there is a userId and apiKey coming in, and the user hasn't already been authenticated, you create your custom Authentication holder object for the credentials (contrary to what you might think, the authenticated: true attribute means "I should be inspected by an AutheticationProvider classes" NOT "the user has been authenticated with this credential"). Traps for young players.

The last piece of code we'll need is that AuthenticationProvider to actually validate the credential. That will need to look up the user's details in the security database. You can use the plugin's userDetailsService to do the heavy lifting of that one. Let's you look up the user in the database based on their user id, then gives you a handle to the underlying domain class to get any attributes you need. Here's my rough impl:

import org.springframework.security.*
import org.springframework.security.providers.*
import org.springframework.security.userdetails.*

class CustomAppTokenAuthenticationProvider implements AuthenticationProvider {
	
	def userDetailsService
	
	Authentication authenticate(Authentication customAuth) {
		def userDetails = userDetailsService.loadUserByUsername(customAuth.principal)
		if (userDetails?.domainClass?.apiKey == customAuth.credentials) {
			customAuth.authorities = userDetails.authorities
			return customAuth
		} else {
			return null
		}
	}
	
	boolean supports(Class authentication) {
		return CustomAppTokenAuthentication.class.isAssignableFrom(authentication)
	}
	
}

At this stage I'm just comparing that the cleartext API key's match. In the next round I'll use a Grails codec to do the actual .encodeAsCrazyHash algo that I'll need for the real crypto.

With all the code in place, we just need the config to wire it all together. Let's start with the spring bean definitions for /grails-app/conf/spring/resources.groovy:

import org.codehaus.groovy.grails.plugins.springsecurity.*
import au.com.bytecode.auth.*

beans = {

	if (AuthorizeTools.securityConfig.security.active) {
		
		customAppTokenFilter(CustomAppTokenFilter) {
			userDetailsService = ref("userDetailsService")
			authenticationManager = ref("authenticationManager")
			customProvider = ref("customAppTokenAppTokenAuthenticationProvider")
		}
	   
		customAppTokenAppTokenAuthenticationProvider(CustomAppTokenAuthenticationProvider) {
	   		userDetailsService = ref("userDetailsService")	
		}
		
	}
   
}          

I use the plugin's AuthorizeTools class just to check that the plugin is turned on in SecurityConfig.groovy. It's useful to be able to turn off security for some testing via that active = false flag, so I wanted to honour that setting.

The last piece of config is making sure the filter fires only for the /api/** URL Mapping. The SecurityConfig.groovy setup allow you to specify a map of URL to pipeline. I'm not sure which filters I need in addition to my custom one, so I just specify them all :-) -- you need some of them to persist your custom credential to the http session, for instance. And some to handle the anonymous user who don't submit a token (so that your standard @Secured annotations work on the target controller). Here's the extract:

   filterInvocationDefinitionSourceMap = [
    '/api/**': 'httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,customAppTokenFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor',
    '/**': 'JOINED_FILTERS',
	]    

The JOINED_FILTERS tag means "all the standard filters", but you can't seem to map "/api/**" to "customAppTokenFilter,JOINED_FILTERS" which could have been nice.

Phew! That was quite a journey! As I said, if you have better ways of simplifying this process, I'm all ears. At least here's a rough outline of how to hack together a custom authentication mechanism if your client needs one!

I've been having a ball playing with Gaelyk for developing Google App Engine applications in Groovy. One thing that Gaelyk lacks (for now! It's only 0.3.x) is any kind of layout engine like Sitemesh. No probs, just add then the Sitemesh filter to your web.xml and you're off, right?

    <filter>
        <filter-name>sitemesh</filter-name>
        <filter-class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>sitemesh</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Well that would be wonderful! However Sitemesh 2.4.1 has some integration points with JNDI that will bring you a world of hurt (Error 500) along with a description in your app engine logs. It will work locally, but fail once deployed. For later googlers, here's the strings from the appengine logs:

Error for /
java.lang.NoClassDefFoundError: javax.naming.InitialContext is a restricted class. Please see the Google App Engine developer's guide for more details.
	at com.google.apphosting.runtime.security.shared.stub.javax.naming.InitialContext.(InitialContext.java)
	at com.opensymphony.module.sitemesh.Factory.getEnvEntry(Factory.java:91)

Fortuntely some kind soul has documented the fix for that Factory class already. Followed those instructions and I was in business.

Now, onto some more DataStore experiments with Gaelyk...

I've got a new little hobby grails project that relies on a user's tweets to power its data collection, so I've been exploring using Twitter's oauth features to do away user accounts altogether. My little project is called "Twitter Until You're Fitter" and the idea is that I can tweet my weight "@tuyf 93kg" each week, and the app will pick up the value and graph it over time toward my goal weight (85kg). Given my current gym workload, that shouldn't be too far away :-)

For those of you who haven't played with oauth, it's one of those emerging "federated SSO" type protocols. You generate a signed request from your application and sent it off to twitter. Twitter asks the logged on user whether they wish to allow your application access their account. If they agree, twitter will send your application an oauth_verifier which you can use to logon as that user. Generating and processing all those tokens is easily handled by twitter4j

In order to get started, you first have to register your application with twitter, after which you'll be issued with a "consumer key" and a "consumer secret". You'll want to squirrel those away in your /grails-app/conf/Config.groovy to get access to them later:

twitter {
	oauth.consumer_key = 'd8sfsv9s0afs89v0sdesvs0'
	oauth.consumer_secret = 'lfsdDKSFjepfskvespfseruDFESilsfesfiseLFS=='
}

Next up we'll taked advantage of Grails 1.2's new dependency management gear, by adding twitter4j to our /grails-app/conf/BuildConfig.groovy

dependencies {
	build 'net.homeip.yusuke:twitter4j:2.0.10'
}

With our dependency in place, and our keys all set aside in config, it's time to generate a request to send the user off to twitter. I've setup a little TwitterService class to abstract some of the details:

class TwitterService {

    def generateRequestToken(twitter, callbackUrl) {	
		def consumerKey = ConfigurationHolder.config.twitter.oauth.consumer_key
		def consumerSecret = ConfigurationHolder.config.twitter.oauth.consumer_secret
		twitter.setOAuthConsumer(consumerKey, consumerSecret)
		def requestToken = twitter.getOAuthRequestToken(callbackUrl)
		return requestToken 
    }

}

I'm passing in the twitter4j object itself, since I'm planning on binding that object to the user's session, and using it to access their timeline. Now we just need a controller to generate the "redirect to login" feature of my application. Something like this should do it:

def requestLogin = {
	def twitterClient = new twitter4j.Twitter()	
	def returnUrl = g.createLink(controller: 'oauth', action: 'processLogin', absolute:true).toString()
	log.debug "Generating request with return url of [${returnUrl}]"
	def requestToken = twitterService.generateRequestToken(twitterClient, returnUrl)
	session.twitter = twitterClient
	session.requestToken = requestToken
	redirect(url:requestToken.getAuthorizationURL())
}

First we generate a link for our return url after authentication, then I call the TwitterService to generate my request token. The RequestToken class exposes a getAuthorizationURL() which returns the URL you need to send them off to. The user will be shown an authorisation screen like this:

Assuming they click "Allow", twitter will redirect back to your requested URL with a URL containing a oauth_verifier parameter. You can use that parameter to login to twitter as that user. Here's the action that processes the return URL from twitter:

def processLogin = {
	
	log.debug "Processing Login Return from Twitter"
	if (!session.requestToken) {
		redirect(action: 'requestLogin')
	} else {
		def accessToken = session.twitter.getOAuthAccessToken(session.requestToken, params.oauth_verifier)
		log.debug "Attempting validate..."
		def twitterUser = session.twitter.verifyCredentials()
		log.debug "Validate successful for ${twitterUser.screenName}"
		session.user = twitterUser
		redirect(action: 'displayDetails')
	}
}

That accessToken object turns out to be really important. If you squirrel away it's token and tokenSecret properties, you can login as the user any time you want with the redirect step (eg. a future session, cookie value, etc).

Phew! We've come a long way! We're now actually logged on as the user, now we just need a gsp to display some timeline details. Perhaps something like this:

<html>
	<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8">
		<title>Welcome ${session.user.name}</title>	
	</head>
	<body>
		<h1>Successful Login for ${session.user.name}</h1>
		<p>Your user handle is <a href="${session.user.getURL()}">@${session.user.screenName}</a></p>
		<p>Your icon is: <img src="${session.user.profileImageURL}"></p>
		<p>Your timeline:</p>
		<ul>
			<g:each in="${session.twitter.homeTimeline}" var="status" status='i'>
				<li class="${ (i % 2) ? 'odd' : 'even'}">
					<img src="${status.user.profileImageURL}"/> 
					${status.user.screenName} : ${status.text} </li>
			</g:each>
		</ul>
	</body>
</html>

Which should give us an output like this:

And our application is fully linked up! If the user has a look in their Twitter settings, they'll now see that our app has read-only access to their account. They can revoke that at any time (so we'll need some error checking to handle that down the track).

Once I've got a bit more of the app running, I'll get some source onto a public repo. Till then, I need to get ready for my Spin class..

I spent last Thursday with a bunch of the Queensland Groovy and Grails folk, hanging out at the Open Source Developers Conference. The day started with a super Groovy/Grails in the Enterprise talk from Bob Brown. After that was a great chance to meet Paul King from "Groovy in Action" fame:

I sat down and interviewed Paul about Groovy, Agile, GPars and Chickens, which will appear as part of episode 101 of the Grails podcast. I went to Paul's talk on Groovy Testing which we gave with Craig Smith. There's already a copy on slideshare, so check it out.

I also had a great chance to hang out with Steve Dalton and Lee Butts from Refactor. These guys work on the Grails S3 plugin and the Portlets plugin. Lee is also a Grails committed. We had lots of good chats about putting together an .au Groovy/Grails conf next year. Stay tuned - it's gonna be a very Groovy time in the Sun.

Finally, I had a chance to sit down with Luke Daley. Luke is behind the Grails Fixtures plugin, the LDAP plugin and the Grails Textmate plugin. Luke had some really good insights on developments in the Grails testing space, and it was also cool to meet another Grails Guitar player and Maven fan.

Big thanks to Steve Dalton at Refactor for talking me into coming and sorting out getting me in the door. It was a fantastic time and I can't wait for a local GroovyConf next year! It's gonna rock!

Interviews will be up on the Grails Podcast site later in the week. Stay tuned!

Continuing my fascination with all things mercurial, I've converted over a few of my googlecode projects (including groovyblogs and gravl). Google code has supported mercurial for a while, but it was initially piloted on just a few projects. These days the floodgates are open :-)

Google provides you with a Step-by-step guide on converting your project from Subversion to Mercurial. In the best case scenario, just do a "hg convert http://projectname.googlecode.com/svn hg-version-of-my-projectname" and you're in business. I tried this and the changesets took so long to pull from the remove svn repo, that I gave up after letting it run for a few hours.

Fortunately, some kind soul linked to this Antwerkz page which gives you a script for syncing your entire google svn repo to your local drive (just using standard svnsync, which isn't something I've played with before, so this trick might be old news to you).

With my whole svn repo mirrored locally, I could run hgconvert file://data/gravl.svn gravl.hg and a few seconds later I was done! Follow that up with a hg push https://gravl.googlecode.com/hg/ and we're up and running (with branches and full history!):

Great stuff. Really interested to see how I copy with a wholesale move to Hg. So far things are going great!