[
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 8:44 AM:
----------------------------------------------------
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.
This 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
h6. Move and Copy
_TODO: permission evaluation with copy and move is not yet implemented
(OAK-920, OAK-710)_
h6. Version Management
h6. User Management
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
- AccessControlConfiguration#getPermissionProvider
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).
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.
This changes are covered by OAK-444 and address the concerns summarized in
JCR-2963.
h6. Property Modification
h6. Node Removal
h6. Version Management
h6. User Management
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
- AccessControlConfiguration#getPermissionProvider
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
