Announcement Announcement Module
No announcement yet.
Permissions/tasks in LDAP/Acegi Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Permissions/tasks in LDAP/Acegi

    I would like to let my application use an LDAP server for authentication and authorisation. Specifically, my application has to be deployed at customers that already have an LDAP server in use, and I have limited or no control on how it is set up. I don't have much LDAP experience, but I would say this is a common scenario.

    What I read in most articles and manuals is that it is very common to configure users and groups in the LDAP server, and assign users to these groups. I've managed to set up a simple LDAP server with some users and groups, and create a small java web application using Spring/Acegi to authenticate and authorise against the server. It works very well, and I was impressed by the fact that I didn't have to write a single line of security-related code; Acegi allows me to configure all of it.

    One thing that I noticed was that the "groups" in LDAP appear as "GrantedAuthority"s in Acegi. However, in most situations they are referred to as "roles". Is there a (significant) difference between groups in LDAP and roles in Acegi?

    What I'm missing in all articles/manual/tutorials etc is a way to define "permissions". It seems that LDAP is typically used to define users and groups (e.g. "supervisor", "customer support", ...), but it is typically not used to define permissions for each group (e.g. "update balance", "do task x", ...). To me, it seems a bit strange to authorise against a role. As I said, the roles (groups in LDAP) are defined by my customer, and not by me, the application designer. This means I have to include role names in my application that I can't define myself. If my customer has a group name "admin", I have to copy this group name into my Acegi configuration, and possibly in my code as well (e.g. to do <authz:authorize ifAllGranted="ROLE_admin">). I hope you agree that this is not a very good solution.

    What I've seen in other (proprietary) systems is that the roles are configured to have permissions (maybe "task" is a better name), that are defined by the application designer. Then, the application authorises against the permission names. The roles are not used by the application in this scenario; they only have an administrative purpose. This seems a pretty elegant solution to me.

    However I don't know if it's possible to do this in an LDAP/Acegi solution; I couldn't find any LDAP examples that do this, and Acegi seems to focus on roles for authorisation.

    Is this an uncommon requirement? Are they other (better) solutions for this problem?


  • #2
    Encountered same issue

    I have encountered exactly the same issue - nice to see it put so succinctly.

    So, why IS authorization against a role? Surely, as Tom says, it should be against a permission? After all, Acegi's authorizations are very fine grained - at the URL or method level.



    • #3
      Its not that you can't use Acegi with permissions. You could use them in place of roles if you wanted to, its just that there is also domain object security. I've seen a few projects just make a straight swop of ROLE_ for PERMISSION_ it worked ok.

      Usually the GrantedAuthority objects are application-wide permissions. They are not specific to a given domain object. Thus, you wouldn't likely have a GrantedAuthority to represent a permission to Employee object number 54, because if there are thousands of such authorities you would quickly run out of memory (or, at the very least, cause the application to take a long time to authenticate a user). Of course, Acegi Security is expressly designed to handle this common requirement, but you'd instead use the project's domain object security capabilities for this purpose.
      Last edited by karldmoore; Dec 11th, 2006, 11:55 AM.


      • #4
        Hi - i had exactly the same issue myself that I tried to explain (perhaps in too much detail) in this post.

        Basically we want permissions as described here (where in our application a supervisor who assigns permissions to groups) The permissions are then used in an acegi role voter to provide find grained authorisation on methods (such as update balance etc)

        However it does make sense to authorise against groups also when using domain object security (ACLS) in this scenario it makes perfect sense to assign visiblity of an object to a group defined in LDAP.

        What I've done for now is store the permissions against groups in our db (configured by a supervisor - the groups here can map to ldap groups if required). Then I have a class that flattens this group permission structure into a single 'acegi role / authority' list of the style ROLE_PERM_X, ROLE_GROUP_Y - after this point I can use the standard voters (with the correct prefixes) to implement method security (on permissions) and ACLs on groups - the acegi system does not need to know the permissions are configured against groups. We have a single class that builds the authorities that can be used with several of the authentication mechanisms.

        However we had to write our own LdapAuthoritiesPopulator (based on the default one) to use this class as the default one does not allow you to override getGrantedAuthorities to make use of our reusable class which would have been nicer. (Any chance of changing this??)

        This seems to be a common question - ie the best way to do roles / permissions / groups - so maybe there should be a bit more support for it or examples of it (I understand ageci is not about how its all managed)