You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-commits@jackrabbit.apache.org by an...@apache.org on 2016/02/10 18:12:27 UTC
svn commit: r1729662 [2/3] - in
/jackrabbit/oak/trunk/oak-doc/src/site/markdown: ./ oak_api/ security/
security/accesscontrol/ security/authentication/ security/authorization/
security/permission/ security/principal/ security/privilege/ security/user/
Added: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/introduction.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/introduction.md?rev=1729662&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/introduction.md (added)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/introduction.md Wed Feb 10 17:12:26 2016
@@ -0,0 +1,105 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+Introduction to Oak Security
+--------------------------------------------------------------------------------
+
+### General
+
+The main entry point to Oak security is the `SecurityProvider`, which is registered
+to the Oak repository upon creation. The provider is in charge of collecting and
+exposing all security related modules present in a given Oak repository.
+
+Each security module comes with one or multiple `SecurityConfiguration`(s) that
+is registered with the provider, identified (and possibly aggregated) by their
+name.
+
+### Modules
+
+Currently Oak comes with the following built-in security modules, each defined
+by a dedicated sub-interfaces of [SecurityConfiguration]:
+
+- Authentication
+ - Authentication s.str.
+ - Token Authentication and Token Management
+- Authorization
+ - Authorization s.str.
+ - Privilege Management
+- Principal Management
+- User Management
+
+<a name="api_extensions"/>
+### API Extensions
+
+The package `org.apache.jackrabbit.oak.spi.security` defines the following interfaces
+and base implementations:
+
+- [SecurityProvider]: Main entry point for Oak security.
+ - [OpenSecurityProvider]: Rudimentary implementation for test purpose.
+- [SecurityConfiguration]: Base interface for all security related configurations.
+ - [ConfigurationBase]: Abstract base implementation of the `SecurityConfiguration` interface.
+ - [CompositeConfiguration]: Abstract base implementation for all composite configurations that allow for aggregation of multiple modules.
+- [ConfigurationParameters]: Utility used to pass around parameters and options.
+- [Context]: Context information associated with a given `SecurityConfiguration` that allow to identify items defined and maintained by a give security module implementation.
+
+#### SecurityProvider
+
+_TODO
+ The interface allow to access the available `SecurityConfiguration`s
+ defining the individual modules. In addition this provider gives access
+ to the configuration parameters that apply to the configurations with the
+ specified `SecurityConfiguration#getName() name`._
+
+ _ TODO: registration of the security provider_
+
+#### SecurityConfiguration
+
+ _TODO_
+
+ - [AuthenticationConfiguration]
+ - [TokenConfiguration] : multiple
+ - [AuthorizationConfiguration] : multiple since Oak 1.4
+ - [PrivilegeConfiguration]
+ - [PrincipalConfiguration], multiple
+ - [UserConfiguration]
+
+ _TODO_
+
+<a name="configuration"/>
+### Configuration
+
+_TODO_
+
+<a name="pluggability"/>
+### Pluggability
+
+_TODO_
+
+<!-- references -->
+[SecurityProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityProvider.html
+[OpenSecurityProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/OpenSecurityProvider.html
+[SecurityConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityConfiguration.html
+[CompositeConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/CompositeConfiguration.html
+[ConfigurationBase]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/ConfigurationBase.html
+[ConfigurationParameters]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/ConfigurationParameters.html
+[Context]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/Context.html
+[AuthenticationConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthenticationConfiguration.html
+[TokenConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/TokenConfiguration.html
+[AuthorizationConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html
+[PrincipalConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.html
+[PrivilegeConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.html
+[UserConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/user/UserConfiguration.html
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/overview.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/overview.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/overview.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/overview.md Wed Feb 10 17:12:26 2016
@@ -18,34 +18,52 @@
The Oak Security Layer
--------------------------------------------------------------------------------
+### General
+
+ * [Introduction to Oak Security](introduction.html)
+
### Authentication
* [Overview](authentication.html)
* [Differences wrt Jackrabbit 2.x](authentication/differences.html)
+ * [Authentication : Implementation Details](authentication/default.html)
* [Token Authentication and Token Management](authentication/tokenmanagement.html)
* [External Authentication](authentication/externalloginmodule.html)
- * [User and Group Synchronization](authentication/usersync.html)
- * [Identity Management](authentication/identitymanagement.html)
- * [LDAP Integration](authentication/ldap.html)
+ * [User and Group Synchronization](authentication/usersync.html)
+ * [Identity Management](authentication/identitymanagement.html)
+ * [LDAP Integration](authentication/ldap.html)
* [Pre-Authentication](authentication/preauthentication.html)
-### Access Control
+### Authorization
+
+ * [Overview](authorization.html)
+
+#### Access Control Management
* [Overview](accesscontrol.html)
* [Differences wrt Jackrabbit 2.x](accesscontrol/differences.html)
- * [Restriction Management](accesscontrol/restriction.html)
+ * [Access Control Management : The Default Implementation](accesscontrol/default.html)
+ * [Restriction Management](authorization/restriction.html)
* [Using the API](accesscontrol/editing.html)
-### Permissions
+#### Permissions
* [Overview](permission.html)
* [Differences wrt Jackrabbit 2.x](permission/differences.html)
- * [Permission Evaluation in Detail](permission/evaluation.html)
-
-### Privilege Management
+ * [Permissions : The Default Implementation](permission/default.html)
+ * [Permission Evaluation in Detail : The Default Implementation](permission/evaluation.html)
+
+#### Privilege Management
* [Overview](privilege.html)
* [Differences wrt Jackrabbit 2.x](privilege/differences.html)
+ * Mapping Privileges to Items and API Calls
+ * [Mapping Privileges to Items](privilege/mappingtoitems.html)
+ * [Mapping API Calls to Privileges](privilege/mappingtoprivileges.html)
+
+#### Extensions
+
+ * [Managing Access with Closed User Groups (CUG)](authorization/cug.html)
### Principal Management
@@ -56,9 +74,10 @@ The Oak Security Layer
* [Overview](user.html)
* [Differences wrt Jackrabbit 2.x](user/differences.html)
- * [Group Membership](user/membership.html)
- * [Authorizable Actions](user/authorizableaction.html)
- * [Authorizable Node Name Generation](user/authorizablenodename.html)
- * [Searching Users and Groups](user/query.html)
- * [Password Expiry and Force Initial Password Change](user/expiry.html)
-
+ * [User Management : The Default Implementation](user/default.html)
+ * [Group Membership](user/membership.html)
+ * [Searching Users and Groups](user/query.html)
+ * [Authorizable Actions](user/authorizableaction.html)
+ * [Authorizable Node Name Generation](user/authorizablenodename.html)
+ * [Password Expiry and Force Initial Password Change](user/expiry.html)
+ * [Password History](user/history.html)
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission.md Wed Feb 10 17:12:26 2016
@@ -18,6 +18,7 @@
Permissions
--------------------------------------------------------------------------------
+<a href="jcr_api"/>
### JCR API
While access control management is a optional feature, a JCR implementation is
@@ -224,20 +225,31 @@ regular JCR write permissions. This affe
permission `USER_MANAGEMENT` to be granted for the editing subject. This permission (including a corresponding privilege)
has been introduced with Oak 1.0. See below for configuration parameters to obtain backwards compatible behavior.
+<a name="api_extensions"/>
+### API Extensions
-### Characteristics of the Permission Evaluation
+Due to the separation of access control management from permission evaluation,
+Oak 1.0 comes with a dedicated API for permission discovery that is used both
+for the repository internal permission evaluation as well as for permission
+discovery at JCR level.
-#### General Notes
+The package `org.apache.jackrabbit.oak.spi.security.authorization.permission`
+defines the following interfaces and classes:
+
+- [PermissionProvider]: Main entry point for permission discovery and evaluation.
+ - [TreePermission]: Evaluates the permissions of a given Oak `Tree`, exposed by `PermissionProvider`.
+ - [RepositoryPermission]: Evaluates the repository level permissions, exposed by `PermissionProvider`.
+- [AggregatedPermissionProvider]: Extension of the [PermissionProvider] required for implementations that are intended to be used in an aggregation of multiple providers (since Oak 1.4)
+- [Permissions]: The permissions defined, respected and evaluated by the repository.
+- [PermissionConstants]: Constants used throughout the permission evaluation.
+
+### Characteristics of the Permission Evaluation
As explained above permission evaluation is completely separated from the access
control management and the associated ccontent. The evaluation itself is done by
the configured `PermissionProvider`.
-The default implementation of the `PermissionProvider` interface evaluates permissions
-based on the information stored in a dedicated part of the repository content call
-the [permission store](#permissionStore).
-
-Similar each JCR `Session` (and Oak `ContentSession`) gets it's own `PermissionProvider`
+Each JCR `Session` (and Oak `ContentSession`) gets it's own `PermissionProvider`
associated with the current repository revision the session is operating on. The
evaluated permissions and caches are not shared between different sessions even
if they represent the same subject.
@@ -246,160 +258,13 @@ if they represent the same subject.
see the corresponding [documentation](permission/differences.html).
-#### Details on Permission Evaluation
+#### Details on the Default Permission Evaluation
-##### 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`).
-
-##### Readable Trees
-
-Oak 1.0 comes with a configurable set of subtrees that are read-accessible to all
-subjects irrespective of other access control content taking effect. The original
-aim of these readable trees is to assert full acccess to namespace, nodetype and
-privilege information and the corresponding configuration therefore lists the
-following paths:
-
-- `/jcr:system/rep:namespaces`: stores all registered namespaces
-- `/jcr:system/jcr:nodeTypes`: stores all registered node types
-- `/jcr:system/rep:privileges`: stores all registered privileges
-
-This default set can be changed or extended by setting the corresponding configuration
-option. However, it is important to note that many JCR API calls rely on the
-accessibility of the namespace, nodetype and privilege information. Removing the
-corresponding paths from the configuration will most probably have undesired effects.
-
-##### Regular Permission Evaluation
-
-See section [Permission Evaluation in Detail](permission/evaluation.html).
-
-#### Permission Representation in the Repository
-
-<a name="permissionStore"/>
-##### Permission Store
-
-The permission evaluation present with Oak 1.0 keeps a dedicated location where
-permissions are being stored for later evaluation. The store is kept in sync
-with the access control content by a separated `PostValidationHook` implementation ([PermissionHook]).
-
-The location of the permission store is `/jcr:system/rep:permissionStore`; in
-accordance with other stores underneath `jcr:system` it is global to the whole
-repository keeping a separate entry for each workspace present with the repository.
-
-The permission entries are grouped by principal and stored below the store root
-based on the hash value of the path of the access controlled node; hash collisions
-are handled by adding subnodes accordingly.
-
- /jcr:system/rep:permissionStore/workspace-name [rep:PermissionStore]
- /principal-name [rep:PermissionStore]
- /1259237738 [rep:PermissionStore]
- /0 [rep:Permissions]
- /1 [rep:Permissions]
- /c0 [rep:PermissionStore] # hash collision
- /0 [rep:Permissions]
- /1 [rep:Permissions]
- /2 [rep:Permissions]
- /c1 [rep:PermissionStore] # hash collision
- /0 [rep:Permissions]
- /1 [rep:Permissions]
- /2 [rep:Permissions]
- /47 [rep:PermissionStore]
- /0 [rep:Permissions]
- /1 [rep:Permissions]
-
-Each per path store looks as follows
-
- "1259237738" {
- "jcr:primaryType": "rep:PermissionStore",
- "rep:accessControlledPath": "/content",
- "0": {
- "jcr:primaryType": "rep:Permissions",
- "rep:isAllow": false,
- "rep:privileges": [32],
- "rep:ntNames": ["nt:unstructured", "oak:Unstructured"]
- ... /* additional restrictions as present in the entry */
- }
- }
-
-###### Accessing the Permission Store
-
-It is important to understand that the permission store is a implementation
-specific structure that is maintained by the system itself. For this reason
-access to the permission store is additionally restricted superimposing the
-regular permissions being enforced for regular repository items.
-
-In detail this means that the permission store cannot be written by JCR nor Oak
-API method calls. It's immutability is enforced by a dedicated `FailingValidator`
-that prevents any modifications underneath `/jcr:system/rep:permissionStore`.
-Similarly read access is not allowed except for system principals. In order to
-discover and display access control related information API consumers should
-use the regular JCR and Jackrabbit permission and access control management API
-as listed above and in section [Using the Access Control Management API](accesscontrol/editing.html).
-
-
-##### Node Type Definitions
-
-For the permission store the following built-in node types have been defined:
-
- [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
-
-In addition Oak 1.0 defines a specific mixin type that allows to store the path(s)
-of the versionable node with each version history. Adding this mixing and updating
-the versionable path information is taken care of by a dedicated commit hook
-implementation (`VersionablePathHook`).
-
- [rep:VersionablePaths]
- mixin
- - * (PATH) protected ABORT
-
-<a name="validation"/>
-##### Validation
-
-The consistency of this content structure is asserted by a dedicated `PermissionValidator`.
-The corresponding errors are all of type `Access` with the following codes:
-
-| Code | Message |
-|-------------------|----------------------------------------------------------|
-| 0000 | Generic access violation |
-| 0021 | Version storage: Node creation without version history |
-| 0022 | Version storage: Removal of intermediate node |
-
-<a name="api_extensions"/>
-### API Extensions
-
-Due to the separation of access control management from permission evaluation,
-Oak 1.0 comes with a dedicated API for permission discovery that is used both
-for the repository internal permission evaluation as well as for permission
-discovery at JCR level.
-
-The package `org.apache.jackrabbit.oak.spi.security.authorization.permission`
-defines the following interface:
-
-- [PermissionProvider]: Main entry point for permission discovery and evaluation.
- - [TreePermission]: Evaluates the permissions of a given Oak `Tree`, exposed by `PermissionProvider`.
- - [RepositoryPermission]: Evaluates the repository level permissions, exposed by `PermissionProvider`.
-- [Permissions]: The permissions defined, respected and evaluated by the repository.
-- [PermissionConstants]: Constants used throughout the permission evaluation.
+The behavior of the default permission implementation is described in sections
+[Permissions: The Default Implementation](permission/default.html) and
+[Permission Evaluation in Detail: The Default Implementation](permission/evaluation.html).
+<a name="configuration"/>
### Configuration
The configuration of the permission evaluation implementation is handled
@@ -411,37 +276,13 @@ methods:
#### Configuration Parameters
-The default implementation supports the following configuration parameters:
-
-| Parameter | Type | Default | Description |
-|-----------------------------------|---------------------|----------|-------------|
-| `PARAM_PERMISSIONS_JR2` | String | \- | Enables backwards compatible behavior for the permissions listed in the parameter value containing the permission names separated by ','. Supported values are: `USER_MANAGEMENT`,`REMOVE_NODE` |
-| `PARAM_READ_PATHS` | Set\<String\> | paths to namespace, nodetype and privilege root nodes | 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` | String[] | \- | The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. |
-| | | | |
-
-##### Supported Values for PARAM_PERMISSIONS_JR2
-
-- `REMOVE_NODE`: if present, the permission evaluation will traverse down the hierarchy upon node removal. This config flag is a best effort approach but doesn't guarantee an identical behavior.
-- `USER_MANAGEMENT`: if set permissions for user related items will be evaluated the same way as regular JCR items irrespective of their protection status.
+The supported configuration options of the default implementation are described in the corresponding [section](permission/default.html#configuration).
##### 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.
-
-### Pluggability
-
-There are two ways for plugging permission related custom implementations:
-
-1. replace `AuthorizationConfiguration`: if you want to completely replace the way
- authorization is handled in the repository. In OSGi-base setup this is achieved
- by making the configuration implementation a service. In a non-OSGi-base setup the
- custom configuration must be exposed by the `SecurityProvider` implementation.
-2. extend `AuthorizationConfiguration`: it is planned to provide a `CompositeAuthorizationConfiguration`
- that allows to aggregate different authorization implementations (see [OAK-1268]).
-
<!-- references -->
[Permissions]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.html
[PermissionProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/PermissionProvider.html
@@ -450,6 +291,7 @@ There are two ways for plugging permissi
[PermissionConstants]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/PermissionConstants.html
[AuthorizationConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html
[PermissionHook]: /oak/docs/apidocs/org/apache/jackrabbit/oak/security/authorization/permission/PermissionHook.html
+[AggregatedPermissionProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/AggregatedPermissionProvider.html
[OAK-444]: https://issues.apache.org/jira/browse/OAK-444
[JCR-2963]: https://issues.apache.org/jira/browse/JCR-2963
[OAK-1268]: https://issues.apache.org/jira/browse/OAK-1268
\ No newline at end of file
Added: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/default.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/default.md?rev=1729662&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/default.md (added)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/default.md Wed Feb 10 17:12:26 2016
@@ -0,0 +1,183 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+Permissions : The Default Implementation
+--------------------------------------------------------------------------------
+
+### General Notes
+
+The default implementation of the `PermissionProvider` interface evaluates permissions
+based on the information stored in a dedicated part of the repository content call
+the [permission store](#permissionStore).
+
+### Characteristics of the Permission Evaluation
+
+#### Regular Permission Evaluation
+
+See section [Permission Evaluation in Detail](evaluation.html).
+
+#### Readable Trees
+
+Oak 1.0 comes with a configurable set of subtrees that are read-accessible to all
+subjects irrespective of other access control content taking effect. The original
+aim of these readable trees is to assert full acccess to namespace, nodetype and
+privilege information and the corresponding configuration therefore lists the
+following paths:
+
+- `/jcr:system/rep:namespaces`: stores all registered namespaces
+- `/jcr:system/jcr:nodeTypes`: stores all registered node types
+- `/jcr:system/rep:privileges`: stores all registered privileges
+
+This default set can be changed or extended by setting the corresponding configuration
+option. However, it is important to note that many JCR API calls rely on the
+accessibility of the namespace, nodetype and privilege information. Removing the
+corresponding paths from the configuration will most probably have undesired effects.
+
+#### 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`).
+
+
+### Permission Representation in the Repository
+
+<a name="permissionStore"/>
+#### Permission Store
+
+The permission evaluation present with Oak 1.0 keeps a dedicated location where
+permissions are being stored for later evaluation. The store is kept in sync
+with the access control content by a separated `PostValidationHook` implementation ([PermissionHook]).
+
+The location of the permission store is `/jcr:system/rep:permissionStore`; in
+accordance with other stores underneath `jcr:system` it is global to the whole
+repository keeping a separate entry for each workspace present with the repository.
+
+The permission entries are grouped by principal and stored below the store root
+based on the hash value of the path of the access controlled node; hash collisions
+are handled by adding subnodes accordingly.
+
+ /jcr:system/rep:permissionStore/workspace-name [rep:PermissionStore]
+ /principal-name [rep:PermissionStore]
+ /1259237738 [rep:PermissionStore]
+ /0 [rep:Permissions]
+ /1 [rep:Permissions]
+ /c0 [rep:PermissionStore] # hash collision
+ /0 [rep:Permissions]
+ /1 [rep:Permissions]
+ /2 [rep:Permissions]
+ /c1 [rep:PermissionStore] # hash collision
+ /0 [rep:Permissions]
+ /1 [rep:Permissions]
+ /2 [rep:Permissions]
+ /47 [rep:PermissionStore]
+ /0 [rep:Permissions]
+ /1 [rep:Permissions]
+
+Each per path store looks as follows
+
+ "1259237738" {
+ "jcr:primaryType": "rep:PermissionStore",
+ "rep:accessControlledPath": "/content",
+ "0": {
+ "jcr:primaryType": "rep:Permissions",
+ "rep:isAllow": false,
+ "rep:privileges": [32],
+ "rep:ntNames": ["nt:unstructured", "oak:Unstructured"]
+ ... /* additional restrictions as present in the entry */
+ }
+ }
+
+##### Accessing the Permission Store
+
+It is important to understand that the permission store is a implementation
+specific structure that is maintained by the system itself. For this reason
+access to the permission store is additionally restricted superimposing the
+regular permissions being enforced for regular repository items.
+
+In detail this means that the permission store cannot be written by JCR nor Oak
+API method calls. It's immutability is enforced by a dedicated `FailingValidator`
+that prevents any modifications underneath `/jcr:system/rep:permissionStore`.
+Similarly read access is not allowed except for system principals. In order to
+discover and display access control related information API consumers should
+use the regular JCR and Jackrabbit permission and access control management API
+as listed in the [introduction](../permission.html#jcr_api) and in section
+[Using the Access Control Management API](../accesscontrol/editing.html).
+
+
+#### Node Type Definitions
+
+For the permission store the following built-in node types have been defined:
+
+ [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
+
+In addition Oak 1.0 defines a specific mixin type that allows to store the path(s)
+of the versionable node with each version history. Adding this mixing and updating
+the versionable path information is taken care of by a dedicated commit hook
+implementation (`VersionablePathHook`).
+
+ [rep:VersionablePaths]
+ mixin
+ - * (PATH) protected ABORT
+
+<a name="validation"/>
+### Validation
+
+The consistency of this content structure is asserted by a dedicated `PermissionValidator`.
+The corresponding errors are all of type `Access` with the following codes:
+
+| Code | Message |
+|-------------------|----------------------------------------------------------|
+| 0000 | Generic access violation |
+| 0021 | Version storage: Node creation without version history |
+| 0022 | Version storage: Removal of intermediate node |
+
+<a name="configuration"/>
+### Configuration
+
+#### Configuration Parameters
+
+The default implementation supports the following configuration parameters:
+
+| Parameter | Type | Default | Description |
+|-----------------------------------|---------------------|----------|-------------|
+| `PARAM_PERMISSIONS_JR2` | String | \- | Enables backwards compatible behavior for the permissions listed in the parameter value containing the permission names separated by ','. Supported values are: `USER_MANAGEMENT`,`REMOVE_NODE` |
+| `PARAM_READ_PATHS` | Set\<String\> | paths to namespace, nodetype and privilege root nodes | 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` | String[] | \- | The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. |
+| | | | |
+
+##### Supported Values for PARAM_PERMISSIONS_JR2
+
+- `REMOVE_NODE`: if present, the permission evaluation will traverse down the hierarchy upon node removal. This config flag is a best effort approach but doesn't guarantee an identical behavior.
+- `USER_MANAGEMENT`: if set permissions for user related items will be evaluated the same way as regular JCR items irrespective of their protection status.
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/permission/evaluation.md Wed Feb 10 17:12:26 2016
@@ -15,16 +15,20 @@
limitations under the License.
-->
-Permission Evaluation in Detail
+Permission Evaluation in Detail : The Default Implementation
--------------------------------------------------------------------------------
-### <a name="permissionentries"></a>Order and Evaluation of Permission Entries
+<a name="permissionentries"/>
+### Order and Evaluation of Permission Entries
In order to evaluate the permissions for a given item, the `PermissionProvider`
lazily builds an iterator of `PermissionsEntry` representing the rep:Permission
present in the permission store that take effect for the given set of principals
at the given node (or property).
+Each `PermissionsEntry` stores the privileges granted/denied together with any
+restrictions that may be defined with the original access control entry.
+
This iterator is a concatenation between all entries associated with user principals
followed by the entries associated with group principals.
@@ -49,6 +53,16 @@ Result:
- everyone is allowed to read the complete tree defined by /content
+###### Simple Inheritance with Restrictions
+
+ /content
+ allow - everyone - READ permission
+ deny - everyone - READ_PROPERTY permission - restriction rep:itemNames = ['prop1', 'prop2']
+
+Result:
+
+- everyone is cannot read the complete tree defined by /content _except_ for properties named 'prop1' or 'prop2' which are explicitly denied by the restricting entry.
+
###### Inheritance with Allow and Deny
/content
@@ -174,7 +188,7 @@ in terms of permission evaluation:
1. The _permission entries_ are [analyzed](#entry_evaluation) if they include the respective permission and if so,
the read status is set accordingly. Note that the sequence of the permission entries from
the iterator is already in the correct order for this kind of evaluation. This is ensured
- by the way how they are stored in the [permission store](../permission.html#permissionStore) and how they
+ by the way how they are stored in the [permission store](default.html#permissionStore) and how they
are feed into the iterator (see [Order and Evaluation of Permission Entries](#permissionentries) above).
The iteration also detects if the evaluated permission entries cover _this_ node and all
@@ -217,8 +231,8 @@ in terms of permission evaluation:
permission for properties defining access control related content. In case
all properties defined with the parent tree are accessible to the editing
session the result is remembered in the `ReadStatus` kept with this `TreePermission`
- instance; otherwise the _permission entries_ are collected and evaluated as described
- in sections [Order and Evaluation of Permission Entries](#permissionentries) above.
+ instance; otherwise the _permission entries_ are collected and evaluated as described
+ [above](#permissionentries).
#### Session Write-Operations
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal.md Wed Feb 10 17:12:26 2016
@@ -18,18 +18,33 @@
Principal Management
--------------------------------------------------------------------------------
-### Characteristics of the Principal Management Implementation
+<a href="jcr_api"/>
+### JCR API
-The default implementation of the principal management API basically corresponds
-to the default in Jackrabbit 2.x and is based on the user management implementation.
-Note however, that as of Oak only a single principal provider is exposed on the
-SPI level (used to be multiple principal providers with the LoginModule configuration
-in Jackrabbit 2.x). See the configuration section below for details.
+JCR itself doesn't come with a dedicated principal management API. Nevertheless
+the specification mentions `java.security.Principal` as key feature for
+access control management but leaves the discovery of principals to the implementation.
+
+Therefore an API for principal management has been defined as part of the
+extensions present with Jackrabbit API.
+
+<a name="jackrabbit_api"/>
+### Jackrabbit API
+
+The Jackrabbit API provides support for principal management (i.e. discovery) that
+are missing in JCR. The relevant interfaces are defined in the
+`org.apache.jackrabbit.api.security.principal' package space:
+
+- `PrincipalManager`
+- `PrincipalIterator`
+- `JackrabbitPrincipal`
+ - `ItemBasedPrincipal`
#### Differences wrt Jackrabbit 2.x
See the corresponding [documentation](principal/differences.html).
+<a name="api_extensions"/>
### API Extensions
- [PrincipalProvider]: SPI level access to principals known to the repository
@@ -41,14 +56,26 @@ different sources.
- [CompositePrincipalProvider]: Implementation that combines different principals
from different source providers.
-See section [Implementations of the PrincipalProvider Interface](principal/principalprovider.html)
-for details.
-
##### Special Principals
- [AdminPrincipal]: Marker interface to identify the principal associated with administrative user(s).
- [EveryonePrincipal]: built-in group principal implementation that has every other valid principal as member.
- [SystemPrincipal]: built-in principal implementation to mark system internal subjects.
+- [SystemUserPrincipal]: Marker interface to identify principals associated with special system users.
+
+### Oak Principal Management Implementation
+
+The default implementation of the principal management API basically corresponds
+to the default in Jackrabbit 2.x and is based on the user management implementation.
+Note however, that as of Oak only a single principal provider is exposed on the
+SPI level (used to be multiple principal providers with the LoginModule configuration
+in Jackrabbit 2.x). See the configuration section below for details.
+
+#### PrincipalProvider Implementations
+
+See section [Implementations of the PrincipalProvider Interface](principal/principalprovider.html)
+for details.
+<a name="configuration"/>
### Configuration
The [PrincipalConfiguration] is the Oak level entry point to obtain a new
@@ -61,6 +88,7 @@ provider implementation configured. In o
sources a implementation that properly handles the different sources is required;
the [CompositePrincipalProvider] is an example that combines multiple implementations.
+<a name="pluggability"/>
### Pluggability
The default security setup as present with Oak 1.0 is able to provide custom
@@ -137,4 +165,5 @@ provider implementation:
[AdminPrincipal]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/AdminPrincipal.html
[EveryonePrincipal]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.html
[SystemPrincipal]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/SystemPrincipal.html
+[SystemUserPrincipal]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/SystemUserPrincipal.html
[PrincipalConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.html
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/differences.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/differences.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/differences.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/differences.md Wed Feb 10 17:12:26 2016
@@ -26,14 +26,14 @@ have been made part of public API expose
- [org.apache.jackrabbit.oak.spi.security.principal.EveryonePrincipal]: corresponds to o.a.j.core.security.principal.EveryonePrincipal
- [org.apache.jackrabbit.oak.spi.security.principal.SystemPrincipal]: corresponds to o.a.j.core.security.SystemPrincipal
-#### Combine principals from different sources
+#### Combining Principals from Different Sources
In contrast to Jackrabbit 2.x Oak only deals with a single `PrincipalProvider`. In
order to combine principals from different sources a implementation that properly
handles the different sources is required; the [CompositePrincipalProvider] is an
example that combines multiple implementations.
-See [Principal Management](../principal.html) for an example.
+See [Principal Management](../principal.html#pluggability) for an example.
<!-- references -->
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/principalprovider.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/principalprovider.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/principalprovider.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/principal/principalprovider.md Wed Feb 10 17:12:26 2016
@@ -21,7 +21,7 @@ Implementations of the PrincipalProvider
Oak contains by default the following implementations of the `PrincipalProvider`
interface:
-### org.apache.jackrabbit.oak.security.principal.PrincipalProviderImpl
+### [PrincipalProviderImpl]
This is the default implementation of the `PrincipalProvider`, which makes use
of the fact that `Authorizable`s as defined by the Jackrabbit user management
@@ -31,17 +31,17 @@ The implementation is not tied to a part
and doesn't need to be rewritten if the security setup would be configured with
different implementation of `UserConfiguration`.
-### org.apache.jackrabbit.oak.security.user.UserPrincipalProvider
+### [UserPrincipalProvider]
The introduction of the optional `UserConfiguration.getUserPrincipalProvider`
-extension allows for an optimized variant of the default principal provider, which
-is reading principal information from user and group accounts always paired with
-a `Principal` instance.
+extension (since Oak 1.3.4) allows for an optimized variant of the default
+principal provider, which is reading principal information from user and group
+accounts using generic user management API. _Note:_ every single user/group
+exposes a `Principal` instance through the call `Authorizable.getPrincipal()`
-This extension allows for a provider based implementation details of the user
+This extension allows for a provider based on implementation details of the user
management implementation it is associated with, offering the ability to optimize
-the principal lookup without having to use regular Jackrabbit user management
-API calls and the associated overhead in terms of user/group object creation.
+the principal lookup and the associated overhead in terms of user/group object creation.
While the implementation is located along with the user management implementation
present in Oak this provider implementation should not be considered being
@@ -51,7 +51,7 @@ Another benefit of this optimized implem
cache the results of the principal resolution in order to improve login performance.
See section [Caching Results of Principal Resolution](cache.html) for further details.
-### org.apache.jackrabbit.oak.spi.security.principal.CompositePrincipalProvider
+### [CompositePrincipalProvider]
This implementation is a simple wrapper implementation that combines different
principals from different source providers. It is used in
@@ -59,3 +59,11 @@ principals from different source provide
collect all configured/plugged principal configurations i.e. the various
implementations of principal management.
+Custom `PrincipalProvider` implementations may be used to combine principals from
+different source i.e. detaching principal management from the user management,
+where principals are backed by an existing user/group account.
+
+<!-- references -->
+[PrincipalProviderImpl]: /oak/docs/apidocs/org/apache/jackrabbit/oak/security/principal/PrincipalProviderImpl.html
+[CompositePrincipalProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.html
+[UserPrincipalProvider]: /oak/docs/apidocs/org/apache/jackrabbit/oak/security/user/UserPrincipalProvider.html
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege.md Wed Feb 10 17:12:26 2016
@@ -18,6 +18,7 @@
Privilege Management
--------------------------------------------------------------------------------
+<a href="jcr_api"/>
### JCR API
As of JSR 283 the API contains the following privilege related interfaces and methods:
@@ -26,6 +27,7 @@ As of JSR 283 the API contains the follo
- `AccessControlManager.getSupportedPrivileges(String)` (see also `PrivilegeManager.getRegisteredPrivileges()`)
- `AccessControlManager.privilegeFromName(String)` equivalent to `PrivilegeManager.getPrivilege(String)`
+<a name="jackrabbit_api"/>
### Jackrabbit API
Privilege management is outside of the scope provided by JCR and therefore provided
@@ -57,126 +59,7 @@ by the extensions defined by the Jackrab
// NOTE: workspace operation that doesn't require Session#save()
privilegeManager.registerPrivilege(privilegeName, isAbstract, declaredAggregateNames);
-### Characteristics of the Privilege Management Implementation
-
-#### 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 and cannot be modified
-using regular JCR write methods. In addition a specific `Validator` and `CommitHook`
-implementations assert the consistency of the privilege store. The built-in
-privileges are installed using a dedicated implementation of the `RepositoryInitializer`.
-
-#### Differences wrt Jackrabbit 2.x
-A comprehensive list of changes compared to Jackrabbit 2.x can be found in the
-corresponding [documentation](privilege/differences.html).
-
-#### Built-in Privileges
-
-- All Privileges as defined by JSR 283
-
- jcr:read (NOTE: Aggregate since Oak 1.0)
- jcr:modifyProperties (NOTE: Aggregate since Oak 1.0)
- jcr:addChildNodes
- jcr:removeNode
- jcr:removeChildNodes
- jcr:readAccessControl
- jcr:modifyAccessControl
- jcr:lockManagement
- jcr:versionManagement
- jcr:nodeTypeManagement
- jcr:retentionManagement (NOTE: retention management not implemented in Oak 1.0)
- jcr:lifecycleManagement (NOTE: lifecycle management not implemented in Oak 1.0)
- 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
- rep:indexDefinitionManagement
-
-Please 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`
-
-An overview on how the built-in privileges map to API calls and individual items
-can be found in ['Mapping Privileges to Items'](privilege/mappingtoitems.html)
-and ['Mapping API Calls to Privileges'](privilege/mappingtoprivileges.html)
-
-##### New Privileges
-
-The new Privileges introduced with Oak 1.0 have the following effect:
-
-- `rep:userManagement`: Privilege required in order to write items that define user or group specific content.
-- `rep:readNodes`: Privilege used to allow/deny read access to nodes (aggregate of `jcr:read`)
-- `rep:readProperties`: Privilege used to allow/deny read access to properties (aggregate of `jcr:read`)
-- `rep:addProperties`: Privilege required in order to create new properties (aggreate of `jcr:modifyProperties`)
-- `rep:alterProperties`: Privilege required in order to change existing properties (aggreate of `jcr:modifyProperties`)
-- `rep:removeProperties`: Privilege required in order to remove existing properties (aggreate of `jcr:modifyProperties`)
-- `rep:indexDefinitionManagement`: Privilege required to create, modify or deleate index definitions.
-
-#### Privilege Representation in the Repository
-
-As of Oak 1.0 all privilege definitions are stored in the repository itself
-underneath `/jcr:system/rep:privileges`. The following privilege related built-in
-node types have been added in OAK 1.0 in order to represent built-in and custom
-privilege definitions.
-
- [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
-
-Note the protection status of all child items defined by these node type definitions
-as they prevent modification of the privilege definitions using regular JCR
-write operations.
-
-<a name="validation"/>
-##### Validation
-
-The consistency of this content structure is asserted by a dedicated `PrivilegeValidator`.
-The corresponding errors are all of type `Constraint` with the following codes:
-
-| Code | Message |
-|-------------------|----------------------------------------------------------|
-| 0041 | Modification of existing privilege definition X |
-| 0042 | Un-register privilege X |
-| 0043 | Next bits not updated |
-| 0044 | Privilege store not initialized |
-| 0045 | Modification of existing privilege definition X |
-| 0046 | Modification of existing privilege definition X |
-| 0047 | Invalid declared aggregate name X |
-| 0048 | PrivilegeBits are missing |
-| 0049 | PrivilegeBits already in used |
-| 0050 | Singular aggregation is equivalent to existing privilege.|
-| 0051 | Declared aggregate X is not a registered privilege |
-| 0052 | Detected circular aggregation |
-| 0053 | Custom aggregate privilege X is already covered. |
-
-
+<a name="api_extensions"/>
### API Extensions
- [PrivilegeConfiguration] : Oak level entry point to retrieve `PrivilegeManager` and privilege related configuration options.
@@ -184,6 +67,7 @@ The corresponding errors are all of type
- [PrivilegeBitsProvider] : Internal provider to read `PrivilegeBits` from the repository content and map names to internal representation (and vice versa).
- [PrivilegeBits]: Internal representation of JCR privileges.
+<a name="utilities"/>
### Utilities
The jcr-commons module present with Jackrabbit provide some privilege related
@@ -193,7 +77,12 @@ utility methods:
- `privilegesFromNames(Session session, String... privilegeNames)`
- `privilegesFromNames(AccessControlManager accessControlManager, String... privilegeNames)`
+### Oak Privilege Management Implementation
+
+The behavior of the default privilege management implementation is described in section
+[Privilege Management: The Default Implementation](privilege/default.html).
+<a name="configuration"/>
### Configuration
The [PrivilegeConfiguration] is the Oak level entry point to obtain a new
Added: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/default.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/default.md?rev=1729662&view=auto
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/default.md (added)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/default.md Wed Feb 10 17:12:26 2016
@@ -0,0 +1,143 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+Privilege Management : The Default Implementation
+--------------------------------------------------------------------------------
+
+### 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 and cannot be modified
+using regular JCR write methods. In addition a specific `Validator` and `CommitHook`
+implementations assert the consistency of the privilege store. The built-in
+privileges are installed using a dedicated implementation of the `RepositoryInitializer`.
+
+### Differences wrt Jackrabbit 2.x
+A comprehensive list of changes compared to Jackrabbit 2.x can be found in the
+corresponding [documentation](differences.html).
+
+### Built-in Privileges
+
+- All Privileges as defined by JSR 283
+
+ jcr:read (NOTE: Aggregate since Oak 1.0)
+ jcr:modifyProperties (NOTE: Aggregate since Oak 1.0)
+ jcr:addChildNodes
+ jcr:removeNode
+ jcr:removeChildNodes
+ jcr:readAccessControl
+ jcr:modifyAccessControl
+ jcr:lockManagement
+ jcr:versionManagement
+ jcr:nodeTypeManagement
+ jcr:retentionManagement (NOTE: retention management not implemented in Oak 1.0)
+ jcr:lifecycleManagement (NOTE: lifecycle management not implemented in Oak 1.0)
+ 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
+ rep:indexDefinitionManagement
+
+Please 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`
+
+#### New Privileges
+
+The new Privileges introduced with Oak 1.0 have the following effect:
+
+- `rep:userManagement`: Privilege required in order to write items that define user or group specific content.
+- `rep:readNodes`: Privilege used to allow/deny read access to nodes (aggregate of `jcr:read`)
+- `rep:readProperties`: Privilege used to allow/deny read access to properties (aggregate of `jcr:read`)
+- `rep:addProperties`: Privilege required in order to create new properties (aggreate of `jcr:modifyProperties`)
+- `rep:alterProperties`: Privilege required in order to change existing properties (aggreate of `jcr:modifyProperties`)
+- `rep:removeProperties`: Privilege required in order to remove existing properties (aggreate of `jcr:modifyProperties`)
+- `rep:indexDefinitionManagement`: Privilege required to create, modify or deleate index definitions.
+
+#### Mapping Privileges to Items and API Calls
+An overview on how the built-in privileges map to API calls and individual items
+can be found in ['Mapping Privileges to Items'](mappingtoitems.html)
+and ['Mapping API Calls to Privileges'](mappingtoprivileges.html)
+
+### Privilege Representation in the Repository
+
+As of Oak 1.0 all privilege definitions are stored in the repository itself
+underneath `/jcr:system/rep:privileges`. The following privilege related built-in
+node types have been added in OAK 1.0 in order to represent built-in and custom
+privilege definitions.
+
+ [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
+
+Note the protection status of all child items defined by these node type definitions
+as they prevent modification of the privilege definitions using regular JCR
+write operations.
+
+<a name="validation"/>
+### Validation
+
+The consistency of this content structure is asserted by a dedicated `PrivilegeValidator`.
+The corresponding errors are all of type `Constraint` with the following codes:
+
+| Code | Message |
+|-------------------|----------------------------------------------------------|
+| 0041 | Modification of existing privilege definition X |
+| 0042 | Un-register privilege X |
+| 0043 | Next bits not updated |
+| 0044 | Privilege store not initialized |
+| 0045 | Modification of existing privilege definition X |
+| 0046 | Modification of existing privilege definition X |
+| 0047 | Invalid declared aggregate name X |
+| 0048 | PrivilegeBits are missing |
+| 0049 | PrivilegeBits already in used |
+| 0050 | Singular aggregation is equivalent to existing privilege.|
+| 0051 | Declared aggregate X is not a registered privilege |
+| 0052 | Detected circular aggregation |
+| 0053 | Custom aggregate privilege X is already covered. |
+
+<a name="configuration"/>
+### Configuration
+
+There are implementation specific configuration options associated with the
+privilege management implementation.
\ No newline at end of file
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/mappingtoitems.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/mappingtoitems.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/mappingtoitems.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/privilege/mappingtoitems.md Wed Feb 10 17:12:26 2016
@@ -52,26 +52,21 @@ by the system only and cannot be modifie
| Privilege | Affected Items |
|-------------------------|-----------------------------------------------------|
-| jcr:readAccessControl | all items defining access control content (1) |
-| jcr:modifyAccessControl | all items defining access control content (1) |
+| jcr:readAccessControl | all items defining access control content [1] |
+| jcr:modifyAccessControl | all items defining access control content [1] |
| rep:privilegeManagement | implementation specific; in Oak everything below `/jcr:system/rep:privileges` |
-(1) in Oak reading/writing nodes with the following node types: `rep:Policy`, `rep:ACL`, `rep:ACE`, `rep:GrantACE`, `rep:DenyACE`, `rep:Restrictions`, `rep:CugPolicy` and all protected items defined therein
-
#### Other Session and Workspace Operations
| Privilege | Affected Items |
|-------------------------|-----------------------------------------------------|
-| jcr:versionManagement | all items defining version content (2) |
+| jcr:versionManagement | all items defining version content [2] |
| jcr:lockManagement | Properties `jcr:lockIsDeep`, `jcr:lockOwner` |
| jcr:lifecycleManagement | `jcr:lifecyclePolicy`, `jcr:currentLifecycleState` |
| jcr:retentionManagement | implementation specific, in Jackrabbit 2.x the following properties: `rep:hold`, `rep:retentionPolicy`, Oak: NA |
-| rep:userManagement | all items defining user/group content (3) |
+| rep:userManagement | all items defining user/group content [3] |
| rep:indexDefinitionManagement | implementation specific; in Oak trees starting with an `oak:index` node |
-(2) granting jcr:versionManagement privilege at a given versionable node will allow writing items through JCR version management API which writes below `/jcr:system/jcr:versionStorage`, `/jcr:system/jcr:activities`, `/jcr:system/jcr:configurations` and the following properties both in the storage(s) and with the versionable node: `jcr:activity`, `jcr:activityTitle`, `jcr:baseVersion`, `jcr:childVersionHistory`, `jcr:configuration`, `jcr:copiedFrom`, `jcr:frozenMixinTypes`, `jcr:frozenPrimaryType`, `jcr:frozenUuid`, `jcr:isCheckedOut`, `jcr:mergeFailed`, `jcr:predecessors`,`jcr:successors`,`jcr:root`,`jcr:versionableUuid`, `jcr:versionHistory`
-(3) in Oak creating nodes with the following primary types: `rep:User`, `rep:SystemUser`, `rep:Group`, `rep:Impersonatable`, `rep:Members`, `rep:MemberReferences`, `rep:MemberReferencesList`, `rep:Password` and all protected properties defined therein
-
#### Repository Operations
| Privilege | Affected Items |
@@ -80,3 +75,13 @@ by the system only and cannot be modifie
| jcr:nodeTypeDefinitionManagement | implementation specific; in Oak everything below `/jcr:system/jcr:nodeTypes` |
| rep:privilegeManagement | implementation specific; in Oak everything below `/jcr:system/rep:privileges` |
| jcr:workspaceManagement | NA |
+
+
+#### Annotations
+
+[1] In Oak reading/writing nodes with the following node types provided by the implementations present: `rep:Policy`, `rep:ACL`, `rep:ACE`, `rep:GrantACE`, `rep:DenyACE`, `rep:Restrictions` and `rep:CugPolicy` and all protected items defined therein.
+ See [Default Access Control Management](../accesscontrol/default.html) and [Managing Access Control with CUG](../authorization_cug/cug.html), respectively.
+
+[2] Granting jcr:versionManagement privilege at a given versionable node will allow writing items through JCR version management API which writes below `/jcr:system/jcr:versionStorage`, `/jcr:system/jcr:activities`, `/jcr:system/jcr:configurations` and the following properties both in the storage(s) and with the versionable node: `jcr:activity`, `jcr:activityTitle`, `jcr:baseVersion`, `jcr:childVersionHistory`, `jcr:configuration`, `jcr:copiedFrom`, `jcr:frozenMixinTypes`, `jcr:frozenPrimaryType`, `jcr:frozenUuid`, `jcr:isCheckedOut`, `jcr:mergeFailed`, `jcr:predecessors`,`jcr:successors`,`jcr:root`,`jcr:versionableUuid`, `jcr:versionHistory`
+
+[3] in Oak creating nodes with the following primary types: `rep:User`, `rep:SystemUser`, `rep:Group`, `rep:Impersonatable`, `rep:Members`, `rep:MemberReferences`, `rep:MemberReferencesList`, `rep:Password` and all protected properties defined therein
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user.md Wed Feb 10 17:12:26 2016
@@ -18,14 +18,16 @@
User Management
--------------------------------------------------------------------------------
-### JCR User Management
+<a href="jcr_api"/>
+### JCR API
JCR itself doesn't come with a dedicated user management API. The only method
related and ultimately used for user management tasks is `Session.getUserID()`.
Therefore an API for user and group management has been defined as part of the
extensions present with Jackrabbit API.
-### Jackrabbit User Management API
+<a name="jackrabbit_api"/>
+### Jackrabbit API
The Jackrabbit API provides the user management related extensions that are
missing in JCR. The relevant interfaces are defined in the
@@ -39,225 +41,25 @@ missing in JCR. The relevant interfaces
- `QueryBuilder`
- `Query`
-### Oak User Management Implementation
-
-The default user management implementation stores user/group information in the
-content repository. In contrast to Jackrabbit 2.x, which by default used a single,
-dedicated workspace for user/group data, this data will as of Oak 1.0 be stored
-separately for each JCR workspace.
-
-Consequently the `UserManager` associated with the editing sessions, performs
-all actions with this editing session. This corresponds to the behavior as defined
-the alternative implementation present with Jackrabbit 2.x ((see Jackrabbit 2.x `UserPerWorkspaceUserManager`).
-
-#### General
-* The Oak implementation is build on the Oak API. This allows for double usage as
- extension to the JCR API as well as within the Oak layer (aka SPI).
-* The `UserManager` is always associated with the same JCR workspace as the editing
- `Session` from which the class has been obtained.
-* Changes made to the user management API are always transient and require `Session#save()` to be persisted.
-* In case of any failure during user management related write operations the API
- consumer is in charge of specifically revert pending or invalid transient modifications
- or calling `Session#refresh(false)`.
-
-#### Differences wrt Jackrabbit 2.x
-
-A summary of all changes with respect to the former implementation present with
-Jackrabbit 2.x is present in the corresponding [section](user/differences.html).
-
-#### Built-in Users and Special Groups
-
-The setup of builtin user and group accounts is triggered by the configured `WorkspaceInitializer`
-associated with the user management configuration (see Configuration section below).
-
-The default user management implementation in OAK comes with an initializer that
-creates the following builtin user accounts:
-
-##### Administrator
-The admin user is always being created. The ID of this user is retrieved from the
-user configuration parameter `PARAM_ADMIN_ID`, which defaults to `admin`.
-
-As of OAK 1.0 however the administrator user might be created without initial
-password forcing the application to set the password upon start (see `PARAM_OMIT_ADMIN_PW`
-configuration parameter).
-
-##### Anonymous User
-In contrast to Jackrabbit 2.x the anonymous (or guest) user is optional. Creation
-will be skipped if the value of the `PARAM_ANONYMOUS_ID` configuration parameter
-is `null` or empty.
-
-Note, that the anonymous user will always be created without specifying a password
-in order to prevent regular login with `SimpleCredentials`.
-The proper way to obtain a guest session is:
-
- Repository#login(new GuestCredentials(), wspName);
-
-See section [Authentication](authentication.html) for further information about
-guest login.
-
-##### Everyone Group
-
-The default user management implementation in Oak contains special handling for
-the optional group that represents _everyone_, which is marked by the reserved
-name [everyone] and corresponds to the `EveryonePrincipal`.
-
-This special group always contains all Authorizable as member and cannot be edited
-with user management API. As of OAK this fact is consistently reflected in all
-group membership related methods. See also [Principal Management](principal.html).
-
-#### Reading Authorizables
-
-##### Handling of the Authorizable ID
-* As of Oak the node type definition of `rep:Authorizable` defines a new property `rep:authorizableId` which is intended to store the ID of a user or group.
-* The default implementation comes with a dedicated property index for `rep:authorizableId` which asserts the uniqueness of that ID.
-* `Authorizable#getID` returns the string value contained in `rep:authorizableID` and for backwards compatibility falls back on the node name in case the ID property is missing.
-* The name of the authorizable node is generated based on a configurable implementation of the `AuthorizableNodeName` interface (see configuration section below). By default it uses the ID as name hint and includes a conversion to a valid JCR node name.
-
-##### equals() and hashCode()
-The implementation of `Object#equals()` and `Object#hashCode()` for user and
-groups slightly differs from Jackrabbit 2.x. It no longer relies on the _sameness_
-of the underlaying JCR node but only compares IDs and the user manager instance.
-
-#### Creating Authorizables
-* The `rep:password` property is no longer defined to be mandatory. Therefore a new user might be created without specifying a password. Note however, that `User#changePassword` does not allow to remove the password property.
-* `UserManager#createGroup(Principal)` will no longer generate a groupID in case the principal name collides with an existing user or group ID. This has been considered redundant as the Jackrabbit API in the mean time added `UserManager#createGroup(String groupID)`.
-* Since OAK is designed to scale with flat hierarchies the former configuration options `autoExpandTree` and `autoExpandSize` are no longer supported.
-
-#### Query
-
-See section [Searching Users and Groups](user/query.html) for details.
-
-#### Group Membership
-
-See section [Group Membership](user/membership.html) for details.
-
-#### Autosave Behavior
-Due to the nature of the UserManager (see above) we decided to drop the auto-save
-behavior in the default implementation present with OAK. Consequently,
-
-* `UserManager#autoSave(boolean)` throws `UnsupportedRepositoryOperationException`
-* `UserManager#isAutoSave()` always returns `false`
-
-See also `PARAM_SUPPORT_AUTOSAVE` below; while this should not be needed if
-application code has been written against the Jackrabbit API (and thus testing if
-auto-save mode is enabled or not) this configuration option can be used as last resort.
-
-
-#### User/Group Representation in the Repository
-
-The following block lists the built-in node types related to user management tasks:
-
- [rep:Authorizable] > mix:referenceable, nt:hierarchyNode
- abstract
- + * (nt:base) = nt:unstructured VERSION
- - rep:principalName (STRING) protected mandatory
- - rep:authorizableId (STRING) protected /* @since oak 1.0 */
- - * (UNDEFINED)
- - * (UNDEFINED) multiple
-
- [rep:Group] > rep:Authorizable, rep:MemberReferences
- + rep:members (rep:Members) = rep:Members multiple protected VERSION /* @deprecated */
- + rep:membersList (rep:MemberReferencesList) = rep:MemberReferencesList protected COPY
-
- /** @since oak 1.0 */
- [rep:MemberReferences]
- - rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
-
- /** @since oak 1.0 */
- [rep:MemberReferencesList]
- + * (rep:MemberReferences) = rep:MemberReferences protected COPY
-
- /** @deprecated since oak 1.0 */
- [rep:Members]
- orderable
- + * (rep:Members) = rep:Members protected multiple
- - * (WEAKREFERENCE) protected < 'rep:Authorizable'
-
-<a name="validation"/>
-##### Validation
-
-The consistency of this content structure is asserted by a dedicated `UserValidator`.
-The corresponding errors are all of type `Constraint` with the following codes:
-
-| Code | Message |
-|-------------------|----------------------------------------------------------|
-| 0020 | Admin user cannot be disabled |
-| 0021 | Invalid jcr:uuid for authorizable (creation) |
-| 0022 | Changing Id, principal name after creation |
-| 0023 | Invalid jcr:uuid for authorizable (mod) |
-| 0024 | Password may not be plain text |
-| 0025 | Attempt to remove id, principalname or pw |
-| 0026 | Mandatory property rep:principalName missing |
-| 0027 | The admin user cannot be removed |
-| 0028 | Attempt to create outside of configured scope |
-| 0029 | Intermediate folders not rep:AuthorizableFolder |
-| 0030 | Missing uuid for group (check for cyclic membership) |
-| 0031 | Cyclic group membership |
-| 0032 | Attempt to set password with system user |
-| 0033 | Attempt to add rep:pwd node to a system user |
-
-
-#### XML Import
-As of Oak 1.0 user and group nodes can be imported both with Session and Workspace
-import. Other differences compared to Jackrabbit 2.x:
-
-* Importing an authorizable to another tree than the configured user/group node will only failed upon save (-> see `UserValidator` during the `Root#commit`). With Jackrabbit 2.x core it used to fail immediately.
-* The `BestEffort` behavior is now also implemented for the import of impersonators (was missing in Jackrabbit /2.x).
-
+<a name="api_extensions"/>
### API Extensions
+
The Oak project introduces the following user management related public
interfaces and classes:
-#### Authorizable Actions
-
-The former internal Jackrabbit interface `AuthorizableAction` has been slightly
-adjusted to match Oak requirements and is now part of the public Oak SPI interfaces.
-In contrast to Jackrabbit-core the AuthorizableAction(s) now operate directly on
-the Oak API, which eases the handling of implementation specific tasks such as
-writing protected items.
-
-See section [Authorizable Actions](user/authorizableaction.html) for further
-details and examples.
-
-#### Node Name Generation
+- `AuthorizableType`: ease handling with the different authorizable types.
+- `AuthorizableAction` and `AuthorizableActionProvider`: see [Authorizable Actions](user/authorizableaction.html) for details.
+- `AuthorizableNodeName`: see section [Authorizable Node Name Generation](user/authorizablenodename.html).
+- `UserAuthenticationFactory`: see sections [pluggability](user/default.html#pluggability)
+and [user authentication](authentication/default.html#user_authentication) for additional details.
-The default user management implementation with Oak 1.0 allows to specify how
-the name of a new authorizable node is being generated.
-
-See section [Authorizable Node Name](user/authorizablenodename.html) for further
-details and examples.
-
-#### Password Expiry and Force Initial Password Change
-
-Since Oak 1.1.0 the default user management and authentication implementation
-provides password expiry and initial password change.
-
-By default these features are disabled. The corresponding configuration options
-are
-
-- `PARAM_PASSWORD_MAX_AGE`: number of days until the password expires.
-- `PARAM_PASSWORD_INITIAL_CHANGE`: boolean flag to enable this feature.
-
-See section [Password Expiry and Force Initial Password Change](user/expiry.html)
-for details.
-
-#### Password History
-
-Since Oak 1.3.3 the default user management implementation provides password
-history support.
-
-By default this feature is disabled. The corresponding configuration option is
-
-- `PARAM_PASSWORD_HISTORY_SIZE`: number of changed passwords to remember.
-
-See section [Password History](user/history.html) for details.
-
-#### Utilities
+<a href="utilities"/>
+### Utilities
`org.apache.jackrabbit.oak.spi.security.user.*`
-- `AuthorizableType` : Ease handling with the different authorizable types.
- `UserConstants` : Constants (NOTE: OAK names/paths)
+- `UserIdCredentials` : Simple credentials implementation that might be used for `User.getCredentials' without exposing pw information.
`org.apache.jackrabbit.oak.spi.security.user.util.*`
@@ -267,82 +69,51 @@ See section [Password History](user/hist
function for password generation.
- `UserUtil` : Utilities related to general user management tasks.
+### Oak User Management Implementation
+
+The behavior of the default user management implementation is described in section
+[User Management: The Default Implementation](user/default.html).
+<a name="configuration"/>
### Configuration
-The following user management specific methods are present with the [UserConfiguration]
-as of OAK 1.0:
+The Oak user management comes with a dedicated entry point called [UserConfiguration].
+This class is responsible for passing configuration options to the implementation
+and provides the following two methods:
-* getUserManager: Obtain a new user manager instance
+- `getUserManager(Root, NamePathMapper)`: get a new `UserManager` instance
+- `getUserPrincipalProvider(Root, NamePathMapper)`: optional method that allows for optimization of the principal look-up associated with user/group accounts (since Oak 1.3.4).
-#### Configuration Parameters supported by the default implementation
+#### Configuration Parameters
-| Parameter | Type | Default |
-|-------------------------------------|---------|----------------------------------------------|
-| `PARAM_ADMIN_ID` | String | "admin" |
-| `PARAM_OMIT_ADMIN_PW` | boolean | false |
-| `PARAM_ANONYMOUS_ID` | String | "anonymous" (nullable) |
-| `PARAM_USER_PATH` | String | "/rep:security/rep:authorizables/rep:users" |
-| `PARAM_GROUP_PATH` | String | "/rep:security/rep:authorizables/rep:groups" |
-| `PARAM_DEFAULT_DEPTH` | int | 2 |
-| `PARAM_PASSWORD_HASH_ALGORITHM` | String | "SHA-256" |
-| `PARAM_PASSWORD_HASH_ITERATIONS` | int | 1000 |
-| `PARAM_PASSWORD_SALT_SIZE` | int | 8 |
-| `PARAM_AUTHORIZABLE_NODE_NAME` | AuthorizableNodeName | AuthorizableNodeName#DEFAULT |
-| `PARAM_AUTHORIZABLE_ACTION_PROVIDER`| AuthorizableActionProvider | DefaultAuthorizableActionProvider |
-| `PARAM_SUPPORT_AUTOSAVE` | boolean | false |
-| `PARAM_IMPORT_BEHAVIOR` | String ("abort", "ignore", "besteffort") | "ignore" |
-| `PARAM_PASSWORD_MAX_AGE` | int | 0 |
-| `PARAM_PASSWORD_INITIAL_CHANGE` | boolean | false |
-| `PARAM_PASSWORD_HISTORY_SIZE` | int (upper limit: 1000) | 0 |
-| `PARAM_CACHE_EXPIRATION` | long | 0 |
-| | | |
-
-The following configuration parameters present with the default implementation in Jackrabbit 2.x are no longer supported and will be ignored:
-
-* `compatibleJR16`
-* `autoExpandTree`
-* `autoExpandSize`
-* `groupMembershipSplitSize`
-
-The optional `cacheExpiration` configuration option listed above is discussed in
-detail in section [Caching Results of Principal Resolution](principal/cache.html).
-It is not related to user management s.str. but affects the implementation
-specific `PrincipalProvider` implementation exposed by `UserConfiguration.getUserPrincipalProvider`.
+The supported configuration options of the default implementation are described in the corresponding [section](user/default.html#configuration).
+<a name="pluggability"/>
### Pluggability
-The default security setup as present with Oak 1.0 is able to provide custom
-implementation on various levels:
+The default security setup as present with Oak 1.0 is able to have the default
+user management implementation replaced as follows:
-1. The complete user management implementation can be changed by plugging a different
- `UserConfiguration` implementations. In OSGi-base setup this is achieved by making
- the configuration a service. In a non-OSGi-base setup the custom configuration
- must be exposed by the `SecurityProvider` implementation.
-2. Within the default user management implementation the following parts can be
- change/extended at runtime by providing corresponding OSGi services or passing
- appropriate configuration parameters exposing the custom implementations:
- - `AuthorizableActionProvider`: Defines the authorizable actions, see [Authorizable Actions](user/authorizableaction.html).
- - `AuthorizableNodeName`: Defines the generation of the authorizable node names
- in case the user management implementation stores user information in the repository.
- See [Authorizable Node Name Generation](user/authorizablenodename.html).
+The complete user management implementation can be changed by plugging a different
+`UserConfiguration` implementations. In OSGi-base setup this is achieved by making
+the configuration a service which must take precedence over the default.
+In a non-OSGi-base setup the custom configuration must be exposed by the
+`SecurityProvider` implementation.
+
+Alternatively the default user management implementation can be extended and
+adjusted using various means. See the corresponding [section](user/default.html#pluggability)
+for further details.
### Further Reading
- [Differences wrt Jackrabbit 2.x](user/differences.html)
-- [Group Membership](user/membership.html)
-- [Authorizable Actions](user/authorizableaction.html)
-- [Authorizable Node Name](user/authorizablenodename.html)
-- [Searching Users and Groups](user/query.html)
-- [Password Expiry and Force Initial Password Change](user/expiry.html)
-- [Password History](user/history.html)
+- [User Management : The Default Implementation](user/default.html)
+ - [Group Membership](user/membership.html)
+ - [Authorizable Actions](user/authorizableaction.html)
+ - [Authorizable Node Name](user/authorizablenodename.html)
+ - [Searching Users and Groups](user/query.html)
+ - [Password Expiry and Force Initial Password Change](user/expiry.html)
+ - [Password History](user/history.html)
<!-- hidden references -->
-[everyone]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.html#NAME
[UserConfiguration]: /oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/user/UserConfiguration.html
-[OAK-118]: https://issues.apache.org/jira/browse/OAK-118
-[OAK-482]: https://issues.apache.org/jira/browse/OAK-482
-[OAK-793]: https://issues.apache.org/jira/browse/OAK-793
-[OAK-949]: https://issues.apache.org/jira/browse/OAK-949
-[OAK-1183]: https://issues.apache.org/jira/browse/OAK-1183
-
Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user/authorizableaction.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user/authorizableaction.md?rev=1729662&r1=1729661&r2=1729662&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user/authorizableaction.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/security/user/authorizableaction.md Wed Feb 10 17:12:26 2016
@@ -33,7 +33,6 @@ Compared to the Jackrabbit interface the
adjusted to match Oak requirements operate directly on the Oak API, which eases
the handling of implementation specific tasks such as writing protected items.
-
### AuthorizableAction API
The following public interfaces are provided by Oak in the package `org.apache.jackrabbit.oak.spi.security.user.action`:
@@ -65,7 +64,7 @@ Oak 1.0 provides the following base impl
The following implementations of the `AuthorizableAction` interface are provided:
* `AccessControlAction`: set up permission for new authorizables
-* `PasswordAction`: simplistic password verification upon user creation and password modification
+* `PasswordValidationAction`: simplistic password verification upon user creation and password modification
* `PasswordChangeAction`: verifies that the new password is different from the old one
* `ClearMembershipAction`: clear group membership upon removal of an authorizable.