Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: SVN trunk
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None

      Description

      In order to separate access to jcr content each application should have its own workspace in the repository.

        Activity

        Hide
        Adrian Crum added a comment -

        I would be interested to see a use case for this issue. In my experience, access to content is based on user credentials, not on a particular application.

        Show
        Adrian Crum added a comment - I would be interested to see a use case for this issue. In my experience, access to content is based on user credentials, not on a particular application.
        Hide
        Pierre Smits added a comment -

        I guess you could compare it to data in an OFBiz repository.

        In my experience access to the OFBiz data is not only based on the user credentials sec, but also on the mapping between the user and the CRUD functions defined in the application. The same is with workspaces, if I understand it correctly. They provide viewpoints to the content stored so that you can maintain multiple reference points to the JCR content.

        E.g. a user can have rights to FICO to store invoices and agreements. But another user, with only access to, let's say CRM, would need access to FICO to view the invoice and/or agreement. By defining a new reference point to the content through the CRM workspace he/she could also have access to that object. Workspaces can then be used for cloning, merging and updating.

        Show
        Pierre Smits added a comment - I guess you could compare it to data in an OFBiz repository. In my experience access to the OFBiz data is not only based on the user credentials sec, but also on the mapping between the user and the CRUD functions defined in the application. The same is with workspaces, if I understand it correctly. They provide viewpoints to the content stored so that you can maintain multiple reference points to the JCR content. E.g. a user can have rights to FICO to store invoices and agreements. But another user, with only access to, let's say CRM, would need access to FICO to view the invoice and/or agreement. By defining a new reference point to the content through the CRM workspace he/she could also have access to that object. Workspaces can then be used for cloning, merging and updating.
        Hide
        Sascha Rodekamp added a comment -

        Separating the concerns in the repository by using different workspaces is, IMHO, a good approach. That could make maintenance of the repository and right management easier.

        Show
        Sascha Rodekamp added a comment - Separating the concerns in the repository by using different workspaces is, IMHO, a good approach. That could make maintenance of the repository and right management easier.
        Hide
        Scott Gray added a comment -

        Please don't take a hasty approach on this, I haven't looked at jackrabbit in a long time now but at first glance this sounds concerning.

        For example this heavily referenced wiki page states: http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29.

        Workspaces should not be used for access control. Visibility of content for a particular group of users is not a good argument to separate things into different workspaces. JCR features "Access Control" in the content repository to provide for that.

        Show
        Scott Gray added a comment - Please don't take a hasty approach on this, I haven't looked at jackrabbit in a long time now but at first glance this sounds concerning. For example this heavily referenced wiki page states: http://wiki.apache.org/jackrabbit/DavidsModel#Rule_.233:_Workspaces_are_for_clone.28.29.2C_merge.28.29_and_update.28.29 . Workspaces should not be used for access control. Visibility of content for a particular group of users is not a good argument to separate things into different workspaces. JCR features "Access Control" in the content repository to provide for that.
        Hide
        Scott Gray added a comment -

        Also to use your example Pierre, if a CRM user needed to access a certain invoice/agreement then the content access control should allow it based on the same permission checks use to allow access to view the invoice from the OFBiz database. So if you can view the invoice then you should be able to view it's representations in the content repo as well.

        All of these things can be achieved by defining permission rules against nodes which would them be inherited by descendent nodes.
        e.g. to read the "/invoices/*" node we might define a permission check that requires the user to either have the ACCOUNTING_VIEW, or otherwise be a party to the invoice (perhaps a representative of the from/to party). All child nodes of invoice would then inherit this check, such as "/invoices/1000123/pdf".

        Show
        Scott Gray added a comment - Also to use your example Pierre, if a CRM user needed to access a certain invoice/agreement then the content access control should allow it based on the same permission checks use to allow access to view the invoice from the OFBiz database. So if you can view the invoice then you should be able to view it's representations in the content repo as well. All of these things can be achieved by defining permission rules against nodes which would them be inherited by descendent nodes. e.g. to read the "/invoices/*" node we might define a permission check that requires the user to either have the ACCOUNTING_VIEW, or otherwise be a party to the invoice (perhaps a representative of the from/to party). All child nodes of invoice would then inherit this check, such as "/invoices/1000123/pdf".
        Hide
        Pierre Smits added a comment -

        Fore sure, various scenarios are possible. Some more effective, some less. We must evaluate all options in the jackrabbit branch before having anything implemented in trunk.

        Show
        Pierre Smits added a comment - Fore sure, various scenarios are possible. Some more effective, some less. We must evaluate all options in the jackrabbit branch before having anything implemented in trunk.

          People

          • Assignee:
            Unassigned
            Reporter:
            Pierre Smits
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development