Comments on: Production-Grade Acegi Security for Grails

By: Ola Bildtsen :: Production-Grade SpringSecurity Plugin for Grails

Ola Bildtsen :: Production-Grade SpringSecurity Plugin for Grails — Wed, 12 Nov 2008 21:54:14 +0000

[...] my previous post “Production-Grade Acegi Security for Grails“, readers correctly commented that the underlying technology for the plugin was rather [...]

By: emplify

emplify — Wed, 05 Nov 2008 21:40:10 +0000

Links – 06.11.2008…

Hatte ich noch gar nicht erwähnt: Am 1.11.2008 ist ja das neue GmbH-Recht in Kraft getreten.Ein ganz interessanter Artikel, auf den ich sehr gerne verlinke auf Kooptech: Wie macht man auf vernachlässigte Themen und Nachrichten aufmerksam? Gerade im…

By: Ted Naleid

Ted Naleid — Wed, 05 Nov 2008 02:29:02 +0000

Regarding Carsten's point, the upcoming version of GORM in Grails 1.1 will have the ability to return objects that only have read-only access. This could likely be leveraged to do what Carsten is looking for.

By: Ola Bildtsen

Ola Bildtsen — Tue, 04 Nov 2008 23:10:25 +0000

Thanks for the comments, everybody, I really appreciate it. I realize I’m stuck in the past with an old version of the plugin and Acegi, and should start using SpringSecurity. The guts of this implementation was created when those things (the old version of the standard plugin and Acegi) was the latest.

What I was trying to focus on was a new approach to flexibility, maintainablility, and authorization, to establish the authorization mappings in conventional places. The actual guts of the Acegi implementation is less important to me.

As to Carsten’s question, I haven’t really considered property-level security directly on domain classes. That seems a little too fine-grained to me, but perhaps that could be useful. The permission approach I’m hinting at is more geared to linking authorizations/roles to certain pieces of UI functionality. But on the whole, security/authorization (in my implementation) lives on a controller-method level. So in the example you’re suggesting, the update/save methods on the Book/Author controllers would be locked to the level you need.

By: Burt

Burt — Tue, 04 Nov 2008 21:05:29 +0000

You appear to be working with a very old version of the plugin – check out http://www.grails.org/AcegiSecurity+Plugin and in particular http://www.grails.org/AcegiSecurity+Plugin+-+LDAP+Tutorial. The current plugin also uses Spring Security 2, whereas you’re using an ancient version of Acegi – 1.0.5.

By: Martin Flower

Martin Flower — Tue, 04 Nov 2008 20:47:25 +0000

Hmm, great work. Just one question : do you think we can drop the name acegi and refer to SpringSecurity instead ?

By: Carsten Block

Carsten Block — Tue, 04 Nov 2008 20:26:43 +0000

Thanks a lot! It’s a very nice article… Concerning the “next steps” I’d love to see an easy to use acegi solution that permits an easy-to-use record level filtering.

Imagine the Author Book case quoted everywhere inside the grails docs:
It would be great to allow everybody to see all books in the store while only authors and admins should be able to edit them (and only admins may delete books).

Neither in in the acegi nor in the jsecurity nor in the authentication plugin there exists an unintrusive way of accomplishing that tasks…