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 [20/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/permission/differences.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission/differences.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission/differences.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission/differences.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 : Differences wrt Jackrabbit 2.x</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,35 +240,30 @@
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">
<div class="section">
<h3><a name="Permissions_:_Differences_wrt_Jackrabbit_2.x"></a>Permissions : Differences wrt Jackrabbit 2.x</h3>
<div class="section">
<h4><a name="General_Notes"></a>General Notes</h4>
<p>The permission evaluation as present in Oak 1.0 differs from Jackrabbit 2.x in two fundamental aspects:</p>
-
<ol style="list-style-type: decimal">
-
-<li>Permission evaluation has been completely separated from the access control content and is executed based on the information stored in the permission store.</li>
-
-<li>Each JCR <tt>Session</tt> (or Oak <tt>ContentSession</tt>) gets it’s own <tt>PermissionProvider</tt> associated with the current repository revision the session is operating on.</li>
+
+<li>Permission evaluation has been completely separated from the access control content and is executed based on the information stored in the permission store.</li>
+<li>Each JCR <tt>Session</tt> (or Oak <tt>ContentSession</tt>) gets it’s own <tt>PermissionProvider</tt> associated with the current repository revision the session is operating on.</li>
</ol></div>
<div class="section">
<h4><a name="Permissions"></a>Permissions</h4>
<p>The following permissions are now an aggregation of new permissions:</p>
-
<ul>
-
+
<li><tt>READ</tt>: aggregates <tt>READ_NODE</tt> and <tt>READ_PROPERTY</tt></li>
-
<li><tt>SET_PROPERTY</tt>: aggregates <tt>ADD_PROPERTY</tt>, <tt>MODIFY_PROPERTY</tt> and <tt>REMOVE_PROPERTY</tt></li>
</ul>
<p>The following permissions have been introduced with Oak 1.0:</p>
-
<ul>
-
+
<li><tt>USER_MANAGEMENT</tt>: permission to 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>: permission to create, modify and remove the oak:index node and it’s subtree which is expected to contain the index definitions.</li>
</ul></div>
<div class="section">
@@ -298,8 +293,7 @@
<p>Repository level operations such as namespace, nodetype, privilege and workspace management require permissions to be defined at the repository level such as outlined by JSR 283. This implies that access control policies need to be set at the <tt>null</tt> path. In contrast to Jackrabbit 2.x permissions defined at any regular path such as e.g. the root path with be ignored.</p></div></div>
<div class="section">
<h4><a name="Configuration"></a>Configuration</h4>
-<p>The <tt>omit-default-permission</tt> 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.</p>
-<!-- hidden references --></div></div></div>
+<p>The <tt>omit-default-permission</tt> 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.</p><!-- hidden references --></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/permission/evaluation.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission/evaluation.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission/evaluation.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission/evaluation.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 – Permission Evaluation in Detail</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,190 +240,168 @@
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="Permission_Evaluation_in_Detail"></a>Permission Evaluation in Detail</h2>
-<p><a name="permissionentries"></a></p>
+-->
<div class="section">
-<h3><a name="Order_and_Evaluation_of_Permission_Entries"></a>Order and Evaluation of Permission Entries</h3>
+<h2><a name="Permission_Evaluation_in_Detail"></a>Permission Evaluation in Detail</h2>
+<a name="permissionentries"></a>
+### Order and Evaluation of Permission Entries
+
<p>In order to evaluate the permissions for a given item, the <tt>PermissionProvider</tt> lazily builds an iterator of <tt>PermissionsEntry</tt> representing the rep:Permission present in the permission store that take effect for the given set of principals at the given node (or property).</p>
<p>Each <tt>PermissionsEntry</tt> stores the privileges granted/denied together with any restrictions that may be defined with the original access control entry.</p>
<p>This iterator is a concatenation between all entries associated with user principals followed by the entries associated with group principals.</p>
<p>The order of precedence is as follows:</p>
-
<ul>
-
+
<li>permissions are inherited throughout the item hierarchy</li>
-
<li>user principals always take precedence over group principals irrespective of
-
<ul>
-
+
<li>their order in the access control list</li>
-
<li>their position in the node hierarchy</li>
- </ul></li>
-
+</ul>
+</li>
<li>within a given type of principal (user vs. group principal) the order of executing is
-
<ul>
-
+
<li>order of entries as specified originally (the index of the permission entry)</li>
-
<li>entries associated with the target tree take precedence over inherited entries</li>
- </ul></li>
</ul>
+</li>
+</ul>
+<div class="section">
<div class="section">
<div class="section">
<h5><a name="Examples"></a>Examples</h5>
<div class="section">
<h6><a name="Simple_Inheritance"></a>Simple Inheritance</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
+<div>
+<div>
+<pre class="source">/content
allow - everyone - READ permission
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
+
<li>everyone is allowed to read the complete tree defined by /content</li>
</ul></div>
<div class="section">
<h6><a name="Simple_Inheritance_with_Restrictions"></a>Simple Inheritance with Restrictions</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
+<div>
+<div>
+<pre class="source">/content
allow - everyone - READ permission
deny - everyone - READ_PROPERTY permission - restriction rep:itemNames = ['prop1', 'prop2']
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
+
<li>everyone is can read the complete tree defined by /content <i>except</i> for properties named ‘prop1’ or ‘prop2’ which are explicitly denied by the restricting entry.</li>
</ul></div>
<div class="section">
<h6><a name="Inheritance_with_Allow_and_Deny"></a>Inheritance with Allow and Deny</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
+<div>
+<div>
+<pre class="source">/content
deny - everyone - READ permission
/content/public
allow - everyone - READ permission
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
+
<li>everyone cannot read items at the tree defined by /content</li>
-
<li>except for tree defined by /content/public which is accessible.</li>
</ul></div>
<div class="section">
<h6><a name="Inheritance_with_Multiple_Allows"></a>Inheritance with Multiple Allows</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
+<div>
+<div>
+<pre class="source">/content
allow - everyone - READ permission
/content/public
allow - everyone - REMOVE permission
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
+
<li>everyonce can read item at /content and the complete subtree</li>
-
<li>in addition everyone can remove items underneath /content/public</li>
</ul></div>
<div class="section">
<h6><a name="Inheritance_with_Different_Principals"></a>Inheritance with Different Principals</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
+<div>
+<div>
+<pre class="source">/content
allow - everyone - READ permission
allow - authorGroup - REMOVE permission
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
+
<li>a subject being member of everyone is allowed to read at /content and the complete subtree</li>
-
<li>a subject being member of authorGroup is only allowed to remove items at /content</li>
-
-<li>a subject being member of both everyone <i>and</i> authorGroup has full read-access at /content <i>and</i> can also remove items.</li>
+<li>a subject being member of both everyone <i>and</i> authorGroup has full read-access at /content <i>and</i> can also remove items.
+<p>/content allow - everyone - READ permission</p>
+<p>/content/private deny - everyone - READ permission allow - powerfulGroup - ALL permission</p></li>
</ul>
-
-<div class="source">
-<div class="source"><pre class="prettyprint">/content
- allow - everyone - READ permission
-
-/content/private
- deny - everyone - READ permission
- allow - powerfulGroup - ALL permission
-</pre></div></div>
<p>Result:</p>
-
<ul>
-
+
<li>a subject being member of everyone
-
<ul>
-
+
<li>is allowed to read at /content and the complete subtree</li>
-
<li>except for /content/private</li>
- </ul></li>
-
+</ul>
+</li>
<li>a subject being member of powerfulGroup
-
<ul>
-
+
<li>has full permission at /content/private</li>
- </ul></li>
-
+</ul>
+</li>
<li>a subject being member of both everyone <i>and</i> powerfulGroup
-
<ul>
-
+
<li>has full read-access at /content</li>
-
<li>has full permission underneath /content/private</li>
- </ul></li>
+</ul>
+</li>
</ul></div>
<div class="section">
<h6><a name="Interaction_of_User_and_Group_Principals"></a>Interaction of User and Group Principals</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">/home/jackrabbit
+<div>
+<div>
+<pre class="source">/home/jackrabbit
allow - jackrabbit - ALL permission
deny - everyone - ALL permission
</pre></div></div>
-<p>Result:</p>
+<p>Result:</p>
<ul>
-
-<li>a subject containing the ‘jackrabbit’ user principal has full permission at /home/jackrabbit irrespective of the presense of everyone group principal in the subject.</li>
-
-<li>any other subject has not access at /home/jackrabbit</li>
-</ul>
-<div class="source">
-<div class="source"><pre class="prettyprint">/home/jackrabbit
- allow - jackrabbit - ALL permission
-
-/home/jackrabbit/private
- deny - everyone - ALL permission
-</pre></div></div>
+<li>a subject containing the ‘jackrabbit’ user principal has full permission at /home/jackrabbit irrespective of the presense of everyone group principal in the subject.</li>
+<li>any other subject has not access at /home/jackrabbit
+<p>/home/jackrabbit allow - jackrabbit - ALL permission</p>
+<p>/home/jackrabbit/private deny - everyone - ALL permission</p></li>
+</ul>
<p>Result:</p>
-
<ul>
-
+
<li>a subject containing the ‘jackrabbit’ user principal has full permission at the tree defined by /home/jackrabbit irrespective of the presense of everyone group principal in the subject.</li>
-
<li>any other subject is explicitly denied access to /home/jackrabbit/private</li>
</ul></div></div></div></div>
<div class="section">
@@ -433,171 +411,213 @@
<div class="section">
<h5><a name="Reading_a_Node"></a>Reading a Node</h5>
<p>The following section describes what happens on <tt>Session.getNode("/foo").getProperty("jcr:title")</tt> in terms of permission evaluation:</p>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>SessionImpl.getNode()</tt> internally calls <tt>SessionDelegate.getNode()</tt> which calls <tt>Root.getTree()</tt> which calls <tt>Tree.getTree()</tt> on the <tt>/foo</tt> tree. This creates a bunch of linked <tt>MutableTree</tt> objects.</p></li>
-
+
+<p><tt>SessionImpl.getNode()</tt> internally calls <tt>SessionDelegate.getNode()</tt> which calls <tt>Root.getTree()</tt> which calls <tt>Tree.getTree()</tt> on the <tt>/foo</tt> tree. This creates a bunch of linked <tt>MutableTree</tt> objects.</p>
+</li>
<li>
-<p>The session delegate then checks if the tree really exists, by calling <tt>Tree.exists()</tt> which then calls <tt>NodeBuilder.exists()</tt>.</p></li>
-
+
+<p>The session delegate then checks if the tree really exists, by calling <tt>Tree.exists()</tt> which then calls <tt>NodeBuilder.exists()</tt>.</p>
+</li>
<li>
-<p>If the session performing the operation is an <i>admin</i> session, then the node builder from the persistence layer is directly used. In all other cases, the original node builder is wrapped by a <tt>SecureNodeBuilder</tt>. The <tt>SecureNodeBuilder</tt> performs permission checks before delegating the calls to the delegated builder.</p></li>
-
+
+<p>If the session performing the operation is an <i>admin</i> session, then the node builder from the persistence layer is directly used. In all other cases, the original node builder is wrapped by a <tt>SecureNodeBuilder</tt>. The <tt>SecureNodeBuilder</tt> performs permission checks before delegating the calls to the delegated builder.</p>
+</li>
<li>
-<p>For non <i>admin</i> sessions the <tt>SecureNodeBuilder</tt> fetches its <i>tree permissions</i> via <tt>getTreePermission()</tt>.</p></li>
-
+
+<p>For non <i>admin</i> sessions the <tt>SecureNodeBuilder</tt> fetches its <i>tree permissions</i> via <tt>getTreePermission()</tt>.</p>
+</li>
<li>
-<p>The <tt>TreePermission</tt> is responsible for evaluating the permissions granted or denied for a given Oak <tt>Tree</tt> and it’s properties. In order to test if a the tree itself is accessible <tt>TreePermission#canRead()</tt> is called and checks the <tt>READ_NODE</tt> permission for normal trees (as in this example) or the <tt>READ_ACCESS_CONTROL</tt> permission on <i>AC trees</i>. The result is remembered in the <tt>ReadStatus</tt> kept with this <tt>TreePermission</tt> instance.</p></li>
-
+
+<p>The <tt>TreePermission</tt> is responsible for evaluating the permissions granted or denied for a given Oak <tt>Tree</tt> and it’s properties. In order to test if a the tree itself is accessible <tt>TreePermission#canRead()</tt> is called and checks the <tt>READ_NODE</tt> permission for normal trees (as in this example) or the <tt>READ_ACCESS_CONTROL</tt> permission on <i>AC trees</i>. The result is remembered in the <tt>ReadStatus</tt> kept with this <tt>TreePermission</tt> instance.</p>
+</li>
<li>
-<p>The read status is based on the evaluation of the <i>permission entries</i> that are effective for this tree and the set of principals associated with the permission provider. They are retrieved internally by calling <tt>getEntryIterator()</tt>.</p></li>
-
+
+<p>The read status is based on the evaluation of the <i>permission entries</i> that are effective for this tree and the set of principals associated with the permission provider. They are retrieved internally by calling <tt>getEntryIterator()</tt>.</p>
+</li>
<li>
-<p>The <i>permission entries</i> are <a href="#entry_evaluation">analyzed</a> 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 <a href="default.html#permissionStore">permission store</a> and how they are feed into the iterator (see <a href="#permissionentries">Order and Evaluation of Permission Entries</a> above).</p>
-<p>The iteration also detects if the evaluated permission entries cover <i>this</i> node and all its properties. If this is the case, subsequent calls that evaluate the property read permissions would then not need to do the same iteration again. In order to detect this, the iteration checks if a non-matching permission entry or privilege was skipped and eventually sets the respective flag in the <tt>ReadStatus</tt>. This flag indicates if the present permission entries are sufficient to tell if the session is allowed to read <i>this</i> node and all its properties. If there are more entries present than the ones needed for evaluating the <tt>READ_NODE</tt> permission, then it’s ambiguous to determine if all properties can be read.</p></li>
-
+
+<p>The <i>permission entries</i> are <a href="#entry_evaluation">analyzed</a> 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 <a href="default.html#permissionStore">permission store</a> and how they are feed into the iterator (see <a href="#permissionentries">Order and Evaluation of Permission Entries</a> above).</p>
+<p>The iteration also detects if the evaluated permission entries cover <i>this</i> node and all its properties. If this is the case, subsequent calls that evaluate the property read permissions would then not need to do the same iteration again. In order to detect this, the iteration checks if a non-matching permission entry or privilege was skipped and eventually sets the respective flag in the <tt>ReadStatus</tt>. This flag indicates if the present permission entries are sufficient to tell if the session is allowed to read <i>this</i> node and all its properties. If there are more entries present than the ones needed for evaluating the <tt>READ_NODE</tt> permission, then it’s ambiguous to determine if all properties can be read.</p>
+</li>
<li>
-<p>Once the <tt>ReadStatus</tt> is calculated (or was calculated earlier) the <tt>canRead()</tt> method returns <tt>ReadStatus.allowsThis()</tt> which specifies if <i>this</i> node is allowed to be read.</p></li>
+
+<p>Once the <tt>ReadStatus</tt> is calculated (or was calculated earlier) the <tt>canRead()</tt> method returns <tt>ReadStatus.allowsThis()</tt> which specifies if <i>this</i> node is allowed to be read.</p>
+</li>
</ol></div>
<div class="section">
<h5><a name="Reading_a_Property"></a>Reading a Property</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>Node.getProperty()</tt> internally calls <tt>NodeDelegate.getPropertyOrNull()</tt> which first resolves the parent node as indicated by the relative path without testing for it’s existence. Then a new <tt>PropertyDelegate</tt> is created from the parent node and the name of the property, which internal obtains the <tt>PropertyState</tt> from the Oak <tt>Tree</tt>, which may return <tt>null</tt>.</p></li>
-
+
+<p><tt>Node.getProperty()</tt> internally calls <tt>NodeDelegate.getPropertyOrNull()</tt> which first resolves the parent node as indicated by the relative path without testing for it’s existence. Then a new <tt>PropertyDelegate</tt> is created from the parent node and the name of the property, which internal obtains the <tt>PropertyState</tt> from the Oak <tt>Tree</tt>, which may return <tt>null</tt>.</p>
+</li>
<li>
-<p>The node delegate then checks if the property really exists (or is accessible to the reading session by calling <tt>PropertyDelegate.exists()</tt> asserting if the underlying <tt>PropertyState</tt> is not <tt>null</tt>.</p></li>
-
+
+<p>The node delegate then checks if the property really exists (or is accessible to the reading session by calling <tt>PropertyDelegate.exists()</tt> asserting if the underlying <tt>PropertyState</tt> is not <tt>null</tt>.</p>
+</li>
<li>
-<p>If the session performing the operation is an <i>admin</i> session, then the property state from the persistence layer is directly used. In all other cases, the original node builder is wrapped by a <tt>SecureNodeBuilder</tt>. The <tt>SecureNodeBuilder</tt> performs permission checks before delegating the calls to the delegated builder.</p></li>
-
+
+<p>If the session performing the operation is an <i>admin</i> session, then the property state from the persistence layer is directly used. In all other cases, the original node builder is wrapped by a <tt>SecureNodeBuilder</tt>. The <tt>SecureNodeBuilder</tt> performs permission checks before delegating the calls to the delegated builder.</p>
+</li>
<li>
-<p>For non <i>admin</i> sessions the <tt>SecureNodeBuilder</tt> fetches its <i>tree permissions</i> via <tt>getTreePermission()</tt>.</p></li>
-
+
+<p>For non <i>admin</i> sessions the <tt>SecureNodeBuilder</tt> fetches its <i>tree permissions</i> via <tt>getTreePermission()</tt>.</p>
+</li>
<li>
-<p>The <tt>TreePermission</tt> is responsible for evaluating the permissions granted or denied for a given Oak <tt>Tree</tt> and it’s properties. In order to test if the property is accessible <tt>TreePermission#canRead(PropertyState)</tt> is called and checks the <tt>READ_PROPERTY</tt> permission for regular properties or the <tt>READ_ACCESS_CONTROL</tt> 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 <tt>ReadStatus</tt> kept with this <tt>TreePermission</tt> instance; otherwise the <i>permission entries</i> are collected and evaluated as described <a href="#permissionentries">above</a>.</p></li>
+
+<p>The <tt>TreePermission</tt> is responsible for evaluating the permissions granted or denied for a given Oak <tt>Tree</tt> and it’s properties. In order to test if the property is accessible <tt>TreePermission#canRead(PropertyState)</tt> is called and checks the <tt>READ_PROPERTY</tt> permission for regular properties or the <tt>READ_ACCESS_CONTROL</tt> 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 <tt>ReadStatus</tt> kept with this <tt>TreePermission</tt> instance; otherwise the <i>permission entries</i> are collected and evaluated as described <a href="#permissionentries">above</a>.</p>
+</li>
</ol></div></div>
<div class="section">
<h4><a name="Session_Write-Operations"></a>Session Write-Operations</h4>
<div class="section">
<h5><a name="Adding_a_Node"></a>Adding a Node</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>Node.addNode(String)</tt> will internally call <tt>NodeDelegate.addChild</tt> which in term, adds a new child to the corresponding Oak <tt>Tree</tt> and generate all autocreated child items.</p></li>
-
+
+<p><tt>Node.addNode(String)</tt> will internally call <tt>NodeDelegate.addChild</tt> which in term, adds a new child to the corresponding Oak <tt>Tree</tt> and generate all autocreated child items.</p>
+</li>
<li>
-<p>Once <tt>Session.save()</tt> is called all pending changes will be merged into the <tt>NodeStore</tt> present with the editing Oak <tt>Root</tt>. This is achieved by calling <tt>Root#commit</tt>.</p></li>
-
+
+<p>Once <tt>Session.save()</tt> is called all pending changes will be merged into the <tt>NodeStore</tt> present with the editing Oak <tt>Root</tt>. This is achieved by calling <tt>Root#commit</tt>.</p>
+</li>
<li>
-<p>The permission evaluation is triggered by means of a specific <tt>Validator</tt> implementation that is passed over to the merge along with the complete set of validators and editors that are combined into a single <tt>CommitHook</tt>.</p></li>
-
+
+<p>The permission evaluation is triggered by means of a specific <tt>Validator</tt> implementation that is passed over to the merge along with the complete set of validators and editors that are combined into a single <tt>CommitHook</tt>.</p>
+</li>
<li>
-<p>The <tt>PermissionValidator</tt> will be notified about the new node being added.</p></li>
-
+
+<p>The <tt>PermissionValidator</tt> will be notified about the new node being added.</p>
+</li>
<li>
-<p>It again obtains the <tt>TreePermission</tt> object form the <tt>PermissionProvider</tt> and evaluates if <tt>ADD_NODE</tt> permission is being granted for the new target node. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p></li>
-
+
+<p>It again obtains the <tt>TreePermission</tt> object form the <tt>PermissionProvider</tt> and evaluates if <tt>ADD_NODE</tt> permission is being granted for the new target node. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p>
+</li>
<li>
-<p>If added the new node is granted the validation continues otherwise the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p></li>
+
+<p>If added the new node is granted the validation continues otherwise the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p>
+</li>
</ol></div>
<div class="section">
<h5><a name="Changing_a_Property"></a>Changing a Property</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>Property.setValue</tt> will internally call <tt>PropertyDelegate.setState</tt> with an new <tt>PropertyState</tt> created from the new value (or the new set of values).</p></li>
-
+
+<p><tt>Property.setValue</tt> will internally call <tt>PropertyDelegate.setState</tt> with an new <tt>PropertyState</tt> created from the new value (or the new set of values).</p>
+</li>
<li>
-<p>Once <tt>Session.save()</tt> is called all pending changes will be merged into the <tt>NodeStore</tt> present with the editing Oak <tt>Root</tt>. This is achieved by calling <tt>Root#commit</tt>.</p></li>
-
+
+<p>Once <tt>Session.save()</tt> is called all pending changes will be merged into the <tt>NodeStore</tt> present with the editing Oak <tt>Root</tt>. This is achieved by calling <tt>Root#commit</tt>.</p>
+</li>
<li>
-<p>The permission evaluation is triggered by means of a specific <tt>Validator</tt> implementation that is passed over to the merge along with the complete set of validators and editors that are combined into a single <tt>CommitHook</tt>.</p></li>
-
+
+<p>The permission evaluation is triggered by means of a specific <tt>Validator</tt> implementation that is passed over to the merge along with the complete set of validators and editors that are combined into a single <tt>CommitHook</tt>.</p>
+</li>
<li>
-<p>The <tt>PermissionValidator</tt> will be notified about the modified property.</p></li>
-
+
+<p>The <tt>PermissionValidator</tt> will be notified about the modified property.</p>
+</li>
<li>
-<p>It again obtains the <tt>TreePermission</tt> object form the <tt>PermissionProvider</tt> and evaluates if <tt>MODIFY_PROPERTY</tt> permission is being granted. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p></li>
-
+
+<p>It again obtains the <tt>TreePermission</tt> object form the <tt>PermissionProvider</tt> and evaluates if <tt>MODIFY_PROPERTY</tt> permission is being granted. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p>
+</li>
<li>
-<p>If changing this property is allowed the validation continues otherwise the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p></li>
+
+<p>If changing this property is allowed the validation continues otherwise the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p>
+</li>
</ol></div></div>
<div class="section">
<h4><a name="Workspace_Operations"></a>Workspace Operations</h4>
<div class="section">
<h5><a name="Copying_Nodes"></a>Copying Nodes</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>Workspac.copy</tt> will internally call <tt>WorkspaceDelegate.copy</tt>.</p></li>
-
+
+<p><tt>Workspac.copy</tt> will internally call <tt>WorkspaceDelegate.copy</tt>.</p>
+</li>
<li>
-<p>After some preliminary validation the delegate will create a new <tt>WorkspaceCopy</tt> and call it’s <tt>perform</tt> method passing in the separate <tt>Root</tt> instance obtained from <tt>ContentSession.getLatestRoot()</tt>; in other words the modifications made by the copy operation will not show up as transient changes on the editing session.</p></li>
-
+
+<p>After some preliminary validation the delegate will create a new <tt>WorkspaceCopy</tt> and call it’s <tt>perform</tt> method passing in the separate <tt>Root</tt> instance obtained from <tt>ContentSession.getLatestRoot()</tt>; in other words the modifications made by the copy operation will not show up as transient changes on the editing session.</p>
+</li>
<li>
-<p>Upon completion of the copy operation <tt>Root.commit</tt> is called on that latest root instance and the delegated will refresh the editing session to reflect the changes made by the copy.</p></li>
-
+
+<p>Upon completion of the copy operation <tt>Root.commit</tt> is called on that latest root instance and the delegated will refresh the editing session to reflect the changes made by the copy.</p>
+</li>
<li>
-<p>The permission evaluation is triggered upon committing the changes associated with the copy by the same <tt>Validator</tt> that handles transient operations.</p></li>
-
+
+<p>The permission evaluation is triggered upon committing the changes associated with the copy by the same <tt>Validator</tt> that handles transient operations.</p>
+</li>
<li>
-<p>The <tt>PermissionValidator</tt> will be notified about the new items created by the copy and checks the corresponding permissions with the <tt>TreePermission</tt> associated with the individual new nodes. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p></li>
-
+
+<p>The <tt>PermissionValidator</tt> will be notified about the new items created by the copy and checks the corresponding permissions with the <tt>TreePermission</tt> associated with the individual new nodes. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p>
+</li>
<li>
-<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p></li>
+
+<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p>
+</li>
</ol></div>
<div class="section">
<h5><a name="Locking_a_Node"></a>Locking a Node</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>LockManager.lock</tt> will internally call <tt>NodeDelegate.lock</tt>, which will obtain a new <tt>Root</tt> from the editing <tt>ContentSession</tt> and perform the required changes on that dedicated root such that the editing session is not affected.</p></li>
-
+
+<p><tt>LockManager.lock</tt> will internally call <tt>NodeDelegate.lock</tt>, which will obtain a new <tt>Root</tt> from the editing <tt>ContentSession</tt> and perform the required changes on that dedicated root such that the editing session is not affected.</p>
+</li>
<li>
-<p>Once the lock operation is complete the delegate will call <tt>Root.commit</tt> on the latest root instance in order to persist the changes. Finally the lock manager will refresh the editing session to reflect the changes made.</p></li>
-
+
+<p>Once the lock operation is complete the delegate will call <tt>Root.commit</tt> on the latest root instance in order to persist the changes. Finally the lock manager will refresh the editing session to reflect the changes made.</p>
+</li>
<li>
-<p>The permission evaluation is triggered upon committing the changes associated with the lock operation by the same <tt>Validator</tt> that handles transient operations.</p></li>
-
+
+<p>The permission evaluation is triggered upon committing the changes associated with the lock operation by the same <tt>Validator</tt> that handles transient operations.</p>
+</li>
<li>
-<p>The <tt>PermissionValidator</tt> will be notified about the new items created by the lock and identify that they are associated with a lock specific operations. Consequently it will checks for <tt>LOCK_MANAGEMENT</tt> permissions being granted at the affected tree. The evaluation triggered by calling <tt>TreePermission.isGranted</tt> and follows the same principals as described <a href="#permissionentries">above</a>.</p></li>
-
+
+<p>The <tt>PermissionValidator</tt> will be notified about the new items created by the lock and identify that they are associated with a lock specific operations. Consequently it will checks for <tt>LOCK_MANAGEMENT</tt> permissions being granted at the affected tree. The evaluation triggered by calling <tt>TreePermission.isGranted</tt> and follows the same principals as described <a href="#permissionentries">above</a>.</p>
+</li>
<li>
-<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p></li>
+
+<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p>
+</li>
</ol></div></div>
<div class="section">
<h4><a name="Repository_Operations"></a>Repository Operations</h4>
<div class="section">
<h5><a name="Registering_a_Privilege"></a>Registering a Privilege</h5>
-
<ol style="list-style-type: decimal">
-
+
<li>
-<p><tt>PrivilegeManager.registerPrivilege</tt> will obtain a new <tt>Root</tt> from the editing <tt>ContentSession</tt> and pass it to a new <tt>PrivilegeDefinitionWriter</tt> that is in charge of writing the repository content associated with a new privilege definition. Finally the writer will persist the changes by calling <tt>Root.commit</tt>.</p></li>
-
+
+<p><tt>PrivilegeManager.registerPrivilege</tt> will obtain a new <tt>Root</tt> from the editing <tt>ContentSession</tt> and pass it to a new <tt>PrivilegeDefinitionWriter</tt> that is in charge of writing the repository content associated with a new privilege definition. Finally the writer will persist the changes by calling <tt>Root.commit</tt>.</p>
+</li>
<li>
-<p>Validation of the new privilege definition if delegated to a dedicated <tt>PrivilegeValidator</tt>.</p></li>
-
+
+<p>Validation of the new privilege definition if delegated to a dedicated <tt>PrivilegeValidator</tt>.</p>
+</li>
<li>
-<p>The permission evaluation is triggered upon committing the changes associated by the same <tt>Validator</tt> that handles transient operations.</p></li>
-
+
+<p>The permission evaluation is triggered upon committing the changes associated by the same <tt>Validator</tt> that handles transient operations.</p>
+</li>
<li>
-<p>The <tt>PermissionValidator</tt> will be notified about changes being made to the dedicated tree storing privilege information and will specifically verify that <tt>PRIVILEGE_MANAGEMENT</tt> permissions being granted at the repository level. This is achieved by obtaining the <tt>RepositoryPermission</tt> object from the <tt>PermissionProvider</tt> and calling <tt>RepositoryPermission.isGranted</tt>. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p></li>
-
+
+<p>The <tt>PermissionValidator</tt> will be notified about changes being made to the dedicated tree storing privilege information and will specifically verify that <tt>PRIVILEGE_MANAGEMENT</tt> permissions being granted at the repository level. This is achieved by obtaining the <tt>RepositoryPermission</tt> object from the <tt>PermissionProvider</tt> and calling <tt>RepositoryPermission.isGranted</tt>. The evaluation follows the same principals as described <a href="#permissionentries">above</a>.</p>
+</li>
<li>
-<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p></li>
-
+
+<p>If a permission violation is detected the <tt>commit</tt> will fail immediately with an <tt>CommitFailedException</tt> of type <tt>ACCESS</tt>.</p>
+</li>
<li>
-<p>Once the registration is successfully completed the manager will refresh the editing session.</p></li>
+
+<p>Once the registration is successfully completed the manager will refresh the editing session.</p>
+</li>
</ol></div></div></div></div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/permission/multiplexing.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission/multiplexing.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission/multiplexing.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission/multiplexing.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 – Multiplexing support in the PermissionStore</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,7 +240,8 @@
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="Multiplexing_support_in_the_PermissionStore"></a>Multiplexing support in the PermissionStore</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
@@ -249,17 +250,20 @@
<h3><a name="PermissionStore_Evaluation_reading"></a>PermissionStore Evaluation (reading)</h3>
<p>Given the following mount setup</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">private
+<div>
+<div>
+<pre class="source">private
- /libs
- /apps
default
- /
</pre></div></div>
+
<p>In above setup nodes under /apps and /libs (include apps and libs) are part of “private” mount (mount name is “private”) and all other paths are part of default mount. A dedicated PermissionStore will be created under <tt>oak:mount-private-default</tt> that contains information relevant to this specific mount.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">/jcr:system/rep:permissionStore
+<div>
+<div>
+<pre class="source">/jcr:system/rep:permissionStore
+ oak:mount-private-default
+ editor //principal name
+ 1345610890 (rep:PermissionStore) //path hash
@@ -274,7 +278,8 @@ default
+ 0
- rep:isAllow = true
- rep:privileges = [1279]
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h3><a name="PermissionStore_updates_writing"></a>PermissionStore updates (writing)</h3>
<p>The <tt>PermissionHook</tt> is now mount-aware and will delegate changes to specific path to their designated components based on path.</p></div></div>
Modified: jackrabbit/site/live/oak/docs/security/permission/permissionsandprivileges.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/permission/permissionsandprivileges.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/permission/permissionsandprivileges.html (original)
+++ jackrabbit/site/live/oak/docs/security/permission/permissionsandprivileges.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 vs Privileges</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,102 +240,81 @@
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_vs_Privileges"></a>Permissions vs Privileges</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
<p>Usually it is not required for a application to check the privileges/permissions of a given session (or set of principals) as this evaluation can be left to the repository.</p>
<p>For rare cases where the application needs to understand if a given session is actually allowed to perform a given action, it is recommend to use <tt>Session.hasPermission(String, String)</tt> or <tt>JackrabbitSession.hasPermission(String, String...)</tt></p>
-<p>In order to test permissions that are not reflected in the action constants defined on <tt>Session</tt> or <tt>JackrabbitSession</tt>, the default implementation also allows to pass the names of the Oak internal permission. </p>
+<p>In order to test permissions that are not reflected in the action constants defined on <tt>Session</tt> or <tt>JackrabbitSession</tt>, the default implementation also allows to pass the names of the Oak internal permission.</p>
<p>Alternatively, <tt>AccessControlManager.hasPrivileges(String, Privilege[])</tt> can be used.</p>
-<p>The subtle differences between the permission-testing <tt>Session</tt> and the evaluation of privileges on <tt>AccessControlManager</tt> are listed below.</p></div>
+<p>The subtle differences between the permission-testing <tt>Session</tt> and the evaluation of privileges on <tt>AccessControlManager</tt> are listed below.</p></div>
<div class="section">
<h3><a name="Testing_Permissions"></a>Testing Permissions</h3>
<div class="section">
<h4><a name="Variants"></a>Variants</h4>
-
<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></li>
</ul>
<p>Where</p>
-
<ul>
-
+
<li><tt>absPath</tt> is an absolute path pointing to an existing or non-existing item (node or property)</li>
-
-<li><tt>actions</tt> defines a comma-separated string (or string array respectively) of the actions defined on <tt>Session</tt> and <tt>JackrabbitSession</tt> (see below). With the default implementation also Oak internal permission names are allowed ( <i>Note:</i> permission names != privilege names)</li>
+<li><tt>actions</tt> defines a comma-separated string (or string array respectively) of the actions defined on <tt>Session</tt> and <tt>JackrabbitSession</tt> (see below). With the default implementation also Oak internal permission names are allowed ( <i>Note:</i> permission names != privilege names)</li>
</ul>
<p>See section <a href="../permission.html#oak_permissions">Permissions</a> for a comprehensive list and the mapping from actions to permissions.</p></div>
<div class="section">
<h4><a name="Characteristics"></a>Characteristics</h4>
-
<ul>
-
+
<li>API call always supported even if access control management is not part of the feature set (see corresponding repository descriptor).</li>
-
<li><i>Note:</i> <tt>ACTION_ADD_NODE</tt> is evaluating if the node at the specified absPath can be added; i.e. the path points to the non-existing node you want to add</li>
-
<li>Not possible to evaluate custom privileges with this method as those are not respected by the default permission evaluation.</li>
-
<li>Restrictions will be respected as possible with the given (limited) information</li>
</ul></div></div>
<div class="section">
<h3><a name="Testing_Privileges"></a>Testing Privileges</h3>
<div class="section">
<h4><a name="Variants"></a>Variants</h4>
-
<ul>
-
+
<li><tt>AccessControlManager.hasPrivileges(String absPath, Privilege[] privileges)</tt></li>
-
<li><tt>AccessControlManager.getPrivileges(String absPath)</tt></li>
</ul>
<p>Where</p>
-
<ul>
-
+
<li><tt>absPath</tt> must point to an existing Node (i.e. existing and accessible to the editing session)</li>
-
<li><tt>privileges</tt> represent an array of supported privileges (see corresponding API calls)</li>
</ul>
<p>For testing purpose the Jackrabbit extension further allows to verify the privileges granted to a given combination of principals, which may or may not reflect the actual principal-set assigned to a given <tt>Subject</tt>. These calls (see below) however requires the ability to read access control content on the target path.</p>
-
<ul>
-
+
<li><tt>JackrabbitAccessControlManager.hasPrivileges(String absPath, Set<Principal> principals, Privilege[] privileges)</tt></li>
-
<li><tt>JackrabbitAccessControlManager.getPrivileges(String absPath, Set<Principal> principals)</tt></li>
</ul></div>
<div class="section">
<h4><a name="Characteristics"></a>Characteristics</h4>
-
<ul>
-
+
<li>Only available if access control management is part of the supported feature set of the JCR repository.</li>
-
<li>Built-in and/or custom privileges can be tested</li>
-
<li><tt>jcr:addChildNode</tt> evaluates if any child can be added at the parent node identify by the specified absPath. The name of child is not known here!</li>
-
<li>Restrictions may or may not be respected</li>
-
<li>Default implementation close to real permission evaluation (not exactly following the specification)</li>
</ul>
-<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="../privilege/mappingtoitems.html">Mapping Privileges to Items</a></li>
-
<li><a href="../privilege/mappingtoprivileges.html">Mapping API Calls to Privileges</a></li>
-</ul></div></div>
+</ul></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/principal.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/principal.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/principal.html (original)
+++ jackrabbit/site/live/oak/docs/security/principal.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 – Principal 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,92 +240,81 @@
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="Principal_Management"></a>Principal Management</h2>
-<p><a href="jcr_api"></a></p>
+-->
<div class="section">
-<h3><a name="JCR_API"></a>JCR API</h3>
+<h2><a name="Principal_Management"></a>Principal Management</h2>
+<a href="jcr_api"></a>
+### JCR API
+
<p>JCR itself doesn’t come with a dedicated principal management API. Nevertheless the specification mentions <tt>java.security.Principal</tt> as key feature for access control management but leaves the discovery of principals to the implementation (see <a class="externalLink" href="http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html#16.5.7%20Principal%20Discovery">Section 16.5.7</a>).</p>
<p>Therefore an API for principal management has been defined as part of the extensions present with Jackrabbit API.</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 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:</p>
+<a name="jackrabbit_api"></a>
+### Jackrabbit API
+<p>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:</p>
<ul>
-
+
<li><tt>PrincipalManager</tt></li>
-
<li><tt>PrincipalIterator</tt></li>
-
<li><tt>JackrabbitPrincipal</tt> extends <a class="externalLink" href="http://docs.oracle.com/javase/7/docs/api/java/security/Principal.html">Principal</a>
-
<ul>
-
+
<li><tt>ItemBasedPrincipal</tt></li>
- </ul></li>
</ul>
+</li>
+</ul>
+<div class="section">
<div class="section">
<h4><a name="Differences_wrt_Jackrabbit_2.x"></a>Differences wrt Jackrabbit 2.x</h4>
<p>See the corresponding <a href="principal/differences.html">documentation</a>.</p>
-<p><a name="api_extensions"></a></p></div></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
+<a name="api_extensions"></a>
+### API Extensions
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalProvider.html">PrincipalProvider</a>: SPI level access to principals known to the repository which is also used by the default implementation of the <tt>PrincipalManager</tt> interface. This interface replaces the internal <tt>PrincipalProvider</tt> interface present in Jackrabbit 2.x. Note, that principals from different sources can be supported by using <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.html">CompositePrincipalProvider</a> or a similar implementation that proxies different sources.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.html">CompositePrincipalProvider</a>: Implementation that combines different principals from different source providers.</li>
</ul>
<div class="section">
-<div class="section">
<h5><a name="Special_Principals"></a>Special Principals</h5>
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/AdminPrincipal.html">AdminPrincipal</a>: Marker interface to identify the principal associated with administrative user(s).</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.html">EveryonePrincipal</a>: built-in group principal implementation that has every other valid principal as member.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/SystemPrincipal.html">SystemPrincipal</a>: built-in principal implementation to mark system internal subjects.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/SystemUserPrincipal.html">SystemUserPrincipal</a>: Marker interface to identify principals associated with special system users.</li>
</ul>
-<p><a href="default_implementation"></a></p></div></div></div>
-<div class="section">
-<h3><a name="Oak_Principal_Management_Implementation"></a>Oak Principal Management Implementation</h3>
-<p>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.</p>
+<a href="default_implementation"></a>
+### Oak Principal Management Implementation
+
+<p>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.</p></div></div>
<div class="section">
<h4><a name="PrincipalProvider_Implementations"></a>PrincipalProvider Implementations</h4>
<p>See section <a href="principal/principalprovider.html">Implementations of the PrincipalProvider Interface</a> for details.</p>
-<p><a name="configuration"></a></p></div></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
+<a name="configuration"></a>
+### Configuration
+
<p>The <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalConfiguration.html">PrincipalConfiguration</a> is the Oak level entry point to obtain a new <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/principal/PrincipalManager.java">PrincipalManager</a> or <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/PrincipalProvider.html">PrincipalProvider</a> as well as principal related configuration options. The default implementation of the <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/principal/PrincipalManager.java">PrincipalManager</a> interface is based on Oak API and can equally be used for privilege related tasks in the Oak layer.</p>
<p>In contrast to Jackrabbit 2.x the system may only have one single principal provider implementation configured. In order to combine principals from different sources a implementation that properly handles the different sources is required; the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.html">CompositePrincipalProvider</a> is an example that combines multiple implementations.</p>
-<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>PrincipalConfiguration</tt> implementations and will automatically combine the different principal provider implementations as noted above.</p>
<p>In an OSGi setup the following steps are required in order to add a custom principal provider implementation:</p>
-
<ul>
-
+
<li>implement <tt>PrincipalProvider</tt> interface</li>
-
<li>create the <tt>PrincipalConfiguration</tt> that exposes the custom provider</li>
-
<li>make the configuration implementation an OSGi service and make it available to the Oak repository.</li>
</ul>
<div class="section">
-<div class="section">
<h5><a name="Examples"></a>Examples</h5>
<div class="section">
<h6><a name="Custom_PrincipalConfiguration"></a>Custom PrincipalConfiguration</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint"> @Component()
+<div>
+<div>
+<pre class="source"> @Component()
@Service({PrincipalConfiguration.class, SecurityConfiguration.class})
public class MyPrincipalConfiguration extends ConfigurationBase implements PrincipalConfiguration {
@@ -364,12 +353,14 @@
return NAME;
}
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Custom_PrincipalProvider"></a>Custom PrincipalProvider</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint"> final class MyPrincipalProvider implements PrincipalProvider {
+<div>
+<div>
+<pre class="source"> final class MyPrincipalProvider implements PrincipalProvider {
MyPrincipalProvider(Root root, NamePathMapper namePathMapper) {
...
@@ -378,22 +369,19 @@
...
}
</pre></div></div>
-<p><a name="further_reading"></a></p></div></div></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="principal/differences.html">Differences wrt Jackrabbit 2.x</a></li>
-
<li><a href="principal/principalprovider.html">Implementations of the PrincipalProvider Interface</a>
-
<ul>
-
+
<li><a href="principal/cache.html">Caching Results of Principal Resolution</a></li>
- </ul></li>
</ul>
-<!-- references --></div></div>
+</li>
+</ul><!-- references --></div></div></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/principal/cache.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/principal/cache.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/principal/cache.html (original)
+++ jackrabbit/site/live/oak/docs/security/principal/cache.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 – Caching Results of Principal Resolution</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,7 +240,8 @@
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="Caching_Results_of_Principal_Resolution"></a>Caching Results of Principal Resolution</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
@@ -250,10 +251,9 @@
<h3><a name="Configuration"></a>Configuration</h3>
<p>An administrator may enable the group principal caching via the <i>org.apache.jackrabbit.oak.security.user.UserConfigurationImpl</i> OSGi configuration. By default caching is disabled.</p>
<p>The following configuration option is supported:</p>
-
<ul>
-
-<li>Cache Expiration (<tt>cacheExpiration</tt>): Specifying a long greater 0 enables the caching.</li>
+
+<li>Cache Expiration (<tt>cacheExpiration</tt>): Specifying a long greater 0 enables the caching.</li>
</ul>
<p>NOTE: It is important that the configured expiration time balances between login performance and cache invalidation to reflect changes made to the group membership. An application that makes use of this cache, must be able to live with shot term diverging of principal resolution and user management upon repository login.</p>
<p>It is expected that the cache is used in scenarios where subsequent repository login calls can (or even should) result in the creation of a <tt>javax.security.auth.Subject</tt> with equal principal set irrespective of group membership changes. See section Invalidation below for further details.</p></div>
@@ -262,46 +262,35 @@
<div class="section">
<h4><a name="Caching_Principal_Names"></a>Caching Principal Names</h4>
<p>If the feature is enabled, evaluating <tt>UserPrincipalProvider.getPrincipals(String userId)</tt> and <tt>PrincipalProvider.getGroupMembership(Principal)</tt> as well as the corresponding calls on <tt>PrincipalManager</tt> will trigger the group principal names to be remembered in a cache if the following conditions are met:</p>
-
<ul>
-
+
<li>a valid expiration time is configured (i.e. > 0),</li>
-
<li>the <tt>PrincipalProvider</tt> has been obtained for a system session (see below),</li>
-
-<li>the tree to hold the cache belongs to a user (i.e. tree with primary type <tt>rep:User</tt> (i.e. no caches are created for groups)</li>
+<li>the tree to hold the cache belongs to a user (i.e. tree with primary type <tt>rep:User</tt> (i.e. no caches are created for groups)</li>
</ul>
<p>The cache itself consists of a tree named <tt>rep:cache</tt> with the built-in node type <tt>rep:Cache</tt>, which defines a mandatory, protected <tt>rep:expiration</tt> property and may have additional protected, residual properties.</p>
<p>Subsequent calls will read the names of the group principals from the cache until the cache expires. Once expired the default resolution will be performed again in order to update the cache.</p>
<div class="section">
<h5><a name="Limitation_to_System_Calls"></a>Limitation to System Calls</h5>
<p>The creation and maintenance of this caches as well as the shortcut upon reading is limited to system internal sessions for security reasons: The cache must always be filled with the comprehensive list of group principals (as required upon login) as must any subsequent call never expose principal information that might not be accessible in the non-cache scenario where access to principals is protected by regular permission evalution.</p>
-<p><a name="validation"></a></p></div>
-<div class="section">
-<h5><a name="Validation"></a>Validation</h5>
+<a name="validation"></a>
+##### Validation
+
<p>The cache is system maintained, protected repository content that can only be created and updated by the implementation. Any attempt to manipulate these caches using JCR or Oak API calls will fail. Also the cache can only be created or updated using the internal system subject.</p>
<p>Also this validation is always enforce irrespective on whether the caching feature is enabled or not, to prevent unintended manipulation.</p>
<p>These constraints and the consistency of the cache structure is asserted by a dedicated <tt>CacheValidator</tt>. The corresponding errors are all of type <tt>Constraint</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>0034 </td>
-
-<td>Attempt to create or change the system maintained cache. </td>
- </tr>
- </tbody>
+<td> 0034 </td>
+<td> Attempt to create or change the system maintained cache. </td></tr>
+</tbody>
</table>
<p>Note however, that the cache tree might be removed by any session that has sufficient privileges to remove it.</p></div>
<div class="section">
Modified: jackrabbit/site/live/oak/docs/security/principal/differences.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/principal/differences.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/principal/differences.html (original)
+++ jackrabbit/site/live/oak/docs/security/principal/differences.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 – Principal Management : Differences wrt Jackrabbit 2.x</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,28 +240,24 @@
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">
<div class="section">
<h3><a name="Principal_Management_:_Differences_wrt_Jackrabbit_2.x"></a>Principal Management : Differences wrt Jackrabbit 2.x</h3>
<div class="section">
<h4><a name="Replacement_for_Jackrabbit_Internals"></a>Replacement for Jackrabbit Internals</h4>
<p>As of Oak 1.0 the following interfaces and class that were internal to Jackrabbit have been made part of public API exposed by Oak:</p>
-
<ul>
-
+
<li><a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/principal/PrincipalManager.java">org.apache.jackrabbit.oak.spi.security.principal.PrincipalProvider</a>: corresponds to o.a.j.core.security.principal.PrincipalProvider</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/AdminPrincipal.html">org.apache.jackrabbit.oak.spi.security.principal.AdminPrincipal</a>: corresponds to o.a.j.core.security.principal.AdminPrincipal</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/EveryonePrincipal.html">org.apache.jackrabbit.oak.spi.security.principal.EveryonePrincipal</a>: corresponds to o.a.j.core.security.principal.EveryonePrincipal</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/SystemPrincipal.html">org.apache.jackrabbit.oak.spi.security.principal.SystemPrincipal</a>: corresponds to o.a.j.core.security.SystemPrincipal</li>
</ul></div>
<div class="section">
<h4><a name="Combining_Principals_from_Different_Sources"></a>Combining Principals from Different Sources</h4>
<p>In contrast to Jackrabbit 2.x Oak only deals with a single <tt>PrincipalProvider</tt>. In order to combine principals from different sources a implementation that properly handles the different sources is required; the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/principal/CompositePrincipalProvider.html">CompositePrincipalProvider</a> is an example that combines multiple implementations.</p>
-<p>See section <a href="../principal.html#pluggability">Pluggability</a> for an example.</p>
-<!-- references --></div></div></div>
+<p>See section <a href="../principal.html#pluggability">Pluggability</a> for an example.</p><!-- references --></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/principal/principalprovider.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/principal/principalprovider.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/principal/principalprovider.html (original)
+++ jackrabbit/site/live/oak/docs/security/principal/principalprovider.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 – Implementations of the PrincipalProvider Interface</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,7 +240,8 @@
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="Implementations_of_the_PrincipalProvider_Interface"></a>Implementations of the PrincipalProvider Interface</h2>
<p>Oak contains by default the following implementations of the <tt>PrincipalProvider</tt> interface:</p>
<div class="section">
@@ -262,8 +263,7 @@
<p>Implementation of the <tt>PrincipalProvider</tt> interface that exposes <i>external</i> principals of type <tt>java.security.acl.Group</tt>. <i>External</i> refers to the fact that these principals are defined and managed by an external identity provider in contrast to the default implementation that represents principals native to the repository. This implies that the principals known and exposed by this provider implementation does not expect principals to be backed by an authorizable group. As such they can only be retrieved using Jackrabbit Principal Management API but not with User Management calls.</p>
<p>For performance reasons the <tt>ExternalGroupPrincipalProvider</tt> doesn’t lookup principals on the IDP but relies data persisted inside the repository where the names of these external principals are synchronized based on a configurable expiration time.</p>
<p>See section <a href="../authentication/external/defaultusersync.html">User and Group Synchronization : The Default Implementation</a> for additional details.</p>
-<p>Since Oak 1.5.3</p>
-<!-- references --></div></div>
+<p>Since Oak 1.5.3</p><!-- references --></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/privilege.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/privilege.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/privilege.html (original)
+++ jackrabbit/site/live/oak/docs/security/privilege.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 – Privilege 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,129 +240,119 @@
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="Privilege_Management"></a>Privilege Management</h2>
-<p><a name="jcr_api"></a></p>
+-->
<div class="section">
-<h3><a name="JCR_API"></a>JCR API</h3>
-<p>As of JSR 283 the API contains the following privilege related interfaces and methods:</p>
+<h2><a name="Privilege_Management"></a>Privilege Management</h2>
+<a name="jcr_api"></a>
+### JCR API
+<p>As of JSR 283 the API contains the following privilege related interfaces and methods:</p>
<ul>
-
+
<li><tt>Privilege</tt>: exposes the name and characteristics of a given privilege and provides constants for privilege names defined by JCR.</li>
-
<li><tt>AccessControlManager.getSupportedPrivileges(String)</tt> (see also <tt>PrivilegeManager.getRegisteredPrivileges()</tt>)</li>
-
<li><tt>AccessControlManager.privilegeFromName(String)</tt> equivalent to <tt>PrivilegeManager.getPrivilege(String)</tt></li>
</ul>
-<p><a name="jackrabbit_api"></a></p></div>
-<div class="section">
-<h3><a name="Jackrabbit_API"></a>Jackrabbit API</h3>
-<p>Privilege management is outside of the scope provided by JCR and therefore provided by the extensions defined by the Jackrabbit API. It consists of a single interface:</p>
+<a name="jackrabbit_api"></a>
+### Jackrabbit API
+<p>Privilege management is outside of the scope provided by JCR and therefore provided by the extensions defined by the Jackrabbit API. It consists of a single interface:</p>
<ul>
-
+
<li><a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/authorization/PrivilegeManager.java">PrivilegeManager</a>: privilege discovery and registration of new custom privileges.
-
<ul>
-
+
<li><tt>getRegisteredPrivileges()</tt></li>
-
<li><tt>getPrivilege(String)</tt></li>
-
<li>`registerPrivilege(String, boolean, String[])</li>
- </ul></li>
+</ul>
+</li>
</ul>
<div class="section">
<div class="section">
+<div class="section">
<h5><a name="Examples"></a>Examples</h5>
<div class="section">
<h6><a name="Access_PrivilegeManager_in_JCR"></a>Access PrivilegeManager in JCR</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">PrivilegeManager privilegeManager = session.getWorkspace().getPrivilegeManager();
-</pre></div></div></div>
+<div>
+<div>
+<pre class="source">PrivilegeManager privilegeManager = session.getWorkspace().getPrivilegeManager();
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Access_PrivilegeManager_in_Oak"></a>Access PrivilegeManager in Oak</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">Root root = contentSession.getLatestRoot();
+<div>
+<div>
+<pre class="source">Root root = contentSession.getLatestRoot();
PrivilegeConfiguration config = securityProvider.getConfiguration(PrivilegeConfiguration.class);
PrivilegeManager privilegeManage = config.getPrivilegeManager(root, namePathMapper));
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Register_Custom_Privilege"></a>Register Custom Privilege</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">PrivilegeManager privilegeManager = session.getWorkspace().getPrivilegeManager();
+<div>
+<div>
+<pre class="source">PrivilegeManager privilegeManager = session.getWorkspace().getPrivilegeManager();
String privilegeName = ...
boolean isAbstract = ...
String[] declaredAggregateNames = ...
// NOTE: workspace operation that doesn't require Session#save()
privilegeManager.registerPrivilege(privilegeName, isAbstract, declaredAggregateNames);
</pre></div></div>
-<p><a name="api_extensions"></a></p></div></div></div></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
+<a name="api_extensions"></a>
+### API Extensions
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.html">PrivilegeConfiguration</a> : Oak level entry point to retrieve <tt>PrivilegeManager</tt> and privilege related configuration options.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConstants.html">PrivilegeConstants</a> : Constants related to privilege management such as Oak names of the built-in privileges.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBitsProvider.html">PrivilegeBitsProvider</a> : Internal provider to read <tt>PrivilegeBits</tt> from the repository content and map names to internal representation (and vice versa).</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeBits.html">PrivilegeBits</a>: Internal representation of JCR privileges.</li>
</ul>
-<p><a name="utilities"></a></p></div>
-<div class="section">
-<h3><a name="Utilities"></a>Utilities</h3>
-<p>The jcr-commons module present with Jackrabbit provide some privilege related utility methods:</p>
+<a name="utilities"></a>
+### Utilities
+<p>The jcr-commons module present with Jackrabbit provide some privilege related utility methods:</p>
<ul>
-
+
<li><tt>AccessControlUtils</tt>
-
<ul>
-
+
<li><tt>privilegesFromNames(Session session, String... privilegeNames)</tt></li>
-
<li><tt>privilegesFromNames(AccessControlManager accessControlManager, String... privilegeNames)</tt></li>
- </ul></li>
</ul>
-<p><a name="default_implementation"></a></p></div>
-<div class="section">
-<h3><a name="Oak_Privilege_Management_Implementation"></a>Oak Privilege Management Implementation</h3>
+</li>
+</ul>
+<a name="default_implementation"></a>
+### Oak Privilege Management Implementation
+
<p>The behavior of the default privilege management implementation is described in section <a href="privilege/default.html">Privilege Management: The Default Implementation</a>.</p>
-<p><a name="configuration"></a></p></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
+<a name="configuration"></a>
+### Configuration
+
<p>The <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/privilege/PrivilegeConfiguration.html">PrivilegeConfiguration</a> is the Oak level entry point to obtain a new <tt>PrivilegeManager</tt> as well as privilege related configuration options. The default implementation of the <tt>PrivilegeManager</tt> interface is based on Oak API and can equally be used for privilege related tasks in the Oak layer.</p>
-<p><a name="pluggability"></a></p></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
+<a name="pluggability"></a>
+### Pluggability
+
<p><i>Please note:</i> While it’s in theory possible to replace the default privilege management implementation in Oak, this is only recommended if you have in depth knowledge and understanding of Jackrabbit/Oak internals and are familiar with the security risk associated with it. Doing so, will most likely require a re-write of the default access control and permission evaluation.</p>
-<p><a name="further_reading"></a></p></div>
-<div class="section">
-<h3><a name="Further_Reading"></a>Further Reading</h3>
+<a name="further_reading"></a>
+### Further Reading
<ul>
-
+
<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>
-<!-- references --></div></div>
+</li>
+</ul><!-- references --></div></div></div></div></div>
</div>
</div>
</div>