[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 11/11/13 11:06 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 restrictions:
** rep:ntNames, which allows to limit the affected ACE to nodes of the
specified node type(s)
** rep:prefixes, which allows to limit the effect to item names that have a
specific namespace prefix.
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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 9/25/13 9:11 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.
_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}}
-
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/8/13 7:30 AM:
h4. 1. Characteristics of the Default Implementation
h5. General
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.
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)
** 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 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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/8/13 7:47 AM:
h4. 1. Characteristics of the Default Implementation
h5. General
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. AccessControlEntry Implementation
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.
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)
** 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
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.
h5. Jackrabbit API
h6. Principal-based Access Control
The principal-based access control management as
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/8/13 10:18 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#getPolicies
OAK introduces a new type of policy that enforces regular read-access for
everyone on the trees that hold this new {{ReadPolicy}}. 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. 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. 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)
** 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}}
-
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/8/13 1:47 PM:
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}}
-
[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-tabpanelfocusedCommentId=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}}
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/7/13 3:43 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 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)
** 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. 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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/7/13 4:49 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 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)
** 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 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)
** 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
[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-tabpanelfocusedCommentId=13718362#comment-13718362 ] angela edited comment on OAK-792 at 8/6/13 12:33 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 h4. 2. API Extensions h4. 3. Configuration h4. 4 References was (Author: anchela): h4. 1. Characteristics of the Default Implementation h5. JCR API h6. Session#hasPermission and #checkPermission h6. AccessControlManager#hasPrivilege and #getPrivileges h6. AccessControlManager#getEffectivePolicies h5. Jackrabbit API h6. Principal-based Access Control h5. Mapping of JCR Actions to Permissions h5. Permission Evaluation h6. Reading h6. Property Modification h6. Node Removal h6. Version Management h6. User Management h5. Administrative Principals h4. 2. API Extensions h4. 3. Configuration 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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/6/13 2:51 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
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
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
h4. 2. API Extensions
h4. 3. Configuration
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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/6/13 3:17 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.
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
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).
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
[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-tabpanelfocusedCommentId=13718362#comment-13718362
]
angela edited comment on OAK-792 at 8/6/13 3:16 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).
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
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
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
