[
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 9:33 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
** 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
was (Author: anchela):
h4. 1. Characteristics of the Default Implementation
h5. General
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}}:
- {{Permissions}}:
- {{ReadStatus}}: _work in progress_
h4. 4. Configuration
* Permission Configuration
** AccessControlConfiguration#getPermissionProvider
* 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
