[ 
https://issues.apache.org/jira/browse/OAK-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720871#comment-13720871
 ] 

angela edited comment on OAK-910 at 11/5/13 1:09 PM:
-----------------------------------------------------

h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type definition.  In addition 
a specific privilege {{Validator}} and {{CommitHook}} implementations assert 
the consistency of the privilege store. The built-in privileges are installed 
using a dedicated implementation of the {{RepositoryInitializer}} [0].

h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves 
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the 
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that 
modifications made on the OAK API directly is equally verified. Subsequently 
any violation (permission, privilege consistency) is only detected at the end 
of the registration process. The privilege manager itself does not perform any 
validation.

h4. 2. Built-in Privilege Definitions

* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties

Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties, 
rep:alterProperties and rep:removeProperties

h4. 3. Node Type Definitions

The following privilege related built-in node types have been added in OAK 1.0. 
They are used to represent built-in and custom privilege definitions in the 
repository.

{code}
[rep:Privileges]
  + * (rep:Privilege) = rep:Privilege protected ABORT
  - rep:next (LONG) protected multiple mandatory

[rep:Privilege]
  - rep:isAbstract (BOOLEAN) protected
  - rep:aggregates (NAME) protected multiple
  - rep:bits (LONG) protected multiple mandatory
{code}

h4. 4. API Extensions

org.apache.jackrabbit.oak.spi.security.privilege
- {{PrivilegeBitsProvider}} : Provider implementation to read {{PrivilegeBits}} 
from the repository content and map names to internal representation (and vice 
versa).
- {{PrivilegeBits}}: Internal representation of JCR privileges.

h4. 5. Configuration

* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} -> returns a new instance of the 
{{PrivilegeManager}} interface such as exposed by 
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default 
implementation is based on OAK API and can equally be used for privilege 
related tasks in the OAK layer.

h4. 6. References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java


was (Author: anchela):
h4. 1. Characteristics of the Privilege Management Implementation

h5. General Notes
As of OAK the built-in and custom privileges are stored in the repository 
underneath {{/jcr:system/rep:privileges}}. Similar to other repository level 
date (node types, namespaces and versions) this location is shared by all 
workspaces present in the repository. The nodes and properties storing the 
privilege definitions are protected by their node type definition.  In addition 
a specific privilege {{Validator}} and {{CommitHook}} implementations assert 
the consistency of the privilege store. The built-in privileges are installed 
using a dedicated implementation of the {{RepositoryInitializer}} [0].

h5. Registration of Custom Privileges
As far as registration of custom privileges the OAK implementation behaves 
different to Jackrabbit 2.x in the following aspects:
* Registration of new privileges fails with {{IllegalStateException}} if the 
editing session has pending changes.
* Any validation is performed by CommitHooks in order to make sure that 
modifications made on the OAK API directly is equally verified. Subsequently 
any violation (permission, privilege consistency) is only detected at the end 
of the registration process. The privilege manager itself does not perform any 
validation.

h4. 2. Built-in Privilege Definitions

* All Privileges as defined by JSR 283
** jcr:read
** jcr:modifyProperties
** jcr:addChildNodes
** jcr:removeNode
** jcr:removeChildNodes
** jcr:readAccessControl
** jcr:modifyAccessControl
** jcr:lockManagement
** jcr:versionManagement
** jcr:nodeTypeManagement
** jcr:retentionManagement (NOTE: retention management not yet implemented)
** jcr:lifecycleManagement (NOTE: lifecycle management not yet implemented)
** jcr:write
** jcr:all
* All Privileges defined by JSR 333
** jcr:workspaceManagement (NOTE: wsp management not yet implemented)
** jcr:nodeTypeDefinitionManagement
** jcr:namespaceManagement
* All Privileges defined by Jackrabbit 2.x
** rep:write
** rep:privilegeManagement
* New Privileges defined by OAK 1.0:
** rep:userManagement
** rep:readNodes
** rep:readProperties
** rep:addProperties
** rep:alterProperties
** rep:removeProperties

Note the following differences with respect to Jackrabbit 2.x definitions:
* jcr:read is now an aggregation of rep:readNodes and rep:readProperties
* jcr:modifyProperties is now an aggregation of rep:addProperties, 
rep:alterProperties and rep:removeProperties

h4. 3. Node Type Definitions

The following privilege related built-in node types have been added in OAK 1.0. 
They are used to represent built-in and custom privilege definitions in the 
repository.

{code}
[rep:Privileges]
  + * (rep:Privilege) = rep:Privilege protected ABORT
  - rep:next (LONG) protected multiple mandatory

[rep:Privilege]
  - rep:isAbstract (BOOLEAN) protected
  - rep:aggregates (NAME) protected multiple
  - rep:bits (LONG) protected multiple mandatory
{code}

h4. 4. API Extensions

-

h4. 5. Configuration

* {{PrivilegeConfiguration}} [1]:
** {{getPrivilegeManager}} -> returns a new instance of the 
{{PrivilegeManager}} interface such as exposed by 
{{JackrabbitWorkspace#getPrivilegeManager}}. Note that the default 
implementation is based on OAK API and can equally be used for privilege 
related tasks in the OAK layer.

h4. 6. References

[0] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/privilege/PrivilegeInitializer.java
[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.java

> Privilege Management: Document changes wrt Jackrabbit
> -----------------------------------------------------
>
>                 Key: OAK-910
>                 URL: https://issues.apache.org/jira/browse/OAK-910
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core, jcr
>            Reporter: angela
>            Assignee: angela
>




--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to