jsr-333
  1. jsr-333
  2. JSR_333-15

Define access control for repository level operations

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: spec
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      15

      Description

      currently the specification doesn't define how access control on repository
      level operations

      • namespace registr.
      • node type registr.
      • workspace mgt

      should be handled.

        Activity

        Hide
        anchela added a comment -

        this is a follow up for https://jsr-283.dev.java.net/issues/show_bug.cgi?id=486
        for those parts that have been left to the implementation.

        Show
        anchela added a comment - this is a follow up for https://jsr-283.dev.java.net/issues/show_bug.cgi?id=486 for those parts that have been left to the implementation.
        Hide
        Peeter Piegaze added a comment -

        Changed platform to "All"

        Show
        Peeter Piegaze added a comment - Changed platform to "All"
        Hide
        Peeter Piegaze added a comment -

        The current spec defines the following privileges:

        jcr:all
        jcr:read
        jcr:readAccessControl
        jcr:modifyAccessControl
        jcr:lockManagement
        jcr:versionManagement
        jcr:nodeTypeManagement
        jcr:retentionManagement
        jcr:lifecycleManagement
        jcr:write
        jcr:modifyProperties
        jcr:addChildNodes
        jcr:removeNode
        jcr:removeChildNodes

        jcr:all is an aggregate privilege that includes all other privileges.
        jcr:write is an aggregate privilege that includes the four more specific write privileges

        This issue proposes to add three additional privileges:

        jcr:workspaceManagement: covers the ability to create and remove workspaces in the repository.

        jcr:nodeTypeDefinitionManagement: covers the ability to register, unregister and change the definitions of node type in the repository.

        jcr:namespaceManagement: covers the ability to register, unregister and modify namespace definitions.

        Unlike the current privileges, these three are not associated with any particular node. Since the existing
        AccessControlManager methods for checking privileges all take an absPath, a solution has to be found for how
        these methods work with the three new privileges. The methods in question are:

        Privilege[] getSupportedPrivileges(String absPath)
        boolean hasPrivileges(String absPath, Privilege[] privileges)
        Privilege[] getPrivileges(String absPath)

        Here are some proposals on how to handle the new privileges using the existing methods:

        1) Each of the three new privileges either applies to all nodes in a workspace or to no nodes in a workspace. In other words the absPath becomes irrelevant when dealing with these privileges.

        2) The three new privileges are considered to apply to the "null" absPath. So, for example, in a system that supports all three of the new privileges, a call to

        acm.getSupportedPrivileges(null);

        would return:

        {jcr:workspaceManagement, jcr:nodeTypeDefinitionManagement, jcr:namespaceManagement}

        Passing a null to hasPrivileges or getPrivileges would work similarly.

        3) Introduce new methods to deal with these new privileges

        Show
        Peeter Piegaze added a comment - The current spec defines the following privileges: jcr:all jcr:read jcr:readAccessControl jcr:modifyAccessControl jcr:lockManagement jcr:versionManagement jcr:nodeTypeManagement jcr:retentionManagement jcr:lifecycleManagement jcr:write jcr:modifyProperties jcr:addChildNodes jcr:removeNode jcr:removeChildNodes jcr:all is an aggregate privilege that includes all other privileges. jcr:write is an aggregate privilege that includes the four more specific write privileges This issue proposes to add three additional privileges: jcr:workspaceManagement: covers the ability to create and remove workspaces in the repository. jcr:nodeTypeDefinitionManagement: covers the ability to register, unregister and change the definitions of node type in the repository. jcr:namespaceManagement: covers the ability to register, unregister and modify namespace definitions. Unlike the current privileges, these three are not associated with any particular node. Since the existing AccessControlManager methods for checking privileges all take an absPath, a solution has to be found for how these methods work with the three new privileges. The methods in question are: Privilege[] getSupportedPrivileges(String absPath) boolean hasPrivileges(String absPath, Privilege[] privileges) Privilege[] getPrivileges(String absPath) Here are some proposals on how to handle the new privileges using the existing methods: 1) Each of the three new privileges either applies to all nodes in a workspace or to no nodes in a workspace. In other words the absPath becomes irrelevant when dealing with these privileges. 2) The three new privileges are considered to apply to the "null" absPath. So, for example, in a system that supports all three of the new privileges, a call to acm.getSupportedPrivileges(null); would return: {jcr:workspaceManagement, jcr:nodeTypeDefinitionManagement, jcr:namespaceManagement} Passing a null to hasPrivileges or getPrivileges would work similarly. 3) Introduce new methods to deal with these new privileges
        Hide
        anchela added a comment -

        A) privilege names
        -> fine by me

        B) privilege discovery
        -> not sure... having new methods feels odd... so 2) is currently
        my preferred though not loved solution... if we went for 2) we
        had to adjust the wording that always states that the path
        defines an existing node.
        -> or should they be supported on the root node only? see (C)

        C) access control editing
        may be we should take a look at this as well... i guess that finding
        a solution for the editing could help us solving the discovery issue (B).
        in other words: how would one grant workspacemanagement privilege to
        somebody.
        if we went for acm.getSupportedPrivileges(null) there was also the
        need to retrieve applicable policies etc. with a 'null' path argument.
        furthermore: would those repo-level privileges be the same for
        each workspace as the effect is not limited to a single workspace?

        D) define what is a privilege:
        currently the API states

        "A privilege represents the capability of performing a particular set
        of operations on items in the JCR repository"

        if we introduce privileges for repository level operations this
        isn't true any more.

        Show
        anchela added a comment - A) privilege names -> fine by me B) privilege discovery -> not sure... having new methods feels odd... so 2) is currently my preferred though not loved solution... if we went for 2) we had to adjust the wording that always states that the path defines an existing node. -> or should they be supported on the root node only? see (C) C) access control editing may be we should take a look at this as well... i guess that finding a solution for the editing could help us solving the discovery issue (B). in other words: how would one grant workspacemanagement privilege to somebody. if we went for acm.getSupportedPrivileges(null) there was also the need to retrieve applicable policies etc. with a 'null' path argument. furthermore: would those repo-level privileges be the same for each workspace as the effect is not limited to a single workspace? D) define what is a privilege: currently the API states "A privilege represents the capability of performing a particular set of operations on items in the JCR repository" if we introduce privileges for repository level operations this isn't true any more.
        Hide
        Peeter Piegaze added a comment -

        > 2) is currently my preferred though not loved solution...
        > if we went for 2) we had to adjust the wording that always
        > states that the path defines an existing node.

        Using null as the path argument seems the most logical solution. And we would have to adjust the wording about the path argument always pointing to a node.

        > or should they be supported on the root node only? see (C)

        I think for repo-wide settings null is better. These particular privileges have no meaning (I think) in a workspace-wide context (i.e., they only apply repo-wide) so in the case of these particular privileges using the root node might be ok. However, since the set of privileges is supposed to be extensible by implementations, there may be other privileges (that we do not define) which have differing effect repo-wide vs. ws-wide. So, for this reason I think we must distinguish repo from WS using null vs "/"

        > if we went for acm.getSupportedPrivileges(null) there was also the
        > need to retrieve applicable policies etc. with a 'null' path argument.

        Yes. the use of the null path as meaning "repo-wide" would also apply to getting, setting and removing policies.

        > furthermore: would those repo-level privileges be the same for
        > each workspace as the effect is not limited to a single workspace?

        Technically this would be implementation detail of the policy itself. In theory the node to which a policy
        is bound is already not necessarily connected directly to the effect of the policy. See 16.3.5 (and associated footnote) which I have copied below:

        16.3.5 Scope of a Policy
        ...
        When an access control policy takes effect, it may affect the accessibility characteristics not only of the node to which it is bound but also of nodes elsewhere in the workspace[20].

        [20] One common case is a policy that affects both its bound node and the subgraph below that node. However, any such deepness attribute is internal to the policy and, like any other internal characteristic of a policy, opaque to the JCR API except insofar as it is part of the human-readable name and description. Note also that, strictly speaking, a policy is not required to affect even its bound node, though such an implementation would be uncommon.

        Show
        Peeter Piegaze added a comment - > 2) is currently my preferred though not loved solution... > if we went for 2) we had to adjust the wording that always > states that the path defines an existing node. Using null as the path argument seems the most logical solution. And we would have to adjust the wording about the path argument always pointing to a node. > or should they be supported on the root node only? see (C) I think for repo-wide settings null is better. These particular privileges have no meaning (I think) in a workspace-wide context (i.e., they only apply repo-wide) so in the case of these particular privileges using the root node might be ok. However, since the set of privileges is supposed to be extensible by implementations, there may be other privileges (that we do not define) which have differing effect repo-wide vs. ws-wide. So, for this reason I think we must distinguish repo from WS using null vs "/" > if we went for acm.getSupportedPrivileges(null) there was also the > need to retrieve applicable policies etc. with a 'null' path argument. Yes. the use of the null path as meaning "repo-wide" would also apply to getting, setting and removing policies. > furthermore: would those repo-level privileges be the same for > each workspace as the effect is not limited to a single workspace? Technically this would be implementation detail of the policy itself. In theory the node to which a policy is bound is already not necessarily connected directly to the effect of the policy. See 16.3.5 (and associated footnote) which I have copied below: 16.3.5 Scope of a Policy ... When an access control policy takes effect, it may affect the accessibility characteristics not only of the node to which it is bound but also of nodes elsewhere in the workspace [20] . [20] One common case is a policy that affects both its bound node and the subgraph below that node. However, any such deepness attribute is internal to the policy and, like any other internal characteristic of a policy, opaque to the JCR API except insofar as it is part of the human-readable name and description. Note also that, strictly speaking, a policy is not required to affect even its bound node, though such an implementation would be uncommon.
        Hide
        Peeter Piegaze added a comment -

        Proposal for resolving this issue: A Word doc with track changes.

        Show
        Peeter Piegaze added a comment - Proposal for resolving this issue: A Word doc with track changes.
        Hide
        Peeter Piegaze added a comment -

        I have attached a proposal for this issue. It is change tracke Word doc.

        Please review and comment.

        http://java.net/jira/secure/attachment/45723/jcr-spec-acm-proposed-changes.doc

        Show
        Peeter Piegaze added a comment - I have attached a proposal for this issue. It is change tracke Word doc. Please review and comment. http://java.net/jira/secure/attachment/45723/jcr-spec-acm-proposed-changes.doc
        Hide
        anchela added a comment -

        attached a commented version of the diff.

        there is one thing that i felt uneasy with: the statement that the user is a session.
        from my point of view this isn't correct (see attachement for wordy explanation).

        i think we should stick with the notion that privileges are assigned to a principal
        for a given object (was: node). how this is matched to a given session is up to now
        left to the implementation and i would rather not want to introduce something like
        'user' as this seems really confusing to me (see also AccessControlList).

        Show
        anchela added a comment - attached a commented version of the diff. there is one thing that i felt uneasy with: the statement that the user is a session. from my point of view this isn't correct (see attachement for wordy explanation). i think we should stick with the notion that privileges are assigned to a principal for a given object (was: node). how this is matched to a given session is up to now left to the implementation and i would rather not want to introduce something like 'user' as this seems really confusing to me (see also AccessControlList).
        Hide
        Peeter Piegaze added a comment -

        My changes plus Angela's adjustments have been made.

        Show
        Peeter Piegaze added a comment - My changes plus Angela's adjustments have been made.

          People

          • Assignee:
            Peeter Piegaze
            Reporter:
            anchela
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: