You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by mr...@apache.org on 2018/07/09 08:53:19 UTC
svn commit: r1835390 [19/23] - in /jackrabbit/site/live/oak/docs: ./
architecture/ coldstandby/ features/ nodestore/ nodestore/document/
nodestore/segment/ oak-mongo-js/ oak_api/ plugins/ query/ security/
security/accesscontrol/ security/authentication...
Modified: jackrabbit/site/live/oak/docs/security/authorization/restriction.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authorization/restriction.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authorization/restriction.html (original)
+++ jackrabbit/site/live/oak/docs/security/authorization/restriction.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Restriction Management</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,136 +240,106 @@
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.
- --><div class="section">
+ -->
+<div class="section">
<h2><a name="Restriction_Management"></a>Restriction Management</h2>
<div class="section">
<h3><a name="Overview"></a>Overview</h3>
<p>The concept of restriction has been created as extension to JCR access control management in order to refine the effect of individual access control entries.</p>
<p>Quoting from JSR 283 section 16.6.2 Permissions:</p>
-
<blockquote>
+
<p>[…] the permissions encompass the restrictions imposed by privileges, but also include any additional policy-internal refinements with effects too fine-grained to be exposed through privilege discovery. A common case may be to provide finer-grained access restrictions to individual properties or child nodes of the node to which the policy applies.</p>
</blockquote>
<p>Furthermore the restriction concept is aimed to allow for custom extensions of the default access control implementation to meet project specific needs without having to implement the common functionality provided by JCR.</p>
<p>Existing and potential examples of restrictions limiting the effect of a given access control entry during permission evaluation include:</p>
-
<ul>
-
+
<li>set of node types</li>
-
<li>set of namespaces</li>
-
<li>name/path pattern</li>
-
<li>dedicated time frame</li>
-
<li>size of a value</li>
</ul>
<p>The set of built-in restrictions present with Jackrabbit 2.x has extended as of Oak 1.0 along with some extensions of the Jackrabbit API. This covers the public facing usage of restrictions i.e. access control management.</p>
<p>In addition Oak provides it’s own restriction API that adds support for internal validation and permission evaluation.</p>
-<p><a name="jackrabbit_api"></a></p></div>
-<div class="section">
-<h3><a name="Jackrabbit_API"></a>Jackrabbit API</h3>
-<p>The Jackrabbit API add the following extensions to JCR access control management to read and create entries with restrictions:</p>
+<a name="jackrabbit_api"></a>
+### Jackrabbit API
+<p>The Jackrabbit API add the following extensions to JCR access control management to read and create entries with restrictions:</p>
<ul>
-
-<li><tt>JackrabbitAccessControlList</tt>
-
+
+<li>
+
+<p><tt>JackrabbitAccessControlList</tt></p>
<ul>
-
+
<li><tt>getRestrictionNames()</tt> : returns the JCR names of the supported restrictions.</li>
-
<li><tt>getRestrictionType(String restrictionName)</tt> : returns property type of a given restriction.</li>
-
<li><tt>addEntry(Principal, Privilege[], boolean, Map<String, Value>)</tt>: the map contain the restrictions.</li>
-
<li><tt>addEntry(Principal, Privilege[], boolean, Map<String, Value>, Map<String, Value[]>)</tt>: allows to specify both single and multivalue restrictions (since Oak 1.0, Jackrabbit API 2.8)</li>
- </ul></li>
</ul>
+</li>
+<li>
+<p><tt>JackrabbitAccessControlEntry</tt></p>
<ul>
-
-<li><tt>JackrabbitAccessControlEntry</tt>
-
-<ul>
-
+
<li><tt>getRestrictionNames()</tt>: returns the JCR names of the restrictions present with this entry.</li>
-
<li><tt>getRestriction(String restrictionName)</tt>: returns the restriction as JCR value.</li>
-
<li><tt>getRestrictions(String restrictionName)</tt>: returns the restriction as array of JCR values (since Oak 1.0, Jackrabbit API 2.8).</li>
- </ul></li>
</ul>
-<p><a name="api_extensions"></a></p></div>
-<div class="section">
-<h3><a name="Oak_Restriction_API"></a>Oak Restriction API</h3>
-<p>The following public interfaces are provided by Oak in the package <tt>org.apache.jackrabbit.oak.spi.security.authorization.restriction</tt> and provide support for pluggable restrictions both for access control management and the repository internal permission evaluation:</p>
+</li>
+</ul>
+<a name="api_extensions"></a>
+### Oak Restriction API
+<p>The following public interfaces are provided by Oak in the package <tt>org.apache.jackrabbit.oak.spi.security.authorization.restriction</tt> and provide support for pluggable restrictions both for access control management and the repository internal permission evaluation:</p>
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/restriction/RestrictionProvider.html">RestrictionProvider</a>: interface to obtain restriction information needed for access control and permission management</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/restriction/Restriction.html">Restriction</a>: the restriction object as created using Jackrabbit access control API</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/restriction/RestrictionDefinition.html">RestrictionDefinition</a>: the static definition of a supported restriction</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/restriction/RestrictionPattern.html">RestrictionPattern</a>: the processed restriction ready for permission evaluation</li>
</ul>
-<p><a name="default_implementation"></a></p></div>
-<div class="section">
-<h3><a name="Default_Implementation"></a>Default Implementation</h3>
-<p>Oak 1.0 provides the following base implementations:</p>
+<a name="default_implementation"></a>
+### Default Implementation
+<p>Oak 1.0 provides the following base implementations:</p>
<ul>
-
+
<li><tt>AbstractRestrictionProvider</tt>: abstract base implementation of the provider interface.</li>
-
<li><tt>RestrictionDefinitionImpl</tt>: default implementation of the <tt>RestrictionDefinition</tt> interface.</li>
-
<li><tt>RestrictionImpl</tt>: default implementation of the <tt>Restriction</tt> interface.</li>
-
<li><tt>CompositeRestrictionProvider</tt>: Allows to aggregate multiple provider implementations (see <a href="#pluggability">Pluggability</a> below).</li>
-
<li><tt>CompositePattern</tt>: Allows to aggregate multiple restriction patterns.</li>
</ul>
<div class="section">
<h4><a name="Changes_wrt_Jackrabbit_2.x"></a>Changes wrt Jackrabbit 2.x</h4>
<p>Apart from the fact that the internal Jackrabbit extension has been replaced by a public API, the restriction implementation in Oak differs from Jackrabbit 2.x as follows:</p>
-
<ul>
-
+
<li>Separate restriction management API (see below) on the OAK level that allows to ease plugging custom restrictions.</li>
-
<li>Changed node type definition for storing restrictions in the default implementation.
-
<ul>
-
+
<li>as of OAK restrictions are collected underneath a separate child node “rep:restrictions”</li>
-
<li>backwards compatible behavior for restrictions stored underneath the ACE node directly</li>
- </ul></li>
-
+</ul>
+</li>
<li>Support for multi-valued restrictions (see <a class="externalLink" href="https://issues.apache.org/jira/browse/JCR-3637">JCR-3637</a>, <a class="externalLink" href="https://issues.apache.org/jira/browse/JCR-3641">JCR-3641</a>)</li>
-
<li>Validation of the restrictions is delegated to a dedicated commit hook</li>
-
<li>Restriction <tt>rep:glob</tt> limits the number of wildcard characters to 20</li>
-
<li>New restrictions <tt>rep:ntNames</tt>, <tt>rep:prefixes</tt> and <tt>rep:itemNames</tt></li>
</ul></div>
<div class="section">
<h4><a name="Built-in_Restrictions"></a>Built-in Restrictions</h4>
<p>The default implementations of the <tt>Restriction</tt> interface are present with Oak 1.0 access control management:</p>
-
<ul>
-
+
<li><tt>rep:glob</tt>: single name, path or path pattern with ‘*’ wildcard(s).</li>
-
<li><tt>rep:ntNames</tt>: multivalued restriction to limit the affected ACE to nodes of the specified primary node type(s) (no nt inheritence, since Oak 1.0)</li>
-
<li><tt>rep:prefixes</tt>: multivalued restriction to limit the effect to item names that match the specified namespace prefixes (session level remapping not respected, since Oak 1.0)</li>
-
<li><tt>rep:itemNames</tt>: multivalued restriction for property or node names (since Oak 1.3.8)</li>
</ul>
<div class="section">
@@ -377,125 +347,66 @@
<div class="section">
<h6><a name="Using_rep:glob"></a>Using rep:glob</h6>
<p>For a nodePath <tt>/foo</tt> the following results can be expected for the different values of <tt>rep:glob</tt>.</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>rep:glob </th>
-
-<th>Result </th>
- </tr>
- </thead>
- <tbody>
-
+<th> rep:glob </th>
+<th> Result </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td>"" </td>
-
-<td>matches node /foo only </td>
- </tr>
-
+<td> "" </td>
+<td> matches node /foo only </td></tr>
<tr class="a">
-
-<td>/cat </td>
-
-<td>the node /foo/cat and all it’s children </td>
- </tr>
-
+<td> /cat </td>
+<td> the node /foo/cat and all it’s children </td></tr>
<tr class="b">
-
-<td>/cat/ </td>
-
-<td>the descendants of the node /foo/cat </td>
- </tr>
-
+<td> /cat/ </td>
+<td> the descendants of the node /foo/cat </td></tr>
<tr class="a">
-
-<td>cat </td>
-
-<td>the node /foocat and all it’s children </td>
- </tr>
-
+<td> cat </td>
+<td> the node /foocat and all it’s children </td></tr>
<tr class="b">
-
-<td>cat/ </td>
-
-<td>all descendants of the node /foocat </td>
- </tr>
-
+<td> cat/ </td>
+<td> all descendants of the node /foocat </td></tr>
<tr class="a">
-
-<td>* </td>
-
-<td>foo, siblings of foo and their descendants </td>
- </tr>
-
+<td> * </td>
+<td> foo, siblings of foo and their descendants </td></tr>
<tr class="b">
-
-<td>/*cat </td>
-
-<td>all children of /foo whose path ends with ‘cat’ </td>
- </tr>
-
+<td> /*cat </td>
+<td> all children of /foo whose path ends with ‘cat’ </td></tr>
<tr class="a">
-
-<td>/*/cat </td>
-
-<td>all non-direct descendants of /foo named ‘cat’ </td>
- </tr>
-
+<td> /*/cat </td>
+<td> all non-direct descendants of /foo named ‘cat’ </td></tr>
<tr class="b">
-
-<td>/cat* </td>
-
-<td>all descendant path of /foo that have the direct foo-descendant segment starting with ‘cat’ </td>
- </tr>
-
+<td> /cat* </td>
+<td> all descendant path of /foo that have the direct foo-descendant segment starting with ‘cat’ </td></tr>
<tr class="a">
-
-<td>*cat </td>
-
-<td>all siblings and descendants of foo that have a name ending with ‘cat’ </td>
- </tr>
-
+<td> *cat </td>
+<td> all siblings and descendants of foo that have a name ending with ‘cat’ </td></tr>
<tr class="b">
-
-<td>*/cat </td>
-
-<td>all descendants of /foo and foo’s siblings that have a name segment ‘cat’ </td>
- </tr>
-
+<td> */cat </td>
+<td> all descendants of /foo and foo’s siblings that have a name segment ‘cat’ </td></tr>
<tr class="a">
-
-<td>cat/* </td>
-
-<td>all descendants of ‘/foocat’ </td>
- </tr>
-
+<td> cat/* </td>
+<td> all descendants of ‘/foocat’ </td></tr>
<tr class="b">
-
-<td>/cat/* </td>
-
-<td>all descendants of ‘/foo/cat’ </td>
- </tr>
-
+<td> /cat/* </td>
+<td> all descendants of ‘/foo/cat’ </td></tr>
<tr class="a">
-
-<td>*cat/* </td>
-
-<td>all descendants of /foo that have an intermediate segment ending with ‘cat’ </td>
- </tr>
- </tbody>
+<td> *cat/* </td>
+<td> all descendants of /foo that have an intermediate segment ending with ‘cat’ </td></tr>
+</tbody>
</table>
-<p><a name="representation"></a></p></div></div></div></div>
-<div class="section">
-<h3><a name="Representation_in_the_Repository"></a>Representation in the Repository</h3>
+<a name="representation"></a>
+### Representation in the Repository
+
<p>All restrictions defined by default in a Oak repository are stored as properties in a dedicated <tt>rep:restriction</tt> child node of the target access control entry node. Similarly, they are represented with the corresponding permission entry. The node type definition used to represent restriction content is as follows:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">[rep:ACE]
+<div>
+<div>
+<pre class="source">[rep:ACE]
- rep:principalName (STRING) protected mandatory
- rep:privileges (NAME) protected mandatory multiple
- rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
@@ -510,28 +421,26 @@
- * (UNDEFINED) protected
- * (UNDEFINED) protected multiple
</pre></div></div>
-<p><a name="pluggability"></a></p></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
+<a name="pluggability"></a>
+### Pluggability
+
<p>The default security setup as present with Oak 1.0 is able to provide custom <tt>RestrictionProvider</tt> implementations and will automatically combine the different implementations using the <tt>CompositeRestrictionProvider</tt>.</p>
<p>In an OSGi setup the following steps are required in order to add a action provider implementation:</p>
-
<ul>
-
+
<li>implement <tt>RestrictionProvider</tt> interface exposing your custom restriction(s).</li>
-
<li>make the provider implementation an OSGi service and make it available to the Oak repository.</li>
</ul>
-<p>Please make sure to consider the following recommendations when implementing a custom <tt>RestrictionProvider</tt>: - restrictions are part of the overall permission evaluation and thus may heavily impact overall read/write performance - the hashCode generation of the base implementation (<tt>RestrictionImpl.hashCode</tt>) relies on <tt>PropertyStateValue.hashCode</tt>, which includes the internal String representation, which is not optimal for binaries (see also <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-5784">OAK-5784</a>)</p>
-<div class="section">
+<p>Please make sure to consider the following recommendations when implementing a custom <tt>RestrictionProvider</tt>: - restrictions are part of the overall permission evaluation and thus may heavily impact overall read/write performance - the hashCode generation of the base implementation (<tt>RestrictionImpl.hashCode</tt>) relies on <tt>PropertyStateValue.hashCode</tt>, which includes the internal String representation, which is not optimal for binaries (see also <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-5784">OAK-5784</a>)</p></div></div>
<div class="section">
<h5><a name="Examples"></a>Examples</h5>
<div class="section">
<h6><a name="Example_RestrictionProvider"></a>Example RestrictionProvider</h6>
<p>Simple example of a <tt>RestrictionProvider</tt> that defines a single time-based <tt>Restriction</tt>, which is expected to have 2 values defining a start and end date, which can then be used to allow or deny access within the given time frame.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">@Component
+<div>
+<div>
+<pre class="source">@Component
@Service(RestrictionProvider.class)
public class MyRestrictionProvider extends AbstractRestrictionProvider {
@@ -573,13 +482,15 @@ public class MyRestrictionProvider exten
// TODO: implementing 'validateRestrictions(String oakPath, Tree aceTree)' would allow to make sure the property contains 2 date values.
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Example_RestrictionPattern"></a>Example RestrictionPattern</h6>
<p>The time-based <tt>RestrictionPattern</tt> used by the example provider above.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">class DatePattern implements RestrictionPattern {
+<div>
+<div>
+<pre class="source">class DatePattern implements RestrictionPattern {
private final Date start;
private final Date end;
@@ -616,12 +527,14 @@ public class MyRestrictionProvider exten
return d.after(start) && d.before(end);
}
};
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Example_Non-OSGI_Setup"></a>Example Non-OSGI Setup</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">RestrictionProvider rProvider = CompositeRestrictionProvider.newInstance(new MyRestrictionProvider(), ...);
+<div>
+<div>
+<pre class="source">RestrictionProvider rProvider = CompositeRestrictionProvider.newInstance(new MyRestrictionProvider(), ...);
Map<String, RestrictionProvider> authorizMap = ImmutableMap.of(PARAM_RESTRICTION_PROVIDER, rProvider);
ConfigurationParameters config = ConfigurationParameters.of(ImmutableMap.of(AuthorizationConfiguration.NAME, ConfigurationParameters.of(authorizMap)));
SecurityProvider securityProvider = SecurityProviderBuilder.newBuilder().with(config).build();
Modified: jackrabbit/site/live/oak/docs/security/introduction.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/introduction.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/introduction.html (original)
+++ jackrabbit/site/live/oak/docs/security/introduction.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Introduction to Oak Security</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,69 +240,57 @@
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.
- --><div class="section">
+ -->
+<div class="section">
<h2><a name="Introduction_to_Oak_Security"></a>Introduction to Oak Security</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
-<p>The main entry point to Oak security is the <tt>SecurityProvider</tt>, 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. </p>
+<p>The main entry point to Oak security is the <tt>SecurityProvider</tt>, 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.</p>
<p>Each security module comes with one or multiple <tt>SecurityConfiguration</tt>(s) that are registered with the provider, identified (and possibly aggregated) by their name.</p></div>
<div class="section">
<h3><a name="Modules"></a>Modules</h3>
<p>Currently Oak comes with the following built-in security modules, each defined by a dedicated sub-interfaces of <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityConfiguration.html">SecurityConfiguration</a>:</p>
-
<ul>
-
+
<li>Authentication
-
<ul>
-
+
<li><a href="authentication.html">Authentication</a> s.str.</li>
-
<li><a href="authentication/tokenmanagement.html">Token Authentication and Token Management</a></li>
- </ul></li>
-
+</ul>
+</li>
<li>Authorization
-
<ul>
-
+
<li><a href="authorization.html">Authorization</a> s.str. including <a href="accesscontrol.html">Access Control Management</a> and <a href="permission.html">Permission Evaluation</a></li>
-
<li><a href="privilege.html">Privilege Management</a></li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="principal.html">Principal Management</a></li>
-
<li><a href="user.html">User Management</a></li>
</ul>
-<p><a name="api_extensions"></a></p></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
-<p>The package <tt>org.apache.jackrabbit.oak.spi.security</tt> defines the following interfaces and base implementations:</p>
+<a name="api_extensions"></a>
+### API Extensions
+<p>The package <tt>org.apache.jackrabbit.oak.spi.security</tt> defines the following interfaces and base implementations:</p>
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityProvider.html">SecurityProvider</a>: Main entry point for Oak security.
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/OpenSecurityProvider.html">OpenSecurityProvider</a>: Rudimentary implementation for test purpose with the minimal required setup.</li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityConfiguration.html">SecurityConfiguration</a>: Base interface for all security related configurations.
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/SecurityConfiguration.Default.html">SecurityConfiguration.Default</a>: Default base implementation return default implementations for initializers, context as well as empty parameters, hooks, validators etc.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/ConfigurationBase.html">ConfigurationBase</a>: Abstract base implementation of the <tt>SecurityConfiguration</tt> interface.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/CompositeConfiguration.html">CompositeConfiguration</a>: Abstract base implementation for all composite configurations that allow for aggregation of multiple modules.</li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/ConfigurationParameters.html">ConfigurationParameters</a>: Utility used to pass around parameters and options.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/Context.html">Context</a>: Context information that allows to identify items defined and maintained by a give security module implementation.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/RegistrationConstants.html">RegistrationConstants</a>: Utility used to define well-known registration properties</li>
</ul>
<div class="section">
@@ -317,33 +305,29 @@
<p>In a non-OSGi setup the <tt>SecurityProvider</tt> (be it the default or a custom implementation) gets passed to the repository constructor. See section <a href="#pluggability">pluggability</a> for details wrt module initialization.</p>
<p>The following example has been extracted from the basic test setup:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">NodeStore nodeStore = ...
+<div>
+<div>
+<pre class="source">NodeStore nodeStore = ...
ConfigurationParameters params = ... // TODO: provide config options
// Optional: set additional/custom implementations of the supported `SecurityConfiguration`s via the params
SecurityProvider sp = SecurityProviderBuilder.newBuilder().with(params).build();
Repository repository = new Jcr(nodeStore).with(sp).createRepository();
-</pre></div></div></div></div>
+</pre></div></div>
+</div></div>
<div class="section">
<h4><a name="SecurityConfiguration"></a>SecurityConfiguration</h4>
<p>The <tt>SecurityConfiguration</tt> interface defines functionality common to all security related modules. Apart from simple configuration parameters the basic interface defines the means to properly initialize a given security module and provide Oak internal mechanism to asserts proper validation and data consistency for all security relevant operations.</p>
<p>Please note, that <tt>RepositoryInitializer</tt> and <tt>WorkspaceInitializer</tt> as exposed by the base interface are only invoked upon repository|workspace initialization and consequently impact the <a href="#pluggability">pluggability</a> of a given security module. Examples includes modules that require modifications to the global repository content such as node types, namespaces and privileges or require the installation of initial content or index definitions for proper execution.</p>
<p>The following subinterfaces of <tt>SecurityConfiguration</tt> are currently defined by Oak:</p>
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthenticationConfiguration.html">AuthenticationConfiguration</a>, <b>mandatory</b></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html">AuthorizationConfiguration</a>, <b>mandatory</b></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.html">PrincipalConfiguration</a></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.html">PrivilegeConfiguration</a></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/TokenConfiguration.html">TokenConfiguration</a></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/user/UserConfiguration.html">UserConfiguration</a></li>
</ul>
<div class="section">
@@ -352,11 +336,12 @@ Repository repository = new Jcr(nodeStor
<p>This is compliant with the security requirements defined by JSR 283 which defines API to login into the repository and mandates minimal permission evaluation, be it implementation specific of imposed by the optional access control management.</p>
<p>The minimal security setup may consequently be reduced to a setup as defined by the following imaginary, custom <tt>SecurityProvider</tt> (see also <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/OpenSecurityProvider.html">OpenSecurityProvider</a>)</p>
-<div class="source">
-<div class="source"><pre class="prettyprint"> public class MySecurityProvider implements SecurityProvider {
-
+<div>
+<div>
+<pre class="source"> public class MySecurityProvider implements SecurityProvider {
+
[...]
-
+
public <T> T getConfiguration(Class<T> configClass) {
if (AuthenticationConfiguration.class == configClass) {
return (T) new MyAuthentication();
@@ -366,11 +351,11 @@ Repository repository = new Jcr(nodeStor
throw new IllegalArgumentException();
}
}
-
+
private final class MyAuthentication extends SecurityConfiguration.Default implements AuthenticationConfiguration {
[...]
}
-
+
private final class MyAuthorization extends SecurityConfiguration.Default implements AuthorizationConfiguration {
public AccessControlManager getAccessControlManager(Root root, NamePathMapper namePathMapper) {
throw new UnsupportedOperationException();
@@ -384,183 +369,129 @@ Repository repository = new Jcr(nodeStor
}
}
</pre></div></div>
-<p>All other security modules can be considered <i>optional</i> from an Oak repository point of view. Please note the following dependencies and special cases:</p>
+<p>All other security modules can be considered <i>optional</i> from an Oak repository point of view. Please note the following dependencies and special cases:</p>
<ol style="list-style-type: decimal">
-
-<li><b>Authentication</b> is mandatory and expected to bind a set of <tt>Principal</tt>s to the <tt>Subject</tt>. This may happen before or during the repository login.</li>
-
-<li><b>Permission Evaluation</b> is mandatory and associated with the set of <tt>Principal</tt>s bound to to the <tt>Subject</tt> during the authentication step.</li>
-
-<li><tt>Principal</tt>s represent the link between authentication and authorization and <i>MAY</i> be exposed by Principal Management module as described above.</li>
-
-<li><b>Access Control Management</b> is optional and <i>usually</i> goes along with Principal and Privilege Management</li>
-
-<li><b>Principal Management</b> is optional and is <i>NOT</i> tied to User Management. However, supporting User Management in a given repository setup <i>usually</i> goes along with exposing the corresponding principals as part of the Principal Management.</li>
-
-<li><b>User Management</b> is optional and <i>MAY</i> be used for credentials validation during the authentication step. If present it is <i>usually</i> used as a source for principals exposed by Principal Management.</li>
+
+<li><b>Authentication</b> is mandatory and expected to bind a set of <tt>Principal</tt>s to the <tt>Subject</tt>. This may happen before or during the repository login.</li>
+<li><b>Permission Evaluation</b> is mandatory and associated with the set of <tt>Principal</tt>s bound to to the <tt>Subject</tt> during the authentication step.</li>
+<li><tt>Principal</tt>s represent the link between authentication and authorization and <i>MAY</i> be exposed by Principal Management module as described above.</li>
+<li><b>Access Control Management</b> is optional and <i>usually</i> goes along with Principal and Privilege Management</li>
+<li><b>Principal Management</b> is optional and is <i>NOT</i> tied to User Management. However, supporting User Management in a given repository setup <i>usually</i> goes along with exposing the corresponding principals as part of the Principal Management.</li>
+<li><b>User Management</b> is optional and <i>MAY</i> be used for credentials validation during the authentication step. If present it is <i>usually</i> used as a source for principals exposed by Principal Management.</li>
</ol>
-<p><a name="configuration"></a></p></div></div></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
-<p>The configuration parameters of individual security modules are described in the corresponding sections. The following paragraphs describe the configuration of <tt>SecurityProvider</tt> and <tt>CompositeConfiguration</tt> in an OSGi-base setup.</p>
+<a name="configuration"></a>
+### Configuration
+
+<p>The configuration parameters of individual security modules are described in the corresponding sections. The following paragraphs describe the configuration of <tt>SecurityProvider</tt> and <tt>CompositeConfiguration</tt> in an OSGi-base setup.</p></div></div>
<div class="section">
<h4><a name="SecurityProviderRegistration"></a>SecurityProviderRegistration</h4>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>Required Services</tt> </td>
-
-<td>String[] </td>
-
-<td>see below </td>
-
-<td>Service references mandatory for the SecurityProvider registration. </td>
- </tr>
- </tbody>
+<td> <tt>Required Services</tt> </td>
+<td> String[] </td>
+<td> see below </td>
+<td> Service references mandatory for the SecurityProvider registration. </td></tr>
+</tbody>
</table>
<p>The value of the individual configuration entries can be one of:</p>
-
<ul>
-
+
<li>the value of the <tt>service.pid</tt> registration property</li>
-
<li>the value of the <tt>oak.security.name</tt> registration property</li>
</ul>
<p>By default the <tt>SecurityProviderRegistration</tt> defines the following mandatory services. As long as these required references are not resolved the <tt>SecurityProviderRegistration</tt> will not register the <tt>SecurityProvider</tt> service and ultimately prevent premature initialization of the Oak repository instance.</p>
-
<ul>
-
+
<li>“org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl”</li>
-
<li>“org.apache.jackrabbit.oak.security.principal.PrincipalConfigurationImpl”,</li>
-
<li>“org.apache.jackrabbit.oak.security.authentication.token.TokenConfigurationImpl”,</li>
-
<li>“org.apache.jackrabbit.oak.spi.security.user.action.DefaultAuthorizableActionProvider”,</li>
-
<li>“org.apache.jackrabbit.oak.security.authorization.restriction.RestrictionProviderImpl”,</li>
-
<li>“org.apache.jackrabbit.oak.security.user.UserAuthenticationFactoryImpl”</li>
</ul>
<p>The value of this configuration parameter needs to be adjusted for any additional module or functionality that is considered required for a successful security setup. See section <a href="#pluggability">pluggability</a> below.</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>Authorization Composition Type</tt> </td>
-
-<td>String (AND|OR) </td>
-
-<td>AND </td>
-
-<td>The Composite Authorization model uses this flag to determine what type of logic to apply to the existing providers</td>
- </tr>
- </tbody>
+<td> <tt>Authorization Composition Type</tt> </td>
+<td> String (AND|OR) </td>
+<td> AND </td>
+<td> The Composite Authorization model uses this flag to determine what type of logic to apply to the existing providers</td></tr>
+</tbody>
</table>
<p>Given a set of permission providers, the composite model can aggregate the results by applying an <tt>AND</tt> logic (for example all providers must allow a specific privilege in order to be granted), or an <tt>OR</tt> (for example any provider can allow a privilege). By default the <tt>AND</tt> version is used.</p></div>
<div class="section">
<h4><a name="CompositeConfiguration"></a>CompositeConfiguration</h4>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>PARAM_RANKING</tt> </td>
-
-<td>int </td>
-
-<td><tt>NO_RANKING</tt> (<tt>Integer.MIN_VALUE</tt>) </td>
-
-<td>Optional configuration parameter to define the ranking within the aggregation. </td>
- </tr>
- </tbody>
+<td> <tt>PARAM_RANKING</tt> </td>
+<td> int </td>
+<td> <tt>NO_RANKING</tt> (<tt>Integer.MIN_VALUE</tt>) </td>
+<td> Optional configuration parameter to define the ranking within the aggregation. </td></tr>
+</tbody>
</table>
<p>Note: Security modules that allow for multiple configurations may choose to expose the <tt>PARAM_RANKING</tt> option in order to allow for explicit ordering of the individual implementations. If the ranking parameter is omitted the <tt>CompositeConfiguration</tt> will try to use the <a class="externalLink" href="https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#SERVICE_RANKING">SERVICE_RANKING</a> to define the order. If neither is available (or set to <tt>NO_RANKING</tt>) the new entry will be appended to the list.</p>
-<p><a name="pluggability"></a></p></div></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
+<a name="pluggability"></a>
+### Pluggability
+
<p>In a default setup Oak allows to plug custom or additional implementations of the various <tt>SecurityConfiguration</tt> described before. Similarly it would be possible to provide a custom <tt>SecurityProvider</tt>.</p>
-<p><i>Please note</i>: this is only recommended for experts having in-depth understanding of Oak internals and which understand the security risk associated with custom replacements or extensions.</p>
+<p><i>Please note</i>: this is only recommended for experts having in-depth understanding of Oak internals and which understand the security risk associated with custom replacements or extensions.</p></div>
<div class="section">
<h4><a name="SecurityProvider"></a>SecurityProvider</h4>
<p>The default <tt>SecurityProvider</tt> service could be replaced by deploying a custom service to the OSGi container. In a non-OSGi setup the JCR|Oak repository needs to be created with the custom implementation:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">SecurityProvider sp = new MySecurityProvider();
+<div>
+<div>
+<pre class="source">SecurityProvider sp = new MySecurityProvider();
Repository repository = new Jcr().with(sp).createRepository();
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h4><a name="SecurityConfiguration"></a>SecurityConfiguration</h4>
<p>The default Oak security setup distinguishes between the following types of modules:</p>
-
<ul>
-
+
<li>Unary modules: <tt>AuthenticationConfiguration</tt>, <tt>PrivilegeConfiguration</tt>, <tt>UserConfiguration</tt></li>
-
<li>Multiple modules: <tt>AuthorizationConfiguration</tt> (since Oak 1.4), <tt>PrincipalConfiguration</tt>, <tt>TokenConfiguration</tt></li>
</ul>
<p>Plugging an implementation of an unary module will replace the default provided by Oak. As far as the multiple modules are concerned a custom implementation plugged into the repository will result in the creation of a <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/CompositeConfiguration.html">CompositeConfiguration</a>. The aggregated modules are kept in a list while the insertion order is defined by the <tt>PARAM_RANKING</tt> or by the OSGi service ranking in case the explicit ranking parameter is missing.</p>
<div class="section">
<h5><a name="OSGi_setup"></a>OSGi setup</h5>
<p>The following steps are required to replace an existing <i>unary</i> security component or add an additional implementation (for <i>multiple</i> configurations only):</p>
-
<ul>
-
+
<li>Deploy the bundle containing your custom implementation</li>
-
<li>Configure the component according to your needs</li>
-
<li>For <i>multiple</i> configurations make sure you have set the desired ranking</li>
-
-<li>Find the <tt>SecurityProviderRegistration</tt> <i>(“Apache Jackrabbit Oak SecurityProvider”)</i> config and enter the PID of your custom security module as additional value to the <tt>requiredServicePids</tt> property.</li>
-
-<li>In case of a replacement remove the PID of the module to be replaced and make sure your implementation gets a higher <a class="externalLink" href="https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#SERVICE_RANKING">SERVICE_RANKING</a> or deactivate the obsolete module altogether.</li>
+<li>Find the <tt>SecurityProviderRegistration</tt> <i>(“Apache Jackrabbit Oak SecurityProvider”)</i> config and enter the PID of your custom security module as additional value to the <tt>requiredServicePids</tt> property.</li>
+<li>In case of a replacement remove the PID of the module to be replaced and make sure your implementation gets a higher <a class="externalLink" href="https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#SERVICE_RANKING">SERVICE_RANKING</a> or deactivate the obsolete module altogether.</li>
</ul></div>
<div class="section">
<h5><a name="Non-OSGi_setup"></a>Non-OSGi setup</h5>
@@ -569,8 +500,9 @@ Repository repository = new Jcr().with(s
<h6><a name="Example"></a>Example</h6>
<p>Extend the default <tt>SecurityProvider</tt> with a custom <tt>PrincipalConfiguration</tt>. See also <i>oak-exercise</i> module for an example.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">MyPrincipalConfiguration pc = new MyPrincipalConfiguration();
+<div>
+<div>
+<pre class="source">MyPrincipalConfiguration pc = new MyPrincipalConfiguration();
ConfigurationParameters params = ConfigurationParameters.EMPTY;
pc.setParameters(params);
@@ -587,13 +519,13 @@ composite.addConfiguration(pc);
composite.addConfiguration(defConfig);
Repository repo = new Jcr(new Oak()).with(securityProvider).createRepository();
-</pre></div></div></div></div>
+</pre></div></div>
+</div></div>
<div class="section">
<h5><a name="Initialization_of_SecurityConfigurations"></a>Initialization of SecurityConfiguration(s)</h5>
<p>If a given security modules mandates repository and|or workspace initialization steps such as e.g. node type registration or persisting new index definitions, the deployment of the module requires a reload of the <tt>SecurityProvider</tt>.</p>
-<p>In the default OSGi-based setup this is achieved by adding the PID of corresponding service to the <tt>Required Service PIDs</tt> property mentioned above ultimately forcing the re-registration of the <tt>SecurityProvider</tt> service with the bundle context. </p>
-<p>Other setup scenarios would need to recreate the <tt>ContentRepository</tt> object or adjust the repository ‘initial’ content <i>before</i> binding the new configuration to the <tt>SecurityProvider</tt> in order to avoid inconsistencies. </p>
-<!-- references --></div></div></div></div>
+<p>In the default OSGi-based setup this is achieved by adding the PID of corresponding service to the <tt>Required Service PIDs</tt> property mentioned above ultimately forcing the re-registration of the <tt>SecurityProvider</tt> service with the bundle context.</p>
+<p>Other setup scenarios would need to recreate the <tt>ContentRepository</tt> object or adjust the repository ‘initial’ content <i>before</i> binding the new configuration to the <tt>SecurityProvider</tt> in order to avoid inconsistencies.</p><!-- references --></div></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/overview.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/overview.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/overview.html (original)
+++ jackrabbit/site/live/oak/docs/security/overview.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – The Oak Security Layer</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -241,160 +241,124 @@
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.
- --><div class="section">
+ -->
+<div class="section">
<h2><a name="The_Oak_Security_Layer"></a>The Oak Security Layer</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
-
<ul>
-
+
<li><a href="introduction.html">Introduction to Oak Security</a></li>
</ul></div>
<div class="section">
<h3><a name="Authentication"></a>Authentication</h3>
-
<ul>
-
+
<li><a href="authentication.html">Overview</a></li>
-
<li><a href="authentication/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="authentication/default.html">Authentication : Implementation Details</a></li>
-
<li><a href="authentication/preauthentication.html">Pre-Authentication</a></li>
</ul>
<div class="section">
<h4><a name="Extensions"></a>Extensions</h4>
-
<ul>
-
+
<li><a href="authentication/tokenmanagement.html">Token Authentication and Token Management</a></li>
-
<li><a href="authentication/externalloginmodule.html">External Authentication</a>
-
<ul>
-
+
<li><a href="authentication/usersync.html">User and Group Synchronization</a></li>
-
<li><a href="authentication/identitymanagement.html">Identity Management</a></li>
-
<li><a href="authentication/ldap.html">LDAP Integration</a></li>
- </ul></li>
+</ul>
+</li>
</ul></div></div>
<div class="section">
<h3><a name="Authorization"></a>Authorization</h3>
-
<ul>
-
+
<li><a href="authorization.html">Overview</a>
-
<ul>
-
+
<li><a href="accesscontrol.html">Access Control Management</a></li>
-
<li><a href="permission.html">Permission Evalution</a></li>
-
<li><a href="authorization/composite.html">Combining Multiple Authorization Models</a></li>
- </ul></li>
+</ul>
+</li>
</ul>
<div class="section">
<h4><a name="Access_Control_Management"></a>Access Control Management</h4>
-
<ul>
-
+
<li><a href="accesscontrol.html">Overview</a></li>
-
<li><a href="accesscontrol/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="accesscontrol/default.html">Access Control Management : The Default Implementation</a></li>
-
<li><a href="accesscontrol/editing.html">Using the API</a></li>
</ul></div>
<div class="section">
<h4><a name="Permissions"></a>Permissions</h4>
-
<ul>
-
+
<li><a href="permission.html">Overview</a>
-
<ul>
-
+
<li><a href="permission/permissionsandprivileges.html">Permissions vs Privileges</a></li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="permission/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="permission/default.html">Permissions : The Default Implementation</a>
-
<ul>
-
+
<li><a href="permission/evaluation.html">Permission Evaluation in Detail</a></li>
- </ul></li>
+</ul>
+</li>
</ul></div>
<div class="section">
<h4><a name="Privilege_Management"></a>Privilege Management</h4>
-
<ul>
-
+
<li><a href="privilege.html">Overview</a></li>
-
<li><a href="privilege/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="privilege/default.html">Privilege Management : The Default Implementation</a></li>
-
<li>Mapping Privileges to Items and API Calls
-
<ul>
-
+
<li><a href="privilege/mappingtoitems.html">Mapping Privileges to Items</a></li>
-
<li><a href="privilege/mappingtoprivileges.html">Mapping API Calls to Privileges</a></li>
- </ul></li>
+</ul>
+</li>
</ul></div>
<div class="section">
<h4><a name="Extensions"></a>Extensions</h4>
-
<ul>
-
+
<li><a href="authorization/restriction.html">Restriction Management</a></li>
-
<li><a href="authorization/cug.html">Managing Access with Closed User Groups (CUG)</a></li>
</ul></div></div>
<div class="section">
<h3><a name="Principal_Management"></a>Principal Management</h3>
-
<ul>
-
+
<li><a href="principal.html">Overview</a></li>
-
<li><a href="principal/differences.html">Differences wrt Jackrabbit 2.x</a></li>
</ul></div>
<div class="section">
<h3><a name="User_Management"></a>User Management</h3>
-
<ul>
-
+
<li><a href="user.html">Overview</a></li>
-
<li><a href="user/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="user/default.html">User Management : The Default Implementation</a>
-
<ul>
-
+
<li><a href="user/membership.html">Group Membership</a></li>
-
<li><a href="user/authorizableaction.html">Authorizable Actions</a></li>
-
<li><a href="user/groupaction.html">Group Actions</a></li>
-
<li><a href="user/authorizablenodename.html">Authorizable Node Name Generation</a></li>
-
<li><a href="user/expiry.html">Password Expiry and Force Initial Password Change</a></li>
-
<li><a href="user/history.html">Password History</a></li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="user/query.html">Searching Users and Groups</a></li>
</ul></div></div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/permission.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Permissions</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,64 +240,49 @@
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.
---><div class="section">
-<h2><a name="Permissions"></a>Permissions</h2>
-<p><a name="jcr_api"></a></p>
+-->
<div class="section">
-<h3><a name="JCR_and_Jackrabbit_API"></a>JCR and Jackrabbit API</h3>
-<p>While access control management is a optional feature, a JCR implementation is required to support the basic permission checking. The basic requirements for the permission evalution are defines as follows</p>
+<h2><a name="Permissions"></a>Permissions</h2>
+<a name="jcr_api"></a>
+### JCR and Jackrabbit API
+<p>While access control management is a optional feature, a JCR implementation is required to support the basic permission checking. The basic requirements for the permission evalution are defines as follows</p>
<blockquote>
+
<p>Permissions encompass the restrictions imposed by any access control restrictions that may be in effect upon the content of a repository, either implementation specific or JCR-defined (Access Control Management)., which consists of</p>
</blockquote>
<p>The methods defined to check permissions:</p>
-
<ul>
-
+
<li><tt>Session#hasPermission(String absPath, String actions)</tt></li>
-
<li><tt>Session#checkPermission(String absPath, String actions)</tt></li>
-
<li><tt>JackrabbitSession.hasPermission(String absPath, @Nonnull String... actions)</tt> (since Jackrabbit API 2.11.0 and Oak 1.4)</li>
</ul>
<p>The actions are expected to be a comma separated list of any of the following string constants:</p>
-
<ul>
-
+
<li><tt>Session.ACTION_READ</tt></li>
-
<li><tt>Session.ACTION_ADD_NODE</tt></li>
-
<li><tt>Session.ACTION_REMOVE</tt></li>
-
<li><tt>Session.ACTION_SET_PROPERTY</tt></li>
</ul>
<p>And defined by Jackrabbit API the following additional actions (since Jackrabbit API 2.11.0):</p>
-
<ul>
-
+
<li><tt>JackrabbitSession.ACTION_ADD_PROPERTY</tt></li>
-
<li><tt>JackrabbitSession.ACTION_MODIFY_PROPERTY</tt></li>
-
<li><tt>JackrabbitSession.ACTION_REMOVE_PROPERTY</tt></li>
-
<li><tt>JackrabbitSession.ACTION_REMOVE_NODE</tt></li>
-
<li><tt>JackrabbitSession.ACTION_NODE_TYPE_MANAGEMENT</tt></li>
-
<li><tt>JackrabbitSession.ACTION_VERSIONING</tt></li>
-
<li><tt>JackrabbitSession.ACTION_LOCKING</tt></li>
-
<li><tt>JackrabbitSession.ACTION_READ_ACCESS_CONTROL</tt></li>
-
<li><tt>JackrabbitSession.ACTION_MODIFY_ACCESS_CONTROL</tt></li>
-
<li><tt>JackrabbitSession.ACTION_USER_MANAGEMENT</tt></li>
</ul>
<p><b>Note</b>: As of Oak 1.0 the these methods also handle the names of the permissions defined by Oak (see <tt>Permissions#getString(long permissions)</tt>).</p>
-<p>See also section <a href="permission/permissionsandprivileges.html">Permissions vs Privileges</a> for a comparison of these permission checks and testing privileges on the <tt>AccessControlManager</tt>. </p>
+<p>See also section <a href="permission/permissionsandprivileges.html">Permissions vs Privileges</a> for a comparison of these permission checks and testing privileges on the <tt>AccessControlManager</tt>.</p>
+<div class="section">
<div class="section">
<div class="section">
<h5><a name="Examples"></a>Examples</h5>
@@ -305,36 +290,41 @@
<h6><a name="Test_if_session_has_permission_to_add_a_new_node_JCR_API"></a>Test if session has permission to add a new node (JCR API)</h6>
<p>Important: <tt>absPath</tt> refers to the node to be created</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">Node content = session.getNode("/content");
+<div>
+<div>
+<pre class="source">Node content = session.getNode("/content");
if (session.hasPermission("/content/newNode", Session.ACTION_ADD_NODE)) {
content.addNode("newNode");
session.save();
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Test_if_session_has_permission_to_perform_version_and_lock_operations_Jackrabbit_API"></a>Test if session has permission to perform version and lock operations (Jackrabbit API)</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">Node content = jrSession.getNode("/content");
+<div>
+<div>
+<pre class="source">Node content = jrSession.getNode("/content");
if (jrSession.hasPermission("/content", JackrabbitSession.ACTION_VERSIONING, JackrabbitSession.ACTION_LOCKING))) {
content.checkin();
session.save();
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Test_if_session_has_permission_to_perform_version_operations_Oak_SPI"></a>Test if session has permission to perform version operations (Oak SPI)</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">Node content = session.getNode("/content");
+<div>
+<div>
+<pre class="source">Node content = session.getNode("/content");
if (session.hasPermission("/content", Permissions.getString(Permissions.VERSION_MANAGEMENT))) {
content.checkin();
session.save();
}
</pre></div></div>
-<p><a name="oak_permissions"></a></p></div></div></div></div>
-<div class="section">
-<h3><a name="Oak_Permissions"></a>Oak Permissions</h3>
+<a name="oak_permissions"></a>
+### Oak Permissions
+</div></div></div>
<div class="section">
<h4><a name="General_Notes"></a>General Notes</h4>
<p>As of Oak 1.0 Permission evaluation is intended to be completely separated from the access control management as defined by JCR and Jackrabbit API. While the evaluation and enforcing permissions is considered to be an internal feature of the Oak core module, the package <tt>org.apache.jackrabbit.oak.spi.security.authorization.permission</tt> provides some extensions points that allow to plug custom extensions or implementations the evaluation (see <a href="#api_extensions">API Extensions</a> below).</p></div>
@@ -344,243 +334,176 @@ if (session.hasPermission("/content
<div class="section">
<h5><a name="Simple_Permissions"></a>Simple Permissions</h5>
<p>Read operations:</p>
-
<ul>
-
+
<li><tt>READ_NODE</tt></li>
-
<li><tt>READ_PROPERTY</tt></li>
-
<li><tt>READ_ACCESS_CONTROL</tt></li>
</ul>
<p>Write operations:</p>
-
<ul>
-
+
<li><tt>ADD_NODE</tt></li>
-
<li><tt>REMOVE_NODE</tt></li>
-
<li><tt>MODIFY_CHILD_NODE_COLLECTION</tt></li>
-
<li><tt>ADD_PROPERTY</tt></li>
-
<li><tt>MODIFY_PROPERTY</tt></li>
-
<li><tt>REMOVE_PROPERTY</tt></li>
-
<li><tt>NODE_TYPE_MANAGEMENT</tt></li>
-
<li><tt>MODIFY_ACCESS_CONTROL</tt></li>
-
<li><tt>LOCK_MANAGEMENT</tt></li>
-
<li><tt>VERSION_MANAGEMENT</tt></li>
</ul>
<p>Since Oak 1.0:</p>
-
<ul>
-
+
<li><tt>USER_MANAGEMENT</tt>: : execute user management related tasks such as e.g. creating or removing user/group, changing user password and editing group membership.</li>
-
<li><tt>INDEX_DEFINITION_MANAGEMENT</tt>: create, modify and remove the oak:index node and it’s subtree which is expected to contain the index definitions.</li>
</ul>
<p>Repository operations:</p>
-
<ul>
-
+
<li><tt>NODE_TYPE_DEFINITION_MANAGEMENT</tt></li>
-
<li><tt>NAMESPACE_MANAGEMENT</tt></li>
-
<li><tt>PRIVILEGE_MANAGEMENT</tt></li>
-
<li><tt>WORKSPACE_MANAGEMENT</tt></li>
</ul>
<p>Not used in Oak 1.0:</p>
-
<ul>
-
+
<li><tt>LIFECYCLE_MANAGEMENT</tt></li>
-
<li><tt>RETENTION_MANAGEMENT</tt></li>
</ul></div>
<div class="section">
<h5><a name="Aggregated_Permissions"></a>Aggregated Permissions</h5>
-
<ul>
-
+
<li><tt>READ</tt>: aggregates <tt>READ_NODE</tt> and <tt>READ_PROPERTY</tt></li>
-
<li><tt>REMOVE</tt>: aggregates <tt>REMOVE_NODE</tt> and <tt>REMOVE_PROPERTY</tt></li>
-
<li><tt>SET_PROPERTY</tt>: aggregates <tt>ADD_PROPERTY</tt>, <tt>MODIFY_PROPERTY</tt> and <tt>REMOVE_PROPERTY</tt></li>
-
<li><tt>WRITE</tt>: aggregates <tt>ADD_NODE</tt>, <tt>REMOVE_NODE</tt> and <tt>SET_PROPERTY</tt></li>
-
<li><tt>ALL</tt>: aggregates all permissions</li>
</ul></div></div>
<div class="section">
<h4><a name="Mapping_of_JCR_Actions_to_Oak_Permissions"></a>Mapping of JCR Actions to Oak Permissions</h4>
<p><tt>ACTION_READ</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.READ_ACCESS_CONTROL</tt></li>
-
<li>regular nodes: <tt>Permissions.READ_NODE</tt></li>
-
<li>regular properties: <tt>Permissions.READ_PROPERTY</tt></li>
-
<li>non-existing items: <tt>Permissions.READ</tt></li>
</ul>
<p><tt>ACTION_ADD_NODE</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>regular nodes: <tt>Permissions.ADD_NODE</tt></li>
</ul>
<p><tt>ACTION_REMOVE</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>regular nodes: <tt>Permissions.REMOVE_NODE</tt></li>
-
<li>regular properties: <tt>Permissions.REMOVE_PROPERTY</tt></li>
-
<li>non-existing nodes: <tt>Permissions.REMOVE</tt></li>
</ul>
<p><tt>ACTION_SET_PROPERTY</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>regular properties: <tt>Permissions.MODIFY_PROPERTY</tt></li>
-
<li>non-existing properties: <tt>Permissions.ADD_PROPERTY</tt></li>
</ul>
<p><tt>ACTION_ADD_PROPERTY</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>other properties: <tt>Permissions.ADD_PROPERTY</tt></li>
</ul>
<p><tt>ACTION_MODIFY_PROPERTY</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>other properties: <tt>Permissions.MODIFY_PROPERTY</tt></li>
</ul>
<p><tt>ACTION_REMOVE_PROPERTY</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>other properties: <tt>Permissions.REMOVE_PROPERTY</tt></li>
</ul>
<p><tt>ACTION_REMOVE_NODE</tt>:</p>
-
<ul>
-
+
<li>access control content: <tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
-
<li>regular nodes: <tt>Permissions.REMOVE_NODE</tt></li>
</ul>
<p><tt>ACTION_NODE_TYPE_MANAGEMENT</tt></p>
-
<ul>
-
+
<li><tt>Permissions.NODE_TYPE_MANAGEMENT</tt></li>
</ul>
<p><tt>ACTION_VERSIONING</tt></p>
-
<ul>
-
+
<li><tt>Permissions.VERSION_MANAGEMENT</tt></li>
</ul>
<p><tt>ACTION_LOCKING</tt></p>
-
<ul>
-
+
<li><tt>Permissions.LOCK_MANAGEMENT</tt></li>
</ul>
<p><tt>ACTION_READ_ACCESS_CONTROL</tt></p>
-
<ul>
-
+
<li><tt>Permissions.READ_ACCESS_CONTROL</tt></li>
</ul>
<p><tt>ACTION_MODIFY_ACCESS_CONTROL</tt></p>
-
<ul>
-
+
<li><tt>Permissions.MODIFY_ACCESS_CONTROL</tt></li>
</ul>
<p><tt>ACTION_USER_MANAGEMENT</tt></p>
-
<ul>
-
+
<li><tt>Permissions.USER_MANAGEMENT</tt></li>
</ul></div>
<div class="section">
<h4><a name="Permissions_for_Different_Operations"></a>Permissions for Different Operations</h4>
<div class="section">
<h5><a name="Reading"></a>Reading</h5>
-
<ul>
-
+
<li><b>Regular Items</b>: Due to the fine grained read permissions Oak read access can be separately granted/denied for nodes and properties. Granting the <tt>jcr:read</tt> privilege will result in a backwards compatible read access for nodes and their properties, while specifying <tt>rep:readNodes</tt> or <tt>rep:readProperties</tt> privileges allows to grant or deny access to nodes and properties (see also <a href="privilege.html">Privilege Management</a> 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).</li>
-
<li><b>Version Content</b>: The accessibility of version content located underneath <tt>/jcr:system/jcr:versionStore</tt> is defined by the permissions present with the versionable node. In case the version information does no longer have a versionable node in this workspace it’s original versionable path is used to evaluate the effective permissions that would apply to that item if the version was restored. This change is covered by <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-444">OAK-444</a> and addresses concerns summarized in <a class="externalLink" href="https://issues.apache.org/jira/browse/JCR-2963">JCR-2963</a>.</li>
-
<li><b>Access Control Content</b> Read access to access control content such node storing policy or ACE information requires <tt>READ_ACCESS_CONTROL</tt> permission.</li>
</ul></div>
<div class="section">
<h5><a name="Writing"></a>Writing</h5>
-
<ul>
-
+
<li><b>Property Modification</b>: Since Oak the former <tt>SET_PROPERTY</tt> 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 <tt>Subject</tt> is only allowed to create content without having the ability to modify/delete it later on.</li>
-
<li><b>Node Removal</b>: As of Oak <tt>Node#remove()</tt> only requires sufficient permissions to remove the target node. See below for configuration parameters to obtain backwards compatible behavior.</li>
-
<li><b>Rename</b>: Due to the nature of the diff mechanism in Oak it is no longer possible to distinguish between <tt>JackrabbitNode#rename</tt> and a move with subsequent reordering.</li>
-
<li><b>Move</b>: The current permission evaluation attempts to provide a best-effort handling to achieve a similar behavior that it was present in Jackrabbit 2.x by keeping track of transient move operations. The current implementation has the following limitations with respect to multiple move operations within a given set of transient operations:
-
<ul>
-
+
<li>Move operations that replace an node that has been moved away will not be detected as modification by the diff mechanism and regular permission checks for on the subtree will be performed.</li>
-
<li>Moving an ancestor of a node that has been moved will only detect the second move and will enforce regular permissions checks on the child that has been moved in a first step.</li>
- </ul></li>
-
+</ul>
+</li>
<li><b>Managing Index Definitions</b>: 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.</li>
</ul></div>
<div class="section">
<h5><a name="Writing_Protected_Items"></a>Writing Protected Items</h5>
<p>Writing protected items requires specific permissions and is not covered by regular JCR write permissions. This affects:</p>
-
<ul>
-
+
<li><b>Set/Modify Primary or Mixin Type</b>: <tt>NODE_TYPE_MANAGEMENT</tt></li>
-
<li><b>Access Control Content</b>: <tt>MODIFY_ACCESS_CONTROL</tt></li>
-
<li><b>Locking</b>: <tt>LOCK_MANAGEMENT</tt></li>
-
<li><b>Versioning</b>: Executing version related operations and thus writing to the version store requires <tt>VERSION_MANAGEMENT</tt> permission instead of the regular JCR write permissions. Similarly, the content in the version store can only be modified using the dedicated version management API.</li>
-
<li><b>User Management</b>: By default user management operations require the specific user management related permission <tt>USER_MANAGEMENT</tt> 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.</li>
</ul></div>
<div class="section">
@@ -588,71 +511,58 @@ if (session.hasPermission("/content
<p>Permission evaluation is also applied when delivering observation events respecting the effective permission setup of the <tt>Session</tt> that registered the <tt>EventListener</tt>.</p>
<p>However, it is important to understand that events are only delivered once the modifications have been successfully persisted and permissions will be evaluated against the persisted state.</p>
<p>In other words: Changing the permission setup along with the modifications to be reported to the <tt>EventListener</tt> will result in events being included or excluded according to the modified permissions. See <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-4196">OAK-4196</a> for an example.</p>
-<p><a name="api_extensions"></a></p></div></div></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
+<a name="api_extensions"></a>
+### API Extensions
+
<p>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.</p>
<p>The package <tt>org.apache.jackrabbit.oak.spi.security.authorization.permission</tt> defines the following interfaces and classes:</p>
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/PermissionProvider.html">PermissionProvider</a>: Main entry point for permission discovery and evaluation.
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/TreePermission.html">TreePermission</a>: Evaluates the permissions of a given Oak <tt>Tree</tt>, exposed by <tt>PermissionProvider</tt>.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/RepositoryPermission.html">RepositoryPermission</a>: Evaluates the repository level permissions, exposed by <tt>PermissionProvider</tt>.</li>
- </ul></li>
-
+</ul>
+</li>
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/AggregatedPermissionProvider.html">AggregatedPermissionProvider</a>: Extension of the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/PermissionProvider.html">PermissionProvider</a> required for implementations that are intended to be used in an aggregation of multiple providers (since Oak 1.4)</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/Permissions.html">Permissions</a>: The permissions defined, respected and evaluated by the repository.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/PermissionConstants.html">PermissionConstants</a>: Constants used throughout the permission evaluation.</li>
</ul>
-<p><a name="default_implementation"></a></p></div>
-<div class="section">
-<h3><a name="Characteristics_of_the_Permission_Evaluation"></a>Characteristics of the Permission Evaluation</h3>
-<p>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 <tt>PermissionProvider</tt>.</p>
-<p>Each JCR <tt>Session</tt> (and Oak <tt>ContentSession</tt>) gets it’s own <tt>PermissionProvider</tt> 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.</p>
+<a name="default_implementation"></a>
+### Characteristics of the Permission Evaluation
+
+<p>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 <tt>PermissionProvider</tt>.</p>
+<p>Each JCR <tt>Session</tt> (and Oak <tt>ContentSession</tt>) gets it’s own <tt>PermissionProvider</tt> 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.</p></div></div>
<div class="section">
<h4><a name="Differences_wrt_Jackrabbit_2.x"></a>Differences wrt Jackrabbit 2.x</h4>
<p>see the corresponding <a href="permission/differences.html">documentation</a>.</p></div>
<div class="section">
<h4><a name="Details_on_the_Default_Permission_Evaluation"></a>Details on the Default Permission Evaluation</h4>
<p>The behavior of the default permission implementation is described in sections <a href="permission/default.html">Permissions: The Default Implementation</a> and <a href="permission/evaluation.html">Permission Evaluation in Detail: The Default Implementation</a>.</p>
-<p><a name="configuration"></a></p></div></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
-<p>The configuration of the permission evaluation implementation is handled by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html">AuthorizationConfiguration</a>, which is used for all authorization related matters. This class provides the following two permission related methods:</p>
+<a name="configuration"></a>
+### Configuration
+<p>The configuration of the permission evaluation implementation is handled by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html">AuthorizationConfiguration</a>, which is used for all authorization related matters. This class provides the following two permission related methods:</p>
<ul>
-
+
<li><tt>getPermissionProvider(Root, String, Set<Principal>)</tt>: get a new <tt>PermissionProvider</tt> instance.</li>
-</ul>
+</ul></div>
<div class="section">
<h4><a name="Configuration_Parameters"></a>Configuration Parameters</h4>
<p>The supported configuration options of the default implementation are described in the corresponding <a href="permission/default.html#configuration">section</a>.</p>
-<p><a name="further_reading"></a></p></div></div>
-<div class="section">
-<h3><a name="Further_Reading"></a>Further Reading</h3>
+<a name="further_reading"></a>
+### Further Reading
<ul>
-
+
<li><a href="permission/permissionsandprivileges.html">Permissions vs Privileges</a></li>
-
<li><a href="permission/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="permission/default.html">Permissions : The Default Implementation</a></li>
-
<li><a href="permission/evaluation.html">Permission Evaluation in Detail</a></li>
-
<li><a href="permission/multiplexing.html">Multiplexed PermissionStore</a></li>
-
<li><a href="authorization/restriction.html">Restriction Management</a></li>
-</ul>
-<!-- references --></div></div>
+</ul><!-- references --></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/permission/default.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission/default.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission/default.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission/default.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Permissions : The Default Implementation</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,57 +240,52 @@
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.
---><div class="section">
+-->
+<div class="section">
<h2><a name="Permissions_:_The_Default_Implementation"></a>Permissions : The Default Implementation</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
<p>The default implementation of the <tt>PermissionProvider</tt> interface evaluates permissions based on the information stored in a dedicated part of the repository content call the <a href="#permissionStore">permission store</a>.</p>
-<p><a name="default_implementation"></a></p></div>
-<div class="section">
-<h3><a name="Characteristics_of_the_Permission_Evaluation"></a>Characteristics of the Permission Evaluation</h3>
+<a name="default_implementation"></a>
+### Characteristics of the Permission Evaluation
+
<div class="section">
<h4><a name="Regular_Permission_Evaluation"></a>Regular Permission Evaluation</h4>
<p>See section <a href="evaluation.html">Permission Evaluation in Detail</a>.</p></div>
<div class="section">
<h4><a name="Readable_Trees"></a>Readable Trees</h4>
<p>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:</p>
-
<ul>
-
+
<li><tt>/jcr:system/rep:namespaces</tt>: stores all registered namespaces</li>
-
<li><tt>/jcr:system/jcr:nodeTypes</tt>: stores all registered node types</li>
-
<li><tt>/jcr:system/rep:privileges</tt>: stores all registered privileges</li>
</ul>
<p>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.</p></div>
<div class="section">
<h4><a name="Administrative_Access"></a>Administrative Access</h4>
<p>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:</p>
-
<ul>
-
+
<li><tt>SystemPrincipal</tt></li>
-
<li>All instances of <tt>AdminPrincipal</tt></li>
-
<li>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. <tt>User#isAdmin</tt>).</li>
</ul></div>
<div class="section">
<h4><a name="Permission_Evaluation_in_Multiplexed_Stores"></a>Permission Evaluation in Multiplexed Stores</h4>
<p>See section <a href="multiplexing.html">Multiplexing support in the PermissionStore</a>.</p>
-<p><a name="representation"></a></p></div></div>
-<div class="section">
-<h3><a name="Representation_in_the_Repository"></a>Representation in the Repository</h3>
-<p><a name="permissionStore"></a></p>
-<div class="section">
-<h4><a name="Permission_Store"></a>Permission Store</h4>
+<a name="representation"></a>
+### Representation in the Repository
+<a name="permissionStore"></a>
+#### Permission Store
+
<p>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 <tt>PostValidationHook</tt> implementation ([PermissionHook]).</p>
<p>The location of the permission store is <tt>/jcr:system/rep:permissionStore</tt>; in accordance with other stores underneath <tt>jcr:system</tt> it is global to the whole repository keeping a separate entry for each workspace present with the repository.</p>
<p>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.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">/jcr:system/rep:permissionStore/workspace-name [rep:PermissionStore]
+<div>
+<div>
+<pre class="source">/jcr:system/rep:permissionStore/workspace-name [rep:PermissionStore]
/principal-name [rep:PermissionStore]
/1259237738 [rep:PermissionStore]
/0 [rep:Permissions]
@@ -307,10 +302,12 @@
/0 [rep:Permissions]
/1 [rep:Permissions]
</pre></div></div>
+
<p>Each per path store looks as follows</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">"1259237738" {
+<div>
+<div>
+<pre class="source">"1259237738" {
"jcr:primaryType": "rep:PermissionStore",
"rep:accessControlledPath": "/content",
"0": {
@@ -322,6 +319,7 @@
}
}
</pre></div></div>
+
<div class="section">
<h5><a name="Accessing_the_Permission_Store"></a>Accessing the Permission Store</h5>
<p>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.</p>
@@ -330,8 +328,9 @@
<h4><a name="Node_Type_Definitions"></a>Node Type Definitions</h4>
<p>For the permission store the following built-in node types have been defined:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">[rep:PermissionStore]
+<div>
+<div>
+<pre class="source">[rep:PermissionStore]
- rep:accessControlledPath (STRING) protected IGNORE
- rep:numPermissions (LONG) protected IGNORE
- rep:modCount (LONG) protected IGNORE
@@ -343,127 +342,81 @@
- * (UNDEFINED) protected multiple IGNORE
+ * (rep:Permissions) = rep:Permissions protected IGNORE
</pre></div></div>
+
<p>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 (<tt>VersionablePathHook</tt>).</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">[rep:VersionablePaths]
+<div>
+<div>
+<pre class="source">[rep:VersionablePaths]
mixin
- * (PATH) protected ABORT
</pre></div></div>
-<p><a name="validation"></a></p></div></div>
-<div class="section">
-<h3><a name="Validation"></a>Validation</h3>
-<p>The consistency of this content structure is asserted by a dedicated <tt>PermissionValidator</tt>. The corresponding errors are all of type <tt>Access</tt> with the following codes:</p>
+<a name="validation"></a>
+### Validation
+<p>The consistency of this content structure is asserted by a dedicated <tt>PermissionValidator</tt>. The corresponding errors are all of type <tt>Access</tt> with the following codes:</p>
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Code </th>
-
-<th>Message </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Code </th>
+<th> Message </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td>0000 </td>
-
-<td>Generic access violation </td>
- </tr>
-
+<td> 0000 </td>
+<td> Generic access violation </td></tr>
<tr class="a">
-
-<td>0021 </td>
-
-<td>Version storage: Node creation without version history </td>
- </tr>
-
+<td> 0021 </td>
+<td> Version storage: Node creation without version history </td></tr>
<tr class="b">
-
-<td>0022 </td>
-
-<td>Version storage: Removal of intermediate node </td>
- </tr>
- </tbody>
+<td> 0022 </td>
+<td> Version storage: Removal of intermediate node </td></tr>
+</tbody>
</table>
-<p><a name="configuration"></a></p></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
+<a name="configuration"></a>
+### Configuration
+</div>
<div class="section">
<h4><a name="Configuration_Parameters"></a>Configuration Parameters</h4>
<p>The default implementation supports the following configuration parameters:</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>PARAM_PERMISSIONS_JR2</tt> </td>
-
-<td>String </td>
-
-<td>- </td>
-
-<td>Enables backwards compatible behavior for the permissions listed in the parameter value containing the permission names separated by ‘,’. Supported values are: <tt>USER_MANAGEMENT</tt>,<tt>REMOVE_NODE</tt> </td>
- </tr>
-
+<td> <tt>PARAM_PERMISSIONS_JR2</tt> </td>
+<td> String </td>
+<td> - </td>
+<td> Enables backwards compatible behavior for the permissions listed in the parameter value containing the permission names separated by ‘,’. Supported values are: <tt>USER_MANAGEMENT</tt>,<tt>REMOVE_NODE</tt> </td></tr>
<tr class="a">
-
-<td><tt>PARAM_READ_PATHS</tt> </td>
-
-<td>Set<String> </td>
-
-<td>paths to namespace, nodetype and privilege root nodes </td>
-
-<td>Set of paths that are always readable to all principals irrespective of other permissions defined at that path or inherited from other nodes. </td>
- </tr>
-
+<td> <tt>PARAM_READ_PATHS</tt> </td>
+<td> Set<String> </td>
+<td> paths to namespace, nodetype and privilege root nodes </td>
+<td> Set of paths that are always readable to all principals irrespective of other permissions defined at that path or inherited from other nodes. </td></tr>
<tr class="b">
-
-<td><tt>PARAM_ADMINISTRATIVE_PRINCIPALS</tt> </td>
-
-<td>String[] </td>
-
-<td>- </td>
-
-<td>The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. </td>
- </tr>
-
+<td> <tt>PARAM_ADMINISTRATIVE_PRINCIPALS</tt> </td>
+<td> String[] </td>
+<td> - </td>
+<td> The names of the additional principals that have full permission and for which the permission evaluation can be skipped altogether. </td></tr>
<tr class="a">
-
<td> </td>
-
<td> </td>
-
<td> </td>
-
-<td> </td>
- </tr>
- </tbody>
+<td> </td></tr>
+</tbody>
</table>
<div class="section">
<h5><a name="Supported_Values_for_PARAM_PERMISSIONS_JR2"></a>Supported Values for PARAM_PERMISSIONS_JR2</h5>
-
<ul>
-
+
<li><tt>REMOVE_NODE</tt>: 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.</li>
-
<li><tt>USER_MANAGEMENT</tt>: if set permissions for user related items will be evaluated the same way as regular JCR items irrespective of their protection status.</li>
</ul></div>
<div class="section">