1 Reply Latest reply on Aug 29, 2013 4:50 PM by rhauch

    ModeShape 3.4 ACLs (and missing optimization)

    rhauch

      When a Session attempts to read or update content, ModeShape needs to determine if they have privilege to do so. Prior to 3.4, the only mechanism that ModeShape supported was via JAAS roles. However, with ModeShape 3.4.0.Final, we added the ability for ModeShape to use JCR 2.0 access control lists (ACLs).

       

      Access Control Lists

       

      ACLs are a fine-grained mechanism for specifying the exact permissions for explicitly-named users (or groups) at a particular location in the repository. ACLs apply to the node on which they're defined and to all descendants, but when determining privileges for a particular node, the ACLs closer to the node take precedence.

       

      ModeShape authorization mechanism takes into account both the JAAS roles and the ACL mechanism: a session must have both the proper role and (if there are applicable ACLs) permission given by those applicable ACLs. Thus, ACLs are considered a refinement of the broader roles.

       

      For example, imagine a repository with a node at "/a/b/c" and which contains a single ACL at the parent node (e.g., "/a/b"). In order to modify properties on node "/a/b/c", a particular session must have the "read-write" role (stating that the user is able to write to the repository) and the ACL at the parent node must grant this particular user the "jcr:modifyProperties" privilege (or one of the "jcr:write" or "jcr:all" aggregate privileges). Note that ACLs do apply to all descendants, so it is possible for the ACL on the parent node to grant permissions to specific users on its children (and other descedants).

       

      Of course, if there happens to be no ACLs on the "/a/b/c" node or its ancestors, then all privileges are implicitly granted to all users which have the required role.

       

      This ACL feature is a technology preview in 3.4, which means that we're asking people to try it out and give us feedback, but to not yet put the feature into production. In other words, ModeShape 3.4.0.Final is ready for production, but just don't create ACLs in production repositories yet.

       

      Repositories with no ACLs

       

      One of the things we wanted to include in 3.4 was an optimization that completely skipped over the ACL checks in repositories that have no ACLs. (See MODE-2004 for details.) Unfortunately, I failed to merge this optimization, and it was only discovered today. That means that ModeShape 3.4.0.Final does not have this optimization, and will therefore attempt to check ACLs even if there are no ACLs in the repository.

       

      What impact does this have on users? First of all, nothing is broken. If you are using ACLs, then those ACLs are enforced. If you are not using ACLs, then ModeShape still correctly authorizes sessions and users. But if you are not using ACLs, then ModeShape takes a bit longer with each operation to look for the non-existant ACLs. How much longer? Well, its difficult to say, since we've made some improvements in other areas, and because it completely depends on your application's access patterns. For example, if your application creates and application and does just a few operations, then it is likely the extra overhead of checking ACLs is negligent. OTOH, if your applications' sessions are doing lots of operations, then that overhead might be noticeable. If you are concerned, please check for yourself by doing some quick benchmarking of your application between 3.3 and 3.4.

       

      Please let us know if you are concerned about 3.4 because of this. Generally we try to avoid issuing patch releases, but in this case we're willing to cut a 3.4.1 release if you want us to.

       

       

      My sincere apologies for any grief or problems that I caused with this mistake!

        • 1. Re: ModeShape 3.4 ACLs (and missing optimization)
          rhauch

          We've released 3.5.0.Final, and it adds in the optimization described above that skips ACL checks until the first ACL is created in a repository. From that point on, ACL checking is always performed when accessing or modifying content.


          Be advised that if you're using this feature in 3.4 and upgrade to 3.5, you may need to create (and save) at least one ACL in the repository before ACL checking is enabled. (You can always remove and save that ACL if it's not really needed.) It's not ideal, but was the only effective way to handle the upgrade.

           

          If you haven't used the ACL feature yet in 3.4, you can simply upgrade to 3.5 and you'll get the performance boost of the optimization.

           

          The ACL features is still considered tech-preview, so if you are interested in it then please put it through its paces and let us know how it works for you.