Goal

  • We want to move the ACL checks to the JCR layer

Reasoning

  • better performance
  • JCR repository can be exposed otherwise (the ACLs are then still taken into account)
  • we want to use the JCR API without needing to wrap the objects everywhere

Resources

Conclusion

  • we cannot use "Resource-based ACLs". We had to update all the nodes on ACL changes and the permissions are only inherited on creation.
  • we will provide a custom AccessControlManager. This is very similar to our current solution, its not tied to the jackrabbit API. AccessControlManager API defined by spec is insufficient to control privileges. The control could be done at this level in JackRabbit, but only by overriding JR specific methods.
  • we will provide our own privilege provider. Privilege provider is already swappable in both JR and MS as each provides Resource based provider and limited role based provider.
  • JR already allows specifying custom privilege provider. MS currently supports only two of its own implementation. We will initiate request to open this to custom implementations.

Milestone 3 Sprint 3 - progress update

  • security is now executed in JCR layer
  • superuser account is treated as "admin" type account by JCR (JR) giving it all permissions always
  • MagnoliaAccessProvider is partially implemented - grants all to superuser, none to anonymous
  • ModeShape team is preparing MS 2.5b2 with hooks for extending security same way as possible in JR
  • only magnolia jaas chain and security realm exist in JCR configuration

Next Steps

  • implement security for ModeShape
  • finalize implementation of Access Provider
  • refactor RepositoryAccessStrategy and WorkspaceAccessUtil - related to unclosed sessions exceptions
  • test and make updates necessary for working with external users/groups
  • internal JR "admin" user should be replaced with superuser only, or admin should be locked out more strongly
  • test with pur or anything with custom realms
  • move supportBase constants to SecurityConstants
  • No labels

7 Comments

  1. Federico Grilli

    Moving ACLs to the JCR level has already been attempted by Openmind's criteria module (http://www.openmindlab.com/lab/products/mgnlcriteria/searchindex.html) According to them, it seems to be a rather tricky thing. In any case, it may be worth having a look at how they tackled the problem and talk with them about it.

    1. Jan Haderka

      This doesn't seem to use JCR security, but rather customize the index to take care of the security rules. The problem I see here is that changing security config requires one to force reindexing.
      Also it applies only to search i.e. if not having rights to the page it will not appear in the search results, but if you know the path, you can still access it.

    2. Philipp Bärfuss

      What we try to do is something completely different.

      criteria module: apply the ACLs upon search results in an efficient way. JCR is not aware of the ACLs.
      Magnolia 5.0: define the ACLs in the repository so that all operations can use the JCR security. All access to JCR are secured by the repository.

      The approach followed by the criteria module just solves a particular use-case because Magnolia doesn't make the ACLs transparent to the repository. Once we do, the criteria module will very well be able to benefit from this change.

  2. Jan Haderka

    As of ModeShape 2.4

    • resource based ACL provider mandated by JCR 2.0 is fully supported
    • there is limited role based ACL provider available
    • there is no way to customize AccessControlManager in MS
    • there is no way to provide custom ACL provider

    full transcript of the conversation with MS/Jboss:

    rah003: rhauch: quick question: if I got it right JCR 2.0 spec requires repos to provide resource based security, so you can configure permissions on existing resources (nodes), but it doesn't let you to specify ACLs for resources that do not exists yet. On top of this JR also provides Principal based provider that allows specifying privileges on the principal (user) rather then on the resource (node) ... is there similar thing in MS?
    00pm rhauch: rah003: ModeShape allows you to set up roles for users: http://docs.jboss.org/modeshape/latest/manuals/reference/html_single/reference-guide-en.html#modeshape_jcr_security
    00pm rah003: rhauch: and 2nd q: is it possible to specify custom impl of javax.jcr.security.AccessControlManager for MS?
    03pm psiroky left the chat room. (Quit: Leaving.)
    04pm rhauch: rah003: If the Credentials impl provides a "getLoginContext()" method that returns a javax.security.auth.login.LoginContext instance (and it can be called), then JcrRepository will use that LoginContext to authenticate, get the Subject name, and to determine if the subject has the various roles.
    05pm rhauch: rah003: we don't currently do anything with AccessControlManager.
    05pm rah003: rhauch: do i understand it correctly that i can't have custom ACM, but I can customize CredentialsImpl and have it to return LoginContext that will determine roles?
    06pm rhauch: rah003: yes, your last statement is correct.
    06pm rah003: rhauch: hmm, in this case I'll probably try to make do with just roles ACL provider that exists for both JR and MS
    07pm rah003: rhauch: thanks for answers. I'm currently looking into moving security from Magnolia directly into JCR and want to make sure it works the same on both JR and MS
    07pm rhauch: rah003: It's a shame that JCR 2 didn't specify how to configure the roles.
    08pm rah003: rhauch: agreed. seems like a security config that most users will be interested in
    08pm rhauch: rah003: without that, you're tied 100% into your JCR impl.
    08pm rhauch: rah003: that's a major shortcoming, IMO.
    08pm rhauch: rah003: shortcoming of the spec, that is.
    09pm rah003: rhauch: yep, and it also limits you to specifying perms only for existing resources ... it's a shame
    12pm rah003: rhauch: one more thing: if i use the roles provider that MS implements ... it currently provides 3 roles readonly, readwrite and admin. how can i add extra roles? is there role management API anywhere or I'm limited to those 3 roles?
    13pm rhauch: rah003: That's it. It's fairly limited.
    13pm maeste is now known as maeste_afk.
    14pm rah003: rhauch: :'( not enough ... any way to plugin my own ACL provider?
    15pm rhauch: rah003: no, not at this time. Want to create a JIRA?
    16pm rah003: rhauch: i'll think it over again, to see if there are any other hooks I could possibly use, but most likely yes.
    16pm rah003: rhauch: thanks for all the info.
    17pm rhauch: rah003: np. sorry there wasn't anything out-of-the-box.
    17pm rhauch: rah003: please let us know what you'd liked to see, though.
    18pm rah003: rhauch: will do

  3. Richard Unger

    Hi security-architects!

    We're having some problems with the current (pre 5.0) implementation of security, and before implementing our own stuff I wanted to get some feedback, if possible, about the future capabilities of Magnolia with regards to security.

    Basically, our customer's requirement is for fairly fine-grained security. They can't work with a centrally managed publish and approve process. Each author can publish his/her own work, without a 2 stage workflow. (We have tried arguing against this, but to no avail).

    So, to keep control over the site, they want to set permissions, ideally down to the individual page level. This creates massive problems for us with magnolia's current security architecture.

    • Quite apart from the fact that the number of ACEs required to manage this is very large, there is currently no GUI for manageing ACLs attached to a individual user. (It seems users can have ACLs attached to them, but currently they need to be created programmatically)
    • Also, JCR offers the right "add-child-node" (as opposed to the more general right "write", which includes "add-child-node"), but there seems to be no such right in magnolia. The "add-child-node" right would be needed to allow authors to create a new page within a parent page, but not allow editing of the parent page itself.

    So we can't really offer security at the page level at the moment, instead we create groups and roles, and set the ACLs down to about the 3rd level of the content hierarchy, which is not exactly what the customer wants, but enough for the moment (with promises of future improvement).

    With this solution we still have the significant problem that whenever the content-hierarchy is changed (our customer uses "Articles", which are organised in "folders" they call "Categories"), the ACLs lose traction, because they are Path rather than UUID based... unfortunately, adding new or renaming  the existing "folders" or "Categories" is something they do frequently, forcing us to update the roles all the time to reflect the new path values in the ACLs.

    In my analysis, what we would really need is:

    1. to be able to set ACLs not only on the roles or groups, but also on the pages (nodes). Not only would this be far more natural in terms of useability --> set the ACLs on the page, when the page is created, but would also vastly reduce the number of ACEs to maintain per object.
      Currently a role needs very many ACEs to cover all the "folders" and "articles" the role is allowed to edit. By setting ACLs on the page-nodes themselves, each page-node will have only a few users allowed to edit it, making for shorter, more manageable lists...
    2. to be able to set an ACLs with right "add-child-node" (but not "write") - so that authors can add an "article" to a "category" without having the right to edit the details of the category itself.
    3. GUIs for managing all this.

    All this is important only on the aithoring side, of course, on the public instance the current security mechanisms are sufficient.

    Any ideas or feedback for our situation?

    Should we wait for Magnolia 5.0? Are there any components/modules in Magnolia 4.x that could help with our situation? Is there even any chance of getting this working in Magnolia 4.x?

    Any insights would be greatly appreciated!

    Regards from Vienna,

    Richard Unger

    1. Jan Haderka

      Hi Richard,
      what you describe is almost exactly what the default security model of JCR is and what each repository implementation has to provide - the access permissions are stored as part of the node itself.
      In 5.0 we are moving security layer to JCR so you should be able to switch off Magnolia AccessProvider and use default AccessProvider shipped with repository. You would still need (most likely) write your own ui code for setting those permissions (we don't have it for 5.0 yes, which is why I don't know how closely we can use JR API for that). However you would get the implementation of permission checking for free. One of the reasons why MAgnolia doesn't use this model is the fact that to check permissions you need to access the node and this effectively renders caching useless, but recent versions of JR have provided some caching at this level as well so the impact might not be so high these days.
      We will try to keep your need in mind and make sure that if possible you can switch provider with minimal effort.
      Regards,
      Jan

      1. Richard Unger

        Thank you for your response!

        We will take this into account in our planning. I really hope we pursuade our customer to choose a more reasonable approach to security, but if not then I will try to argue that we need to wait for Magnolia 5.0 for this feature.

        Regards,

        Richard