5 Replies Latest reply on Jun 18, 2009 3:37 PM by jpav

    JCR Authorization Approach RFC

    bcarothers

      The JSR-170 spec gives a lot of latitude in how security is implemented. Because DNA needs to work in the JAAS world and in a servlet-based environment (for the REST server), we're currently taking a lowest common denominator approach and basing authorization off of "magic" role names.

      That is, having the "readonly" role implies that the user can read all content in all workspaces. Having the "readonly.foo" role implies that the user can read all content in the workspace named "foo" only.

      This yields the following mapping from DNA roles to JCR actions:
      DNA RoleJCR Action
      readonlyread
      readwriteadd_node, set_property, remove


      I am looking for feedback on this approach in general and these questions in particular:

      1. Do we need to add an additional admin or superuser role to add authorization for registering permanent namespace mappings and registering or unregistering types?

      2. Should users "see" workspaces (through Session.getAvailableWorkspaceNames()) that they don't have some kind of access to?

      3. Should the permision[.workspaceName] pattern be expanded to permission[.repositoryName[.workspaceName]] since DNA can host multiple repositories on the same server? Currently, giving a named user access to the "foo" workspace on one repository and not the other is only supported if the two repositories have different JAAS stores.

      In the long-term, I suspect that the security approach will start to look more like JSR-283 ACLs, but I would like to keep the 1.0 approach a bit simpler.

      Thanks!

        • 1. Re: JCR Authorization Approach RFC
          rhauch

          A few questions:

          a) Does "set_property" include adding, setting and removing properties and property values?
          b) Does "remove" apply to nodes? If so, should it be "remove_node" to better match "add_node"?

          Some responses to your questions:
          1) Probably, though we could add it when needed rather than preemptively do it.
          2) Good question. Ideally they would only see the names of the workspaces that they can read. Is that possible/easy?
          3) I think yes, so that we can support multiple repositories.

          • 2. Re: JCR Authorization Approach RFC
            medavid

            1) yes, I would preffer normal users whom just read / write to no be able to alter permanent namespaces or types
            2) always a difficult choise: show them what's in store or show them where they have access to. I prefer the first option, as in an application layer I'll be able to make that decision. But if the specifications tell that a user should not be able to know of a node exists if is not allowed to read it, I prefer the latter.
            3) that would be nice. In my projects we work with multiple virtual repositories, so that would be nice indeed.

            • 3. Re: JCR Authorization Approach RFC
              jpav

              My votes:
              1) Yes, though this would be DNA-specific since JCR-170 doesn't appear to have the concept.
              2) I would think not. Too bad JCR-170 doesn't have some type of "list" permission
              3) Yes
              a) Not according to the spec. However, it's not clear that adding is covered by add_node either...
              b) Strictly speaking, remove would apply to both nodes and properties. Regarding what it's called, this is defined by the spec.

              Reading the spec, it defines some permissions, but doesn't seem to preclude the addition of other implementation-specific permissions, such as "list" or "add_property". Something to consider?

              • 4. Re: JCR Authorization Approach RFC
                bcarothers

                 


                A few questions:

                a) Does "set_property" include adding, setting and removing properties and property values?

                "set_property" is for adding and modifying property values. "remove" is for removing properties or nodes.

                b) Does "remove" apply to nodes? If so, should it be "remove_node" to better match "add_node"?

                "remove" is for removing any item. It's not how I would have done it, but it's per-spec.

                Some responses to your questions:
                1) Probably, though we could add it when needed rather than preemptively do it.

                Works for me.

                2) Good question. Ideally they would only see the names of the workspaces that they can read. Is that possible/easy?

                Possible and pretty easy, I think.

                3) I think yes, so that we can support multiple repositories.

                Got it.

                • 5. Re: JCR Authorization Approach RFC
                  jpav

                  Oh, yes, missed the parentheses in the spec for set_property. bcarothers, you're right, set_property does deal with add.