jackrabbit-oak-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mdue...@apache.org
Subject svn commit: r1593224 - in /jackrabbit/oak/branches/1.0: ./ oak-doc/ oak-doc/src/site/markdown/security/ oak-doc/src/site/markdown/security/authentication/ oak-doc/src/site/markdown/security/permission/
Date Thu, 08 May 2014 10:11:08 GMT
Author: mduerig
Date: Thu May  8 10:11:07 2014
New Revision: 1593224

URL: http://svn.apache.org/r1593224
Log:
OAK-301 : oak docu
Merged r1593210

Added:
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/evaluation.md
      - copied unchanged from r1593210, jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md
Modified:
    jackrabbit/oak/branches/1.0/   (props changed)
    jackrabbit/oak/branches/1.0/oak-doc/   (props changed)
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication.md
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/differences.md
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/tokenmanagement.md
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission.md
    jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/differences.md

Propchange: jackrabbit/oak/branches/1.0/
------------------------------------------------------------------------------
  Merged /jackrabbit/oak/trunk:r1593210

Propchange: jackrabbit/oak/branches/1.0/oak-doc/
------------------------------------------------------------------------------
  Merged /jackrabbit/oak/trunk/oak-doc:r1593210

Modified: jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication.md?rev=1593224&r1=1593223&r2=1593224&view=diff
==============================================================================
--- jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication.md (original)
+++ jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication.md Thu May
 8 10:11:07 2014
@@ -88,9 +88,37 @@ Furthermore JCR defines two types of `Cr
 - [javax.jcr.GuestCredentials]: used to obtain a "guest", "public" or "anonymous" session.
 - [javax.jcr.SimpleCredentials]: used to login a user with a userId and password.
 
+The following variants exist for the repository login itself:
+
+- `Repository.login()`: equivalent to passing `null` credentials and the default workspace
name.
+- `Repository.login(Credentials credentials): login with credentials to the default workspace.
+- `Repository.login(String workspace): login with `null` credentials to the workspace with
the specified name.
+- `Repository.login(Credentials credentials, String workspaceName`)
+- `JackrabbitRepository.login(Credentials credentials, String workspaceName, Map<String,
Object> attributes)`:
+  in addition allows to pass implementation specific session attributes.
+
+See [javax.jcr.Repository] and [org.apache.jackrabbit.api.JackrabbitRepository]
+for further details.
+
+In addition JCR defines `Session.impersonate(Credentials)` to impersonate another
+user or - as of JSR 333 -  clone an existing session.
+
 
 ### Oak Authentication
 
+#### General Notes
+
+_todo_
+
+#### Oak API
+
+_todo_
+
+- ContentRepository.login
+- AuthInfo
+- ContentSession.getAuthInfo
+
+
 #### Differences wrt Jackrabbit 2.x
 
 See section [differences](authentication/differences.html) for complete list of
@@ -179,7 +207,62 @@ This login module implementations behave
 
 #### Impersonation
 
-_todo_
+Another flavor of the Oak authentication implementation is covered by
+`javax.jcr.Session#impersonate(Credentials)`, which allows to obtain an new
+`Session` for user identitified by the specified credentials. As of JSR 333
+this method can also be used in order to clone the existing session (i.e.
+self-impersonation of the user that holds the session.
+
+With Oak 1.0 impersonation is implemented as follows:
+
+1. `Session#impersonate` takes any kind of `Credentials`
+2. the specified credentials are wrapped in a new instance of [ImpersonationCredentials]
+   along with the current [AuthInfo] object.
+3. these `ImpersonationCredentials` are passed to `Repository.login`
+
+Whether or not impersonation succeeds consequently both depends on the authentication
+setup and on some implementation specific validation that make sure the
+editing session is allowed to impersonate the user identified by the credentials
+passed to the impersonate call.
+
+With Oak 1.0 only the default login module ([LoginModuleImpl]) is able to deal
+with `ImpersonationCredentials` and applies the following logic:
+
+- **Self-Impersonation**: Any attempt to impersonate the same session will succeed
+  as long as the user is still valid (i.e. exists and has not been disabled).
+- **Regular Impersonation**: Impersonation another user will only succeed if
+  the impersonated user is valid (i.e. exists and is not disabled) _and_ the
+  the user associated with the editing session is allowed to impersonate this
+  user. The latter depends on the [User Management](user.html) implementation
+  specifically on the return value of `User.getImpersonation().allows(Subject subject)`.
+
+##### ImpersonationCredentials
+
+Since the implementation of `Session.impersonate` no longer uses `SimpleCredentials`
+to transport the original `Subject` but rather performs the login with dedicated
+[ImpersonationCredentials], impersonation is no longer restricted to `SimpleCredentials`
+being passed to `Session#impersonate` call. Instead the specified credentials are
+passed to a new instance of `ImpersonationCredentials` delegating the evaluation
+and validation of the specified `Credentials` to the configured login module(s).
+
+This modification will not affect applications that used JCR API to impersonate
+a given session. Note however that applications relying on the Jackrabbit
+implementation and manually creating `SimpleCredentials` with a
+`SecurityConstants.IMPERSONATOR_ATTRIBUTE`, would need to be refactor after
+migration to Oak.
+
+##### Impersonation with Custom Authentication Setup
+
+Applications that wish to use a custom authentication setup need to ensure the
+following steps in order to get JCR impersonation working:
+
+- Respect `ImpersonationCredentials` in the authentication setup.
+- Identify the impersonated from `ImpersonationCredentials.getBaseCredentials`
+  and verify if it can be authenticated.
+- Validate that the editing session is allowed to impersonate: The user associated
+  with the editing session can be identified by the [AuthInfo] obtained from
+  from `ImpersonationCredentials.getImpersonatorInfo()`.
+
 
 #### Token Login
 
@@ -297,6 +380,10 @@ There also exists a utility class that a
 [javax.security.auth.login.Configuration]: http://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html
 [javax.jcr.GuestCredentials]: http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/GuestCredentials.html
 [javax.jcr.SimpleCredentials]: http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/SimpleCredentials.html
+[javax.jcr.Repository]: http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/Repository.html
+[org.apache.jackrabbit.api.JackrabbitRepository]: http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java
+[ImpersonationCredentials]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/ImpersonationCredentials.html
+[AuthInfo]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthInfo.html
 [GuestLoginModule]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/GuestLoginModule.html
 [LoginModuleImpl]: /oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/user/LoginModuleImpl.html
 [com.day.crx.security.ldap.LDAPLoginModule]: http://dev.day.com/docs/en/crx/current/administering/ldap_authentication.html

Modified: jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/differences.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/differences.md?rev=1593224&r1=1593223&r2=1593224&view=diff
==============================================================================
--- jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/differences.md
(original)
+++ jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/differences.md
Thu May  8 10:11:07 2014
@@ -59,21 +59,33 @@ The OAK implementation of `Session#imper
 to transport the original `Subject` but rather performs the login with dedicated
 [ImpersonationCredentials].
 
-With this change the impersonation feature no longer relies on `SimpleCredentials`
-being passed to `Session#impersonate` call. Instead the specified credentials are
-passed to a new instance of `ImpersonationCredentials` delegating the evaluation
-and validation of the specified `Credentials` to the configured login module(s).
-
 This modification will not affect applications that used JCR API to impersonate
 a given session. However the following example which 'manually' builds impersonation
-credentials the way jackrabbit core was handling it will no longer work to
+credentials the way jackrabbit core was handling it will **no longer work** to
 impersonate an existing session:
 
-     SessionImpl sImpl = (SessionImpl) mySession;
+     org.apache.jackrabbit.core.SessionImpl sImpl = (SessionImpl) mySession;
      SimpleCredentials jrImpCreds = new SimpleCredentials("someUserId, new char[0]);
      creds.setAttribute(SecurityConstants.IMPERSONATOR_ATTRIBUTE, sImpl.getSubject());
      Session impersonated = sImpl.getRepository().login(jrImpCreds, sImpl.getWorkspace().getName());
 
+Upon migration to Oak such implementation specific code should be refactored
+to use regular JCR API for impersonation:
+
+     // Note: build credentials depends on the auth setup !
+     Credentials impersonationCredentials = new SimpleCredentials("someUserId, new char[0]);
+     Session impersonated = session.impersonate(impersonationCredentials);
+
+In order to achieve impersonation on the Oak API directly:
+
+     ContentRepository contentRepo = ...
+     ContentSession editingSession = ...
+
+     AuthInfo impersonatorInfo = editingSession.getAuthInfo();
+     Credentials credentials = new SimpleCredentials("someUserId, new char[0]);
+     ImpersonationCredentials impersonationCredentials = new ImpersonationCredentials(credentials,
impersonatorInfo);
+     ContentSession impersonated = contentRepo.login(impersonationCredentials, editingSession.getWorkspaceName());
+
 #### Token based Authentication
 
 The token based authentication has been completely refactor in Oak as described

Modified: jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/tokenmanagement.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/tokenmanagement.md?rev=1593224&r1=1593223&r2=1593224&view=diff
==============================================================================
--- jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/tokenmanagement.md
(original)
+++ jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/authentication/tokenmanagement.md
Thu May  8 10:11:07 2014
@@ -42,10 +42,10 @@ extended at runtime (see section Configu
 
 The `TokenLoginModule` itself behaves as follows:
 
-upon login()
+*Phase 1: Login*
 _todo_
 
-upon commit()
+*Phase 1: Commit*
 _todo_
 
 ### Token Management API

Modified: jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission.md?rev=1593224&r1=1593223&r2=1593224&view=diff
==============================================================================
--- jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission.md (original)
+++ jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission.md Thu May 
8 10:11:07 2014
@@ -15,11 +15,170 @@
    limitations under the License.
 -->
 
-Permission Evaluation
+Permissions
 --------------------------------------------------------------------------------
 
-_TODO_
+### JCR API
 
-### Differences wrt Jackrabbit 2.x
+_todo_
 
-see the corresponding [documentation](permission/differences.html).
\ No newline at end of file
+**`Session#hasPermission` and `Session#checkPermission`**
+
+_todo_
+
+**JCR Actions**
+
+_todo_
+
+##### Mapping of JCR Actions to Oak Permissions
+
+`ACTION_READ':
+
+- access control content: `Permissions.READ_ACCESS_CONTROL`
+- regular nodes: `Permissions.READ_NODE`
+- regular properties: `Permissions.READ_PROPERTY`
+- non-existing items: `Permissions.READ`
+
+`ACTION_ADD_NODE`:
+
+- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
+- regular nodes: `Permissions.ADD_NODE`
+
+`ACTION_REMOVE`:
+
+- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
+- regular nodes: `Permissions.REMOVE_NODE`
+- regular properties: `Permissions.REMOVE_PROPERTY`
+- non-existing nodes: `Permissions.REMOVE`
+
+`ACTION_SET_PROPERTY`:
+
+- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
+- regular properties: `Permissions.MODIFY_PROPERTY`
+- non-existing properties: `Permissions.ADD_PROPERTY`
+
+**Note**
+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)`).
+
+
+### Oak API
+
+_todo_
+
+#### Built-in Permissions
+
+The set of permissions supported by Oak are listed in [Permissions]. 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.
+- `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node
and it's subtree which is expected to contain the index definitions.
+
+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`
+
+#### New Permissions
+
+_todo_
+
+- `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.
+- `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node
and it's subtree which is expected to contain the index definitions.
+
+
+### Characteristics of the Permission Evaluation
+
+#### General Notes
+
+In general the permission evaluation related code in Oak is intended to be
+more clearly separated from the access control management such as defined by the
+JCR and Jackrabbit API. While permission evaluation is considered to be an
+internal feature of the Oak core module, the package
+`org.apache.jackrabbit.oak.spi.security.authorization.permission` provides some
+extensions points that allow to plug custom extensions or implementations of
+the permission evaluation.
+
+#### Differences wrt Jackrabbit 2.x
+
+see the corresponding [documentation](permission/differences.html).
+
+
+#### Permission Representation in the Repository
+
+_todo_
+
+    [rep:PermissionStore]
+      - rep:accessControlledPath (STRING) protected IGNORE
+      - rep:numPermissions (LONG) protected IGNORE
+      - rep:modCount (LONG) protected IGNORE
+      + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
+      + * (rep:Permissions) = rep:Permissions protected IGNORE
+
+    [rep:Permissions]
+      - * (UNDEFINED) protected IGNORE
+      - * (UNDEFINED) protected multiple IGNORE
+      + * (rep:Permissions) = rep:Permissions protected IGNORE
+
+    [rep:VersionablePaths]
+      mixin
+      - * (PATH) protected ABORT
+
+
+#### Administrative Access
+In the default implementation following principals always have full access to
+the whole content repository (except for hidden items that are not exposed
+on the Oak API) irrespective of the access control content:
+
+- `SystemPrincipal`
+- All instances of `AdminPrincipal`
+- All principals whose name matches the configured administrative principal names (see Configuration
section below). This configuration only applies to the permission evaluation and is currently
not reflected in other security models nor methods that deal with the administrator (i.e.
`User#isAdmin`).
+
+
+#### Detains on Permission Evaluation
+
+_todo_
+
+see [details](permission/evaluation.html)
+
+
+### API Extensions
+
+_todo_
+
+org.apache.jackrabbit.oak.spi.security.authorization.permission
+
+- `PermissionProvider`: Main entry point for Oak internal permission evaluation.
+- `Permissions`: The permissions defined, respected and evaluated by the repository.
+- `PermissionConstants`: Constants used throughout the permission evaluation.
+
+
+### Configuration
+
+- [AuthorizationConfiguration]: _todo_
+
+
+Configuration Parameters supported by the default implementation
+
+- `PARAM_PERMISSIONS_JR2`: Enables backwards compatible behavior for the permissions listed
in the parameter value. Currently the following values are allowed: `USER_MANAGEMENT` and
`REMOVE_NODE`. The parameter value must contain the permission names separated by ','.
+- `PARAM_READ_PATHS`: default set of paths that are always readable to all principals irrespective
of other permissions defined at that path or inherited from other nodes.
+- `PARAM_ADMINISTRATIVE_PRINCIPALS`: The names of the additional principals that have full
permission and for which the permission evaluation can be skipped altogether.
+
+Differences to Jackrabbit 2.x
+The `omit-default-permission` configuration option present with the Jackrabbit's AccessControlProvider
implementations is no longer supported with Oak.
+Since there are no permissions installed by default this flag has become superfluous.
+
+#### Write Custom Permission Evaluation
+
+_todo_
+
+
+
+<!-- references -->
+[Permissions]: /oak/docs/apidocs/org/apache/jackrabbit/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.html
+[AuthorizationConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html

Modified: jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/differences.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/differences.md?rev=1593224&r1=1593223&r2=1593224&view=diff
==============================================================================
--- jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/differences.md
(original)
+++ jackrabbit/oak/branches/1.0/oak-doc/src/site/markdown/security/permission/differences.md
Thu May  8 10:11:07 2014
@@ -14,78 +14,28 @@
    See the License for the specific language governing permissions and
    limitations under the License.
   -->
-### Permission Evaluation : Differences wrt Jackrabbit 2.x
+### Permissions : Differences wrt Jackrabbit 2.x
 
-#### 1. Characteristics of the Default Implementation
+#### General Notes
 
-##### General
-In general the permission evaluation related code in Oak is intended to be
-more clearly separated from the access control management such as defined by the
-JCR and Jackrabbit API. While permission evaluation is considered to be an
-internal feature of the Oak core module, the package
-`org.apache.jackrabbit.oak.spi.security.authorization.permission` provides some
-extensions points that allow to plug custom extensions or implementations of
-the permission evaluation.
+_todo_
 
-##### JCR API
-###### `Session#hasPermission` and `Session#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)`).
-
-##### Mapping of JCR Actions to Permissions
-
-`ACTION_READ':
-
-- access control content: `Permissions.READ_ACCESS_CONTROL`
-- regular nodes: `Permissions.READ_NODE`
-- regular properties: `Permissions.READ_PROPERTY`
-- non-existing items: `Permissions.READ`
-
-`ACTION_ADD_NODE`:
-
-- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
-- regular nodes: `Permissions.ADD_NODE`
-
-`ACTION_REMOVE`:
-
-- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
-- regular nodes: `Permissions.REMOVE_NODE`
-- regular properties: `Permissions.REMOVE_PROPERTY`
-- non-existing nodes: `Permissions.REMOVE`
+##### Permissions
 
-`ACTION_SET_PROPERTY`:
+The following permissions are now an aggregation of new permissions:
 
-- access control content: `Permissions.MODIFY_ACCESS_CONTROL`
-- regular properties: `Permissions.MODIFY_PROPERTY`
-- non-existing properties: `Permissions.ADD_PROPERTY`
+- `READ`: aggregates `READ_NODE` and `READ_PROPERTY`
+- `SET_PROPERTY`: aggregates `ADD_PROPERTY`, `MODIFY_PROPERTY` and `REMOVE_PROPERTY`
 
-##### Permissions
-The set of permissions supported by Oak are listed in [Permissions]. The following changes
have been compared compared to Jackrabbit 2.x:
+The following permissions have been introduced with Oak 1.0:
 
-- `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.
 - `INDEX_DEFINITION_MANAGEMENT`: permission to create, modify and remove the oak:index node
and it's subtree which is expected to contain the index definitions.
 
-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`
-
-#### 2. Permission Evaluation
+#### Permission Evaluation
 
 ##### 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
@@ -94,12 +44,18 @@ Jackrabbit 2.x doesn't apply any special
 and address the concerns summarized in [JCR-2963].
 
 ##### 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.
+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.
 
 ##### Node Removal
-As of Oak `Node#remove()` only requires sufficient permissions to remove the target node.
In contrast to Jackrabbit 2.x the validation will not traverse the tree and verify remove
permission on all child nodes/properties.
-In order to obtain backwards compatible behavior with respect to tree removal the permission
evaluation can be configured to traverse down the hierarchy upon removal. This config flag
is a best effort approach but doesn't guarantee an identical behavior.
+As of Oak `Node#remove()` only requires sufficient permissions to remove the target
+node. In contrast to Jackrabbit 2.x the validation will not traverse the tree and
+verify remove permission on all child nodes/properties.
+In order to obtain backwards compatible behavior with respect to tree removal the
+permission evaluation can be configured to traverse down the hierarchy upon removal.
+This config flag is a best effort approach but doesn't guarantee an identical behavior.
 
 ##### Rename
 Due to the nature of the diff mechanism in Oak it is not possible to distinguish
@@ -134,69 +90,24 @@ requires `REMOVE_NODE` permission on the
 permissions at the destination.
 
 ##### User Management
-By default user management operations require the specific user mgt related permission to
be granted for the editing subject. This permission (including a corresponding privilege)
has been introduced with Oak 1.0.
-For backwards compatibility with Jackrabbit 2.x this behavior can be turned off by setting
the corresponding configuration flag.
+By default user management operations require the specific user mgt related
+permission to be granted for the editing subject. This permission (including a
+corresponding privilege) has been introduced with Oak 1.0.
+For backwards compatibility with Jackrabbit 2.x this behavior can be turned off
+by setting the corresponding configuration flag.
 
 ##### Version Management
-Reading and writing items in the version store does not follow the regular permission evaluation
but depends on access rights present on the corresponding versionable node. In case the version
information does no longer have a versionable node in this workspace that original path is
used to evaluate the effective permissions that would apply to that node if the version was
restored.
-Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular JCR write
permissions is required in order to execute version operations and thus modify the version
store. These changes are covered by [OAK-444] and address the concerns summarized in [JCR-2963].
-
-##### Query Index Definitions
-Writing query index definitions requires the specific index definition management
-which is enforce on nodes named "oak:index" and the subtree defined by them.
-Note that the corresponding items are not protected in the JCR sense. Consequently
-any other modification in these subtrees like e.g. changing the primary type
-or adding mixin types is governed by the corresponding privileges.
-
-#### 3. Administrative Principals
-The following principals always have full access to the whole content repository irrespective
of the access control content:
-
-- `SystemPrincipal`
-- All instances of `AdminPrincipal`
-- All principals whose name matches the configured administrative principal names (see Configuration
section below). This configuration only applies to the permission evaluation and is currently
not reflected in other security models nor methods that deal with the administrator (i.e.
`User#isAdmin`).
-
-#### 4. Node Types
-
-    [rep:PermissionStore]
-      - rep:accessControlledPath (STRING) protected IGNORE
-      - rep:numPermissions (LONG) protected IGNORE
-      - rep:modCount (LONG) protected IGNORE
-      + * (rep:PermissionStore) = rep:PermissionStore protected IGNORE
-      + * (rep:Permissions) = rep:Permissions protected IGNORE
-
-    [rep:Permissions]
-      - * (UNDEFINED) protected IGNORE
-      - * (UNDEFINED) protected multiple IGNORE
-      + * (rep:Permissions) = rep:Permissions protected IGNORE
-
-    [rep:VersionablePaths]
-      mixin
-      - * (PATH) protected ABORT
-
-#### 5. API Extensions
-
-org.apache.jackrabbit.oak.spi.security.authorization.permission
-
-- `PermissionProvider`: Main entry point for Oak internal permission evaluation.
-- `Permissions`: The permissions defined, respected and evaluated by the repository.
-- `PermissionConstants`: Constants used throughout the permission evaluation.
-
-#### 6. Configuration
-
-Configuration Parameters supported by the default implementation
-
-- `PARAM_PERMISSIONS_JR2`: Enables backwards compatible behavior for the permissions listed
in the parameter value. Currently the following values are allowed: `USER_MANAGEMENT` and
`REMOVE_NODE`. The parameter value must contain the permission names separated by ','.
-- `PARAM_READ_PATHS`: default set of paths that are always readable to all principals irrespective
of other permissions defined at that path or inherited from other nodes.
-- `PARAM_ADMINISTRATIVE_PRINCIPALS`: The names of the additional principals that have full
permission and for which the permission evaluation can be skipped altogether.
-
-Differences to Jackrabbit 2.x
-The `omit-default-permission` configuration option present with the Jackrabbit's AccessControlProvider
implementations is no longer supported with Oak.
-Since there are no permissions installed by default this flag has become superfluous.
+Reading and writing items in the version store does not follow the regular permission
+evaluation but depends on access rights present on the corresponding versionable node.
+In case the version information does no longer have a versionable node in this workspace
+that original path is used to evaluate the effective permissions that would apply
+to that node if the version was restored.
+Note, that as in Jackrabbit VERSION_MANAGEMENT permission instead of the regular
+JCR write permissions is required in order to execute version operations and thus
+modify the version store. These changes are covered by [OAK-444] and address the
+concerns summarized in [JCR-2963].
 
 <!-- hidden references -->
 [Permissions]: http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.java
 [OAK-444]: https://issues.apache.org/jira/browse/OAK-444
-[OAK-792]: https://issues.apache.org/jira/browse/OAK-792
-[OAK-910]: https://issues.apache.org/jira/browse/OAK-910
-[OAK-710]: https://issues.apache.org/jira/browse/OAK-710
 [JCR-2963]: https://issues.apache.org/jira/browse/JCR-2963
\ No newline at end of file



Mime
View raw message