How to do rule-based authorization with Spring Security in Grails?

Question

Spring Security is great for doing role-based authorization, but it seems to fall short when it comes to rule-based authorization. Sure, there are ways to do it via SpEL, but going that route seems to lock your authorization logic inside the annotations when it would be much better to pull that logic out into a service so that multiple places can use the same logic.

There seem to be some ways to go about adding in your own SpEL expressions, but noting is particularly clear, and even those that make sense to me seem to fall short. I would think, given how flexible Groovy is, that there must be some way to not have to hard-code the dependencies together, but to have the security rules (or SpEL extensions) picked up at run-time.

While not ideal, even something as seemingly simple as defining all of the desired new rules and injecting the as mixins (ie. SecurityExpressionRoot.mixin MyRule1) would be a good start, but that doesn't seem to work.

Does anyone know of an example that does this? If not, how might I go about doing this myself?

---

One (simplified) example : A user can only take a particular action (ie. execute a service method) with an object if 3 of 4 fields have values over a particular threshold, but only if the object is less than 3 days old:

class MyRule {

    boolean canTakeAction(Person person, MyThing myThing) {
        int numFieldsWithValues = 0
        if (myThing.field1 != null) { numFieldsWithValues++ }
        if (myThing.field2 != null) { numFieldsWithValues++ }
        if (myThing.field3 != null) { numFieldsWithValues++ }
        if (myThing.field4 != null) { numFieldsWithValues++ }

        return (numFieldsWithValues > 3) && (ageInDays(myThing) < 3)
    }

    int ageInDays(MyThing myThing) {
        ...
    }
}

And that is one of the simpler rules.

Answer 1

Role based authorization is the easiest but less flexible way. The contrast to this is the Spring security ACL system. ACLs are let you define exaclty who is allowed to do what on which object at runtime. On the other side this requires a much more complicated setup. There is also a grails plugin for this.

The way of using annotions with SpEL expressions is somewhere between these both alternatives. They are more flexible than simple roles and easier than ACLs. If you are looking for an introduction to method security in Grails maybe this blog post I wrote some time ago can help you.

Answer 2

You can manage your rule in Requestmap, which provides dynamic configuration capability.

For instance, define security type as requestmap in config.groovy first:

grails.plugins.springsecurity.securityConfigType = "Requestmap"

Then you may have Requestmap domain class similar to User and Role, like this:

package com.app.auth
class Requestmap {

    String url
    String configAttribute

    static mapping = {
        cache true
    }

    static constraints = {
        url blank: false
        configAttribute blank: false
    }
}

Now since User, Role, and Reqestmap are all persisted in database, you can easily change your rules by CRUD actions in some controller without need to redeploy or restart your service. Like this:

class RequestmapController {

def springSecurityService

...

def save = { 
    def requestmapInstance = new Requestmap(params) 
    if (!requestmapInstance.save(flush: true)) { 
        render view: 'create', model: [requestmapInstance: requestmapInstance] 
        return 
    }

    springSecurityService.clearCachedRequestmaps()     //This is important: to refresh the requestmap. Without it the rules remain unchanged.
    flash.message = "${message(code: 'default.created.message', args: [message(code: 'requestmap.label', default: 'Requestmap'), requestmapInstance.id])}" 
    redirect action: show, id: requestmapInstance.id 
    } 
}

In the view layer, you can manage your menus, buttons, and other elements need authorization by using spring security tag like:

<sec:access url="foo/bar">
    <li><g:link class="list" controller="foo" action="bar">Bar action</g:link></li>
</sec:access>

Therefore, the views are also comply with the authorization rule.

Furthermore, there is a Hierarchical Roles feature which can be leveraged to reduce clutter in your request mappings.

Answer 3

From the example you posted, GContracts might be what you're looking for. You'd just have to figure out how to access the Principal when running a GContract closure, but that might be just as simple as passing it as a parameter to the contracted method.