You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/11/11 12:05:17 UTC
[jira] [Comment Edited] (OAK-792) AccessControl Management:
Document changes wrt. Jackrabbit
[ 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 11/11/13 11:03 AM:
-------------------------------------------------------
h4. 1. Characteristics of the Default Implementation
h5. General
In general the authorization related code in OAK clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation (see also OAK-942).
The default implementation of the access control management corresponds to the resource-based implementation present with Jackrabbit 2.x. The former principal-base access control management is no longer available but it's functionality has been incorporated both in the default ac management implementation and the permission evaluation.
h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
As of OAK those methods throw {{PathNotFoundException}} if the corresponding node is not accessible by the editing session. This is in accordance with the behavior mandated by JSR 283 and a bug in Jackrabbit 2.x.
h6. AccessControlManager#getEffectivePolicies
In contrast to Jackrabbit 2.x the editing session is used to retrieve the effective policies and the policies returned by these methods are guarantueed to only return information that is otherwise accessible by the session. The corresponding methods in Jackrabbit 2.x use to throw an exception in this situation.
h6. AccessControlPolicy
OAK introduces a new type of policy that enforces regular read-access for everyone on the trees that hold this new {{ReadPolicy}} [0]. The main usage of this new policy is to ensure backwards compatible behavior of repository level information (node types, namespace, privileges) that are now kept within the content repository. In Jackrabbit 2.x this information was stored in the file system without the ability to apply or enforce regular access control such as present with items in the repository.
Currently these special read policies are defined as part of the overall security configuration and cannot be managed/edited using regular access control management API (see OAK-951).
h6. AccessControlEntry
Validation: as of OAK the implementation of the {{AccessControlEntry}} interface is no longer in charge of validating the specified privileges. While some validation is still performed in the corresponding {{AccessControlList}} methods, the complete validation is delegated to the commit phase and executed by a specific {{Validator}} implementation.
Restrictions: as of OAK the optional restrictions present with a given {{JackrabbitAccessControlEntry}} can be multivalued (see below).
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 has been modified/extended as follows:
* Separate restriction management API (see below) on the OAK level that allows to ease plugging custom restrictions.
* 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, JCR-3641)
** 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}}
Differences to Jackrabbit 2.x:
The "omit-default-permission" configuration option present with the Jackrabbit's AccessControlProvider implementations is no longer supported with Oak.
As of OAK no extra access control content is installed by default which renders that flag superfluous.
h4. 5 References
[0] ReadPolicy
was (Author: anchela):
h4. 1. Characteristics of the Default Implementation
h5. General
In general the authorization related code in OAK clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation (see also OAK-942).
The default implementation of the access control management corresponds to the resource-based implementation present with Jackrabbit 2.x. The former principal-base access control management is no longer available but it's functionality has been incorporated both in the default ac management implementation and the permission evaluation.
h5. JCR API
h6. AccessControlManager#hasPrivilege and #getPrivileges
As of OAK those methods throw {{PathNotFoundException}} if the corresponding node is not accessible by the editing session. This is in accordance with the behavior mandated by JSR 283 and a bug in Jackrabbit 2.x.
h6. AccessControlManager#getEffectivePolicies
In contrast to Jackrabbit 2.x the editing session is used to retrieve the effective policies and the policies returned by these methods are guarantueed to only return information that is otherwise accessible by the session. The corresponding methods in Jackrabbit 2.x use to throw an exception in this situation.
h6. AccessControlPolicy
OAK introduces a new type of policy that enforces regular read-access for everyone on the trees that hold this new {{ReadPolicy}} [0]. The main usage of this new policy is to ensure backwards compatible behavior of repository level information (node types, namespace, privileges) that are now kept within the content repository. In Jackrabbit 2.x this information was stored in the file system without the ability to apply or enforce regular access control such as present with items in the repository.
_TODO: managing ReadPolicies (OAK-951)_
h6. AccessControlEntry
Validation: as of OAK the implementation of the {{AccessControlEntry}} interface is no longer in charge of validating the specified privileges. While some validation is still performed in the corresponding {{AccessControlList}} methods, the complete validation is delegated to the commit phase and executed by a specific {{Validator}} implementation.
Restrictions: as of OAK the optional restrictions present with a given {{JackrabbitAccessControlEntry}} can be multivalued (see below).
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 has been modified/extended as follows:
* Separate restriction management API (see below) on the OAK level that allows to ease plugging custom restrictions.
* 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, JCR-3641)
** 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}}
Differences to Jackrabbit 2.x:
The "omit-default-permission" configuration option present with the Jackrabbit's AccessControlProvider implementations is no longer supported with Oak.
As of OAK no extra access control content is installed by default which renders that flag superfluous.
h4. 5 References
[0] ReadPolicy
> 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
> Fix For: 0.12
>
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)