[ https://issues.apache.org/jira/browse/OAK-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730703#comment-13730703 ]
angela edited comment on OAK-942 at 8/9/13 11:43 AM: ----------------------------------------------------- h4. 1. Characteristics of the Default Implementation h5. General _TODO_ h5. JCR API h6. Session#hasPermission and #checkPermission Since OAK the permission related API calls not only allow to pass the action strings defined by JCR specification (see constants defined in {{Session.java}}) but also handles the names of the permission defined by OAK (see {{Permissions#getString(long permissions)}}). h5. Mapping of JCR Actions to Permissions _TODO_ h5. Permissions The set of permissions supported by OAK are listed in Permissions [0]. The following changes have been compared compared to Jackrabbit 2.x: * READ_NODE: permission to read a node * READ_PROPERTY: permission to read a property * ADD_PROPERTY: permission to create a new property * MODIFY_PROPERTY: permission to change an existing property * REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY * USER_MANAGEMENT: permission to execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership. The following permissions are now an aggregation of new permissions: * READ: aggregates READ_NODE and READ_PROPERTY * SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY h5. Permission Evaluation h6. Reading Due to the fine grained read permissions OAK read access can be separately granted/denied for nodes and properties. See also the section about extended restriction management in OAK-792. Granting the jcr:read privilege will result in a backwards compatible read access for nodes and their properties, while specifying {{rep:readNodes}} or rep:readProperties privileges allows separately granting or denying access to nodes and properties (see also OAK-910 for changes in the privilege definitions). Together with the restrictions this new behavior now allows to individually grant/deny access to properties that match a given name/path/nodetype (and as a possible extension even property value). The only break in terms of backwards compatibility is the accessibility of version content underneath /jcr:system/jcr:versionStore. As of OAK the access to version content depends on the read permissions present with the versionable node while Jackrabbit 2.x doesn't apply any special rule. These changes are covered by OAK-444 and address the concerns summarized in JCR-2963. h6. Property Modification Since OAK the former SET_PROPERTY permission has been split such to allow for more fined grained control on writing JCR properties. In particular OAK clearly distinguishes between creating a new property that didn't exist before, modifying or removing an existing property. This will allow to cover those cases where a given subject is only allowed to create content but doesn't have the ability to modify/delete it later on. h6. Node Removal As of Oak `Node#remove()` only requires sufficient permissions to remove the target node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and verify remove permission on all child nodes/properties. In order to obtain backwards compatible behavior with respect to tree removal the permission evaluation can be configured to traverse down the hierarchy upon removal. This config flag is a best effort approach but doesn't guarantee an identical behavior. h6. Move and Copy _TODO: permission evaluation with copy and move is not yet implemented (OAK-920, OAK-710)_ h6. Version Management Reading and writing items in the version store does not follow the regular permission evaluation but depends on access rights present on the corresponding versionable node. In case the version information does no longer have a versionable node in this workspace that original path is used to evaluate the effective permissions that would apply to that node if the version was restored. Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular JCR write permissions is required in order to execute version operations and thus modify the version store. These changes are covered by OAK-444 and address the concerns summarized in JCR-2963. h6. User Management By default user management operations require the specific user mgt related permission to be granted for the editing subject. This permission (including a corresponding privilege) has been introduced with OAK 1.0. For backwards compatibility with Jackrabbit 2.x this behavior can be turned off by setting the corresponding configuration flag. h5. Administrative Principals h4. 2. Node Types _TODO_ {code} /** * @since oak 1.0 */ [rep:PermissionStore] orderable + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE + * (rep:Permissions) = rep:Permissions protected IGNORE /** * @since oak 1.0 */ [rep:Permissions] - * (UNDEFINED) protected - * (UNDEFINED) protected multiple + * (rep:Permissions) = rep:Permissions protected IGNORE {code} {code} /** * @since oak 1.0 */ [rep:VersionablePaths] mixin - * (PATH) protected ABORT {code} h4. 3. API Extensions org.apache.jackrabbit.oak.spi.security.authorization.permission - {{PermissionProvider}}: _TODO_ - {{Permissions}}: _TODO_ - {{PermissionConstants}}: _TODO_ - {{ReadStatus}}: _work in progress_ h4. 4. Configuration * Permission Configuration ** AuthorizationConfiguration#getPermissionProvider: _TODO_ * Configuration Parameters supported by the default implementation ** PARAM_PERMISSIONS_JR2: Enables backwards compatible behavior for the permissions listed in the parameter value. Currently the following values are allowed: "USER_MANAGEMENT" and "REMOVE_NODE". The parameter value must contain the permission names separated by ','. ** PARAM_READ_PATHS: default set of paths that are always readable to all principals irrespective of other permissions defined at that path or inherited from other nodes. ** PARAM_ADMINISTRATOR_PRINCIPALS: The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. h4. 5 References [0] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java was (Author: anchela): h4. 1. Characteristics of the Default Implementation h5. General _TODO_ h5. JCR API h6. Session#hasPermission and #checkPermission Since OAK the permission related API calls not only allow to pass the action strings defined by JCR specification (see constants defined in {{Session.java}}) but also handles the names of the permission defined by OAK (see {{Permissions#getString(long permissions)}}). h5. Mapping of JCR Actions to Permissions _TODO_ h5. Permissions The set of permissions supported by OAK are listed in Permissions [0]. The following changes have been compared compared to Jackrabbit 2.x: * READ_NODE: permission to read a node * READ_PROPERTY: permission to read a property * ADD_PROPERTY: permission to create a new property * MODIFY_PROPERTY: permission to change an existing property * REMOVE: aggregation of REMOVE_NODE and REMOVE_PROPERTY * USER_MANAGEMENT: permission to execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership. The following permissions are now an aggregation of new permissions: * READ: aggregates READ_NODE and READ_PROPERTY * SET_PROPERTY: aggregates ADD_PROPERTY, MODIFY_PROPERTY and REMOVE_PROPERTY h5. Permission Evaluation h6. Reading Due to the fine grained read permissions OAK read access can be separately granted/denied for nodes and properties. See also the section about extended restriction management in OAK-792. Granting the jcr:read privilege will result in a backwards compatible read access for nodes and their properties, while specifying {{rep:readNodes}} or rep:readProperties privileges allows separately granting or denying access to nodes and properties (see also OAK-910 for changes in the privilege definitions). Together with the restrictions this new behavior now allows to individually grant/deny access to properties that match a given name/path/nodetype (and as a possible extension even property value). The only break in terms of backwards compatibility is the accessibility of version content underneath /jcr:system/jcr:versionStore. As of OAK the access to version content depends on the read permissions present with the versionable node while Jackrabbit 2.x doesn't apply any special rule. These changes are covered by OAK-444 and address the concerns summarized in JCR-2963. h6. Property Modification Since OAK the former SET_PROPERTY permission has been split such to allow for more fined grained control on writing JCR properties. In particular OAK clearly distinguishes between creating a new property that didn't exist before, modifying or removing an existing property. This will allow to cover those cases where a given subject is only allowed to create content but doesn't have the ability to modify/delete it later on. h6. Node Removal As of Oak `Node#remove()` only requires sufficient permissions to remove the target node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and verify remove permission on all child nodes/properties. In order to obtain backwards compatible behavior with respect to tree removal the permission evaluation can be configured to traverse down the hierarchy upon removal. This config flag is a best effort approach but doesn't guarantee an identical behavior. h6. Move and Copy _TODO: permission evaluation with copy and move is not yet implemented (OAK-920, OAK-710)_ h6. Version Management Reading and writing items in the version store does not follow the regular permission evaluation but depends on access rights present on the corresponding versionable node. In case the version information does no longer have a versionable node in this workspace that original path is used to evaluate the effective permissions that would apply to that node if the version was restored. Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular JCR write permissions is required in order to execute version operations and thus modify the version store. These changes are covered by OAK-444 and address the concerns summarized in JCR-2963. h6. User Management By default user management operations require the specific user mgt related permission to be granted for the editing subject. This permission (including a corresponding privilege) has been introduced with OAK 1.0. For backwards compatibility with Jackrabbit 2.x this behavior can be turned off by setting the corresponding configuration flag. h5. Administrative Principals h4. 2. Node Types _TODO_ {code} /** * @since oak 1.0 */ [rep:PermissionStore] orderable + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE + * (rep:Permissions) = rep:Permissions protected IGNORE /** * @since oak 1.0 */ [rep:Permissions] - * (UNDEFINED) protected - * (UNDEFINED) protected multiple + * (rep:Permissions) = rep:Permissions protected IGNORE {code} {code} /** * @since oak 1.0 */ [rep:VersionablePaths] mixin - * (PATH) protected ABORT {code} h4. 3. API Extensions org.apache.jackrabbit.oak.spi.security.authorization.permission - {{PermissionProvider}}: _TODO_ - {{Permissions}}: _TODO_ - {{PermissionConstants}}: _TODO_ - {{ReadStatus}}: _work in progress_ h4. 4. Configuration * Permission Configuration ** AccessControlConfiguration#getPermissionProvider: _TODO_ * Configuration Parameters supported by the default implementation ** PARAM_PERMISSIONS_JR2: Enables backwards compatible behavior for the permissions listed in the parameter value. Currently the following values are allowed: "USER_MANAGEMENT" and "REMOVE_NODE". The parameter value must contain the permission names separated by ','. ** PARAM_READ_PATHS: default set of paths that are always readable to all principals irrespective of other permissions defined at that path or inherited from other nodes. ** PARAM_ADMINISTRATOR_PRINCIPALS: The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. h4. 5 References [0] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java > Permissions: Document changes wrt Jackrabbit > -------------------------------------------- > > Key: OAK-942 > URL: https://issues.apache.org/jira/browse/OAK-942 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: doc > Reporter: angela > Assignee: angela > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira