Skip to content

OpenSSO and the Quest for the Holy Grails

June 12, 2009


With apologies to Monty Python Fans….

Did you ever want to use OpenSSO with Grails? Now you can!

The astute reader of this blog (that’s you Mom!) will know that you can protect Spring applications with the OpenSSO Spring 2 Security provider

As it turns out, Grails has a plugin that let’s you use Spring Security for authentication and authorization. If we marry this plugin with the provider, we ought to be able to use OpenSSO with Grails. Don’t ya love it when a plan comes together?

To get started, you will need to download the OpenSSO Grails plugin from here, and install it using the grails install-plugin command. 

To give credit where credit is due, the OpenSSO plugin is largely based on the work of the Spring Security Grails plugin. The original authors are T.Yamamoto, Hatian Sun, and Burt Beckwith. My humble contribution is the OpenSSO glue code and the integration of the OpenSSO Spring Security extension. For reasons that I won’t go into here, I elected to create a separate version of the plugin specifically for OpenSSO (ping me if you want the details).

I would also suggest downloading this sample Grails application that demonstrates how to use the plugin in a Grails Application.

 Yes. But what does it do?

 The OpenSSO plugin provides the following functionality to a Grails Application:

Single Sign On (SSO) with OpenSSO:

The plugin delegates logon to OpenSSO. If the user has previously authenticated to OpenSSO, the browser will present a cookie containing the SSO token. Providing the session is still valid, the user will be transparently signed on the Grails application.  If the user does not have a token, the plugin redirects them to OpenSSO. After succesfull authentication, the user is then redirected back to the application.  

This means that your application is not responsible for authentication. In fact, there are no logon or password screens to maintain as OpenSSO handles it for you. One of the nice benefits of this approach is that the authentication method and strength is factored out of the application. Want to use one time passwords? How about AD?  No problem – just configure the authentication chain in OpenSSO. No changes to your application.  

URL Policy Enforcement

 The plugin provides for enforcement of URL policy using OpenSSO.  This works quite nicely with Grails and it’s "REST" like structure for controller URLs. So we can (for example), allow one group of users to /list controller items, and another group of users to /update or /create new items. Custom controller methods (beyond the standard CRUD methods) can use the same mechanism. 

Note that this largely eliminates the need for the @Secured annotations in Grails code – since the same effect can be implemented using URL policy. This externalizes the authorization into OpenSSO – which is generally a good thing. 

Controller Security Methods  

 The plugin injects several security methods into your controllers to provide access to the security context. Here is sampling of methods available to controllers:

isUserInRole("ROLE_MANAGER")   - true if a user belongs to the specified Role
isUserLogon()	 -  true if the user is logged on (authenticated)
getGrantedAuthorities() - returns an array of Strings representing the Granted Authorities (Spring terminology for role names) that this user posseses.

GSP Tags

The plugin provides access to GSP security tags. These tags can be used in your Grails view to drive the display based on the user’s role or authentication status.

For example:

<g:ifNotGranted role="ROLE_MANAGERS">You are not a Manager!!! </g:ifNotGranted>

<g:ifAllGranted role="ROLE_MANAGERS">Congrats. You are a manager!</g:ifAllGranted>

Time permitting, I may create a cookbook on how to get this all working with the sample application. Drop me a line if you are interested.

PS. Just what is the wing speed velocity of swallow?  

  1. June 12, 2009 4:16 pm

    Cool stuff. Even if you want to host the source and/or plugin zip yourself you should create a plugin doc page at Your plugin script’s doc link is currently set to which doesn’t exist.
    You should probably rename/repackage the source you borrowed from the Spring Security plugin. If users install both plugins there will be conflicts; I’m not sure which version Grails would choose or if it’d work at all. There are other issues with using both plugins – you’re using the same bean names – but the common code is definitely a problem.

  2. June 12, 2009 5:30 pm

    Hi Burt
    Thanks for your comments. If there is sufficient interest I will most definitely put this up on
    Regarding the re-packaging of the source – do you think that people would use both plugins at the same time?
    I don’t know if it is possible, but I would like to see the Spring Security plugin re-factored to a base plugin plus separate extensions (.e.g. for CAS, OpenId, OpenSSO). I started with the approach of adding OpenSSO to the existing plugin – but it quickly got messy. The plugin will get pretty hefty if every authentication technology is included in the distribution.
    BTW – thanks for your great work on the original plugin. You made all of this possible!

  3. Larry permalink
    June 19, 2009 2:20 am

    Very cool stuff!!! Thank you Warren!

Comments are closed.

%d bloggers like this: