[
https://issues.apache.org/jira/browse/OAK-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/7/13 2:52 PM:
----------------------------------------------------
h4. 1. Characteristics of the Default Implementation
h5. General
h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
h6. AccessControlManager#getEffectivePolicies
h5. Jackrabbit API
h6. Principal-based Access Control
The principal-based access control management as present in Jackrabbit-core is
no longer present with OAK. The main benefit of the principal-based approach
has been incorporated with the changes in the default permission evaluation
(see OAK-942). In addition the default access control manager implementation
supports all methods defined by {{JackrabbitAccessControlManager}}; i.e.
editing access control information by principal is possible as long as the
editing session has sufficient permission on the target node(s). Similarly, the
per principal policies exposed to a given session will always respect that
access rights of that session.
h6. Restrictions
The implementation of the additional restrictions associated with an ACE have
changed in the following aspects:
* Separate restriction management API (see below) on the OAK level that allows
to ease pluggability
* Changed node type definition for storing restrictions in the default
implementation.
** as of OAK restrictions are collected underneath a separate child node
"rep:restrictions"
** restrictions can be multi-valued (see JCR-3637)
** backwards compatible behavior for restrictions stored underneath the ACE
node directly
* New restriction "rep:ntNames", which allows to limit the affect ACE to nodes
of the specified node type(s)
h4. 2. Node Types
As mentioned above the node type definitions have been extended to match the
new functionality related to restrictions.
The node type definition for access control entries:
{code}
[rep:ACE]
- rep:principalName (STRING) protected mandatory
- rep:privileges (NAME) protected mandatory multiple
- rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
- rep:glob (STRING) protected /* deprecated in favor of restrictions */
- * (UNDEFINED) protected /* deprecated in favor of restrictions */
+ rep:restrictions (rep:Restrictions) = rep:Restrictions protected
{code}
The new node type definition for restrictions:
{code}
/**
* @since oak 1.0
*/
[rep:Restrictions]
- * (UNDEFINED) protected
- * (UNDEFINED) protected multiple
{code}
h4. 3. API Extensions and Public Classes
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol
- {{AbstractAccessControlList}}
- {{ImmutableACL}}
- {{ACE}}
org.apache.jackrabbit.oak.spi.security.authorization.restriction
- {{RestrictionProvider}}:
- {{RestrictionDefinition}}
- {{RestrictionPattern}}
- {{Restriction}}
h4. 4. Configuration
The following access control related configuration options are present with the
{{AuthorizationConfiguration}} as of OAK 1.0
- {{getAccessControlManager}}
- {{getRestrictionProvider}}
h4. 5 References
was (Author: anchela):
h4. 1. Characteristics of the Default Implementation
h5. General
h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
h6. AccessControlManager#getEffectivePolicies
h5. Jackrabbit API
h6. Principal-based Access Control
The principal-based access control management as present in Jackrabbit-core is
no longer present with OAK. The main benefit of the principal-based approach
has been incorporated with the changes in the default permission evaluation
(see OAK-942). In addition the default access control manager implementation
supports all methods defined by {{JackrabbitAccessControlManager}}; i.e.
editing access control information by principal is possible as long as the
editing session has sufficient permission on the target node(s). Similarly, the
per principal policies exposed to a given session will always respect that
access rights of that session.
h6. Restrictions
The implementation of the additional restrictions associated with an ACE have
changed in the following aspects:
* Separate restriction management API (see below) on the OAK level that allows
to ease pluggability
* Changed node type definition for storing restrictions in the default
implementation.
** as of OAK restrictions are collected underneath a separate child node
"rep:restrictions"
** restrictions can be multi-valued (see JCR-3637)
** backwards compatible behavior for restrictions stored underneath the ACE
node directly
* New restriction "rep:ntNames", which allows to limit the affect ACE to nodes
of the specified node type(s)
h4. 2. API Extensions and Public Classes
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol
- {{AbstractAccessControlList}}
- {{ImmutableACL}}
- {{ACE}}
org.apache.jackrabbit.oak.spi.security.authorization.restriction
- {{RestrictionProvider}}:
- {{RestrictionDefinition}}
- {{RestrictionPattern}}
- {{Restriction}}
h4. 3. Configuration
The following access control related configuration options are present with the
{{AuthorizationConfiguration}} as of OAK 1.0
- {{getAccessControlManager}}
- {{getRestrictionProvider}}
h4. 4 References
> AccessControl Management: Document changes wrt. Jackrabbit
> ----------------------------------------------------------
>
> Key: OAK-792
> URL: https://issues.apache.org/jira/browse/OAK-792
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: jcr
> 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
