The Acegi concept as I understood it and I actually use, is pretty simple and very usefull. Besides basic authentication and ACLs, authorization is the concept you are trying to grab. Let me try to give you a quick picture. In Acegi:
1. Any given user has grantedAuthorities (in your jargon, Authorities map to ROLES).
2. Now, that you know what the granted Authorities to the user are, you are able to let or deny this user to fire an action (a method, or whatever). Acegi will help you with a nice set of features that work even in a standalone enviroment. See net.sf.acegisecurity.intercept.method.aopalliance. MethodSecurityInterceptor
3. In the Acegi world, there is not concept of group of users. Acegi interfaces expect authorities to be given per user. Group of users is an administration helper artifact (the one any administrator will request to have if let's say you are developing an app for a call center and for example need to assign 1,000 users the ROLE_CUSTOMERREP role). In other words, when most people have their first approach to Acegi, would say: Hey, do I need to assign ROLES user by user? The answer is not really. Acegi interface will enforce to get grantedAuthorities per user, but is is up to you, implementing the Acegi interface in order to for example saying customer rep John Doe belongs to group LatinCustomerReps, and have in your implementation the ROLE_CUSTOMERREP assigned to this group.
So, trying to map your requirements to Acegi features...
Acegi is not limited to web enviroments. It works 5/5 in a rich client enviroment, either client/server(remoting) or standalone. An you do not need to deal with the actual enforcement. See next comment.
This is for a rich client, so I expect I will have to deal with the actual enforcement myself, as the web filters won't work and method or class level authorization also doesn't apply.
This can be pretty easy using the previously mechanism provided by
These permissions are defined by the application developer and will just be used as an arbitrary binary check to see if the given user can do something.
with just some xml like:
The app developer is just setting up an xml file. That can be changed without going through a new compile process. Just restart.
Now, if you have a group of so called UserOrg, just assign members of this group the role ROLE_VIEWER. Acegi will enforce security in a way this users will only be able to execute method editUser from class MainAppService (the wildcard is exactly what you are guessing: any variant of the method like viewUserOfTheMonth for example.
I would suggest you get deeper into Acegi. IMHO, Acegi WILLl help you. Get the Spring RC distribution and see the petclinic sample. Hope my two cents shed some light (here in Buenos Aires, we have a saying: please do not shed that light, it is just getting darker :wink: ).