Mapping Authorization Scheme to Acegi

[mumbly]

I'm trying to get a feel for who the authorization scheme I am working to implement would map to Acegi. Basically, what is there for free, what I would need to massage to fit and what I would need to write myself.

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.

Basically, we have users, roles and permissions. A user will have one or more roles. An administrator will assign some set of permissions to a role. 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.

So the permissions might be something like:

ViewUsers
EditUser
EditPermissions
AssignRole

These permissions have more information associated with them. They will have stuff such as a description, a version and possibly a scope and will likely be defined in XML.

Since we will be supporting multiple organizations, we will likely have roles for each org. So something like:

AdminOrg1
UserOrg1
GuestOrg1
AdminOrg2
UserOrg2
GuestOrg2

An admin for Org1 will assign the relevant permissions to each of the first three orgs above. As an example:

AdminOrg1 - EditUser, EditPermissions, ViewUsers
UserOrg1 - ViewUsers

And then a user will be assigned on or more roles available for their particular organization.

So what I would like to know is who this would/could be mapped to existing Acegi functionality and what I would need to write myself. Any pointers to example/sample apps that do something similar with Acegi would be great.

Thanks.

--Tim

[gfaerman]

Tim,

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...

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.

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.

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.

This can be pretty easy using the previously mechanism provided by
net.sf.acegisecurity.intercept.method.aopalliance. MethodSecurityInterceptor
with just some xml like:

<property name="objectDefinitionSource">
    <value>
       com.example.MainAppService.vieUser*=ROLE_ADMIN,ROLE_VIEWER
      com.example.MainAppService.editUser*=ROLE_ADMIN,ROLE_USERADMIN,ROLE_SECURITYADMIN
       com.example.editPermissions*=ROLE_ADMIN,ROLE_SECURITYADMIN
    </value>
  </property>

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: ).

Good luck!

Gustavo.

[Ben Alex]

Basically your best bet would be a custom GrantedAuthority that understands your notion of different customers, and also can provide a description etc. You'll need an AuthenticationDao that can retrieve those GrantedAuthoritys. You'll use the providers.rcp package to get the GrantedAuthority[]s for a user from the server to your rich client.

Hopefully there's some pointers. Basically you can use stock-standard Acegi Security code and just massage an intelligent AuthenticationDao. Oh, and you'll probably need a custom AccessDecisionVoter that can work with your more advanced GrantedAuthority[]s.

[mumbly]

Thanks for the pointers. I think that will get me started.

--Tim