Announcement Announcement Module
Collapse
No announcement yet.
Mapping Authorization Scheme to Acegi Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mapping Authorization Scheme to Acegi

    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

  • #2
    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:
    Code:
    <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.

    Comment


    • #3
      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.

      Comment


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

        --Tim

        Comment

        Working...
        X