You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by an...@apache.org on 2016/02/12 18:09:07 UTC
svn commit: r1730074 [2/8] - in /jackrabbit/site/live/oak/docs: ./ META-INF/
architecture/ coldstandby/ features/ nodestore/ nodestore/segment/
oak-mongo-js/ oak_api/ plugins/ query/ security/ security/accesscontrol/
security/authentication/ security/a...
Propchange: jackrabbit/site/live/oak/docs/security/.DS_Store
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Modified: jackrabbit/site/live/oak/docs/security/accesscontrol.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/accesscontrol.html?rev=1730074&r1=1730073&r2=1730074&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/accesscontrol.html (original)
+++ jackrabbit/site/live/oak/docs/security/accesscontrol.html Fri Feb 12 17:09:05 2016
@@ -1,15 +1,15 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia at 2016-02-08
+ | Generated by Apache Maven Doxia at 2016-02-10
| Rendered using Apache Maven Fluido Skin 1.3.0
-->
<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="20160208" />
+ <meta name="Date-Revision-yyyymmdd" content="20160210" />
<meta http-equiv="Content-Language" content="en" />
- <title>Jackrabbit Oak - Access Control</title>
+ <title>Jackrabbit Oak - Access Control Management</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="../css/site.css" />
<link rel="stylesheet" href="../css/print.css" media="print" />
@@ -213,7 +213,7 @@
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2016-02-08</li>
+ <li id="publishDate">Last Published: 2016-02-10</li>
<li class="divider">|</li> <li id="projectVersion">Version: 1.4-SNAPSHOT</li>
@@ -507,7 +507,12 @@
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>Access Control<a name="Access_Control"></a></h2>
+<h2>Access Control Management<a name="Access_Control_Management"></a></h2>
+<div class="section">
+<h3>General<a name="General"></a></h3>
+<p>This section covers fundamental concepts of the access control related APIs provided by JCR and Jackrabbit as well as the extensions points defined by Oak. </p>
+<p>If you are already familiar with the API and looking for examples you may directly read <a href="accesscontrol/editing.html">Using the Access Control Management API</a> for a comprehensive list of method calls as well as examples that may be used to edit the access control content of the repository.</p>
+<p><a href="jcr_api"></a></p></div>
<div class="section">
<h3>JCR API<a name="JCR_API"></a></h3>
<p>Access Control Management is an optional feature defined by <a class="externalLink" href="http://www.day.com/specs/jcr/2.0/16_Access_Control_Management.html">JSR 283</a> consisting of</p>
@@ -547,7 +552,8 @@
<li><i>effect</i>: policies bound to a given node only take effect upon <tt>Session.save()</tt>. Access to properties is defined by the their parent node.</li>
<li><i>scope</i>: a given policy may not only affect the node it is bound to but may have an effect on accessibility of items elsewhere in the workspace.</li>
-</ul></div>
+</ul>
+<p><a name="jackrabbit_api"></a></p></div>
<div class="section">
<h3>Jackrabbit API<a name="Jackrabbit_API"></a></h3>
<p>The Jackrabbit API defines various access control related extensions to the JCR API in order to cover common needs such as for example:</p>
@@ -587,323 +593,8 @@
<li><tt>JackrabbitAccessControlList</tt></li>
<li><tt>JackrabbitAccessControlEntry</tt></li>
-</ul></div>
-<div class="section">
-<h3>Edit Access Control<a name="Edit_Access_Control"></a></h3>
-<p>see section <a href="accesscontrol/editing.html">Using the Access Control Management API</a> for a comprehensive list of method calls as well as examples that may be used to edit the access control content of the repository.</p></div>
-<div class="section">
-<h3>Characteristics of the Default Implementation<a name="Characteristics_of_the_Default_Implementation"></a></h3>
-<div class="section">
-<h4>General<a name="General"></a></h4>
-<p>In general the authorization related code in Oak clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation (see also <a href="permission/differences.html">Permission Evaluation</a>).</p></div>
-<div class="section">
-<h4>Differences wrt Jackrabbit 2.x<a name="Differences_wrt_Jackrabbit_2.x"></a></h4>
-<p>see the corresponding <a href="accesscontrol/differences.html">documentation</a>.</p></div>
-<div class="section">
-<h4>Resource vs Principal Based Access Control<a name="Resource_vs_Principal_Based_Access_Control"></a></h4>
-<p>The default implementation present with Oak 1.0 is natively resource-based which corresponds to the way JCR defines access control. Nevertheless the principal based approach as defined by the Jackrabbit API is supported using a best-effort approach: principal-based policies are created using the Oak query API and fully respect the access rights imposed on the different policies that contain entries for a given principal. These principal-based policies can also be modified using the corresponding methods provided by the access control, except for <tt>JackrabbitAccessControlList.orderBefore</tt>.</p>
-<p>Thus the default implementation corresponds to the default implementation present with Jackrabbit 2.x. Note however, that the former principal-base approach that stored policies per principal in a dedicated tree is no longer available.</p></div>
-<div class="section">
-<h4>Access Control Policies<a name="Access_Control_Policies"></a></h4>
-<p>The Oak access control management exposes two types of policies that cover all use case defined by the specification and required by the default setup:</p>
-
-<table border="0" class="table table-striped">
- <thead>
-
-<tr class="a">
-
-<th>Name </th>
-
-<th>Policy </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
-<tr class="b">
-
-<td>Default ACL </td>
-
-<td><tt>JackrabbitAccessControlList</tt> </td>
-
-<td>access control on individual nodes </td>
- </tr>
-
-<tr class="a">
-
-<td>Repo-Level ACL </td>
-
-<td><tt>JackrabbitAccessControlList</tt> </td>
-
-<td>repo-level access control for the <tt>null</tt> path </td>
- </tr>
-
-<tr class="b">
-
-<td>Read Policy </td>
-
-<td><tt>NamedAccessControlPolicy</tt> </td>
-
-<td>trees that are configured to be readable to everyone </td>
- </tr>
-
-<tr class="a">
-
-<td> </td>
-
-<td> </td>
-
-<td> </td>
- </tr>
- </tbody>
-</table>
-<div class="section">
-<h5>Default ACL<a name="Default_ACL"></a></h5>
-<p>The default access control lists are bound to individual nodes. They may be used to grant/deny access for all operations that are in some way related to JCR items: regular read/write, access control management, versioning, locking and as of Oak 1.0 user management and writing index definitions.</p>
-<p>These policies are designed to take effect on the complete subtree spanned by the node they are bound to. The individual access control entries are evaluated in strict order (first entries in a given list, second entries inherited from list bound to parent nodes) with one notable exception: access control entries created for non-group principals always take precedence irrespective of their inheritance status.</p>
-<p>Further details are described in section <a href="permission.html">Permissions</a>.</p></div>
-<div class="section">
-<h5>Repo-Level ACL<a name="Repo-Level_ACL"></a></h5>
-<p>The access control lists bound to the <tt>null</tt> path can be used to grant/deny privileges associated with operations on repository-level such as namespace, node type, privilege and workspace management.</p>
-<p>The effect of these entries is limited to the repository operations and is no inherited to any items inside the repository.</p></div>
-<div class="section">
-<h5>Read Policy<a name="Read_Policy"></a></h5>
-<p>These immutable policy has been introduced in Oak 1.0 in order to allow for opening up trees that need to be readable to all sessions irrespective of other effective policies.</p>
-<p>By default these policies are bound to the following trees:</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>The 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>
-<div class="section">
-<h4>Access Control Entries<a name="Access_Control_Entries"></a></h4>
-<p>The access control entries present in a given list are subject to the following rules applied upon editing but not enforced by <tt>CommitHook</tt>s:</p>
-
-<ul>
-
-<li><i>uniqueness</i>: a given entry may only appear onces in a list</li>
-
-<li><i>merging</i>: if an entry exists for a given principal with the same allow-status and restrictions, the existing entry will be updated without being moved in the list.</li>
-
-<li><i>redundancy</i>: if an new entry makes an existing entry (partially) redundant the existing entry will be updated or removed altogether.</li>
-</ul></div>
-<div class="section">
-<h4>Restrictions<a name="Restrictions"></a></h4>
-<p>Access control entries may be created by limiting their effect by adding restrictions as mentioned by JSR 283. Details about the restriction management in Oak 1.0 as well as a list of built-in restrictions and extensibility can be found in section <a href="accesscontrol/restriction.html">Restriction Management</a>.</p></div>
-<div class="section">
-<h4>Representation in the Repository<a name="Representation_in_the_Repository"></a></h4>
-<p>All access control policies defined with an Oak repository are stores child of the node they are bound to. The node type definition used to represent access control content:</p>
-
-<div class="source">
-<pre>[rep:AccessControllable]
- mixin
- + rep:policy (rep:Policy) protected IGNORE
-
-[rep:RepoAccessControllable]
- mixin
- + rep:repoPolicy (rep:Policy) protected IGNORE
-
-[rep:Policy]
- abstract
-
-[rep:ACL] > rep:Policy
- orderable
- + * (rep:ACE) = rep:GrantACE protected IGNORE
-
-[rep:ACE]
- - rep:principalName (STRING) protected mandatory
- - rep:privileges (NAME) protected mandatory multiple
- - rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
- - rep:glob (STRING) protected /* deprecated in favor of restrictions */
- - * (UNDEFINED) protected /* deprecated in favor of restrictions */
- + rep:restrictions (rep:Restrictions) = rep:Restrictions protected /* since oak 1.0 */
-
-[rep:GrantACE] > rep:ACE
-
-[rep:DenyACE] > rep:ACE
-
-/**
- * @since oak 1.0
- */
-[rep:Restrictions]
- - * (UNDEFINED) protected
- - * (UNDEFINED) protected multiple
-</pre></div>
-<div class="section">
-<h5>Examples<a name="Examples"></a></h5>
-<div class="section">
-<h6>Regular ACL at /content<a name="Regular_ACL_at_content"></a></h6>
-
-<div class="source">
-<pre>"": {
- "jcr:primaryType": "rep:root",
- "content": {
- "jcr:primaryType": "oak:Unstructured",
- "jcr:mixinTypes": "rep:AccessControllable",
- "rep:policy": {
- "jcr:primaryType": "rep:ACL",
- "allow": {
- "jcr:primaryType": "rep:GrantACE",
- "rep:principalName": "jackrabbit",
- "rep:privileges": ["jcr:read", "rep:write"]
- },
- "deny": {
- "jcr:primaryType": "rep:DenyACE",
- "rep:principalName": "jackrabbit",
- "rep:privileges": ["jcr:addNodes", "rep:addProperties"],
- "rep:restrictions" {
- "jcr:primaryType": "rep:Restrictions",
- "rep:ntNames": ["nt:hierarchyNode", "nt:resource"]
- }
- }
- }
- }
-}
-</pre></div></div>
-<div class="section">
-<h6>Repo-Level Policy<a name="Repo-Level_Policy"></a></h6>
-
-<div class="source">
-<pre>"": {
- "jcr:primaryType": "rep:root",
- "jcr:mixinTypes": "rep:RepoAccessControllable",
- "rep:repoPolicy": {
- "jcr:primaryType": "rep:ACL",
- "allow": {
- "jcr:primaryType": "rep:GrantACE",
- "rep:principalName": "elefant",
- "rep:privileges": ["rep:privilegeManagement"]
- }
- }
-}
-</pre></div>
-<p><a name="validation"></a></p></div></div>
-<div class="section">
-<h5>Validation<a name="Validation"></a></h5>
-<p>The consistency of this content structure is asserted by a dedicated <tt>AccessControlValidator</tt>. The corresponding errors are all of type <tt>AccessControl</tt> with the following codes:</p>
-
-<table border="0" class="table table-striped">
- <thead>
-
-<tr class="a">
-
-<th>Code </th>
-
-<th>Message </th>
- </tr>
- </thead>
- <tbody>
-
-<tr class="b">
-
-<td>0001 </td>
-
-<td>Generic access control violation </td>
- </tr>
-
-<tr class="a">
-
-<td>0002 </td>
-
-<td>Access control entry node expected </td>
- </tr>
-
-<tr class="b">
-
-<td>0003 </td>
-
-<td>Invalid policy name </td>
- </tr>
-
-<tr class="a">
-
-<td>0004 </td>
-
-<td>Invalid policy node: Order of children is not stable </td>
- </tr>
-
-<tr class="b">
-
-<td>0005 </td>
-
-<td>Access control policy within access control content </td>
- </tr>
-
-<tr class="a">
-
-<td>0006 </td>
-
-<td>Isolated policy node </td>
- </tr>
-
-<tr class="b">
-
-<td>0007 </td>
-
-<td>Isolated access control entry </td>
- </tr>
-
-<tr class="a">
-
-<td>0008 </td>
-
-<td>ACE without principal name </td>
- </tr>
-
-<tr class="b">
-
-<td>0009 </td>
-
-<td>ACE without privileges </td>
- </tr>
-
-<tr class="a">
-
-<td>0010 </td>
-
-<td>ACE contains invalid privilege name </td>
- </tr>
-
-<tr class="b">
-
-<td>0011 </td>
-
-<td>ACE uses abstract privilege </td>
- </tr>
-
-<tr class="a">
-
-<td>0012 </td>
-
-<td>Repository level policies defined with non-root node </td>
- </tr>
-
-<tr class="b">
-
-<td>0013 </td>
-
-<td>Duplicate ACE found in policy </td>
- </tr>
- </tbody>
-</table></div></div>
-<div class="section">
-<h4>XML Import<a name="XML_Import"></a></h4>
-<p>As of OAK 1.0 access control content can be imported both with Session and Workspace import.</p>
-<p>In addition the JCR XML import behavior has been extended to respect the <tt>o.a.j.oak.spi.xml.ImportBehavior</tt> flags instead of just performing a best effort import.</p>
-<p>Currently the <tt>ImportBehavior</tt> is only used to switch between different ways of handling principals unknown to the repository. For consistency and in order to match the validation requirements as specified by <tt>AccessControlList#addAccessControlEntry</tt> the default behavior is ABORT (while in Jackrabbit 2.x the behavior always was BESTEFFORT).</p>
-<p>The different <tt>ImportBehavior</tt> flags are implemented as follows: - <tt>ABORT</tt>: throws an <tt>AccessControlException</tt> if the principal is unknown - <tt>IGNORE</tt>: ignore the entry defining the unknown principal - <tt>BESTEFFORT</tt>: import the access control entry with an unknown principal.</p>
-<p>In order to get the same best effort behavior as present with Jackrabbit 2.x the configuration parameters of the <tt>AuthorizationConfiguration</tt> must contain the following entry:</p>
-
-<div class="source">
-<pre>importBehavior = "besteffort"
-</pre></div>
-<p>See also (<a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1350">OAK-1350</a>))</p></div></div>
+<p><a name="api_extensions"></a></p></div>
<div class="section">
<h3>API Extensions<a name="API_Extensions"></a></h3>
<p>Oak defines the following interfaces extending the access control management API:</p>
@@ -929,7 +620,8 @@
</ul>
<div class="section">
<h4>Restriction Management<a name="Restriction_Management"></a></h4>
-<p>Oak 1.0 defines a dedicated restriction management API. See <a href="accesscontrol/restriction.html">Restriction Management</a> for details and further information regarding extensibility and pluggability.</p></div></div>
+<p>Oak 1.0 defines a dedicated restriction management API. See <a href="authorization/restriction.html">Restriction Management</a> for details and further information regarding extensibility and pluggability.</p>
+<p><a href="utilities"></a></p></div></div>
<div class="section">
<h3>Utilities<a name="Utilities"></a></h3>
<p>The jcr-commons module present with Jackrabbit provide some access control related utilities that simplify the creation of new policies and entries such as for example:</p>
@@ -955,6 +647,10 @@ acMgr.setPolicy(path, acl);
session.save();
</pre></div></div></div></div>
<div class="section">
+<h3>Characteristics of the Default Implementation<a name="Characteristics_of_the_Default_Implementation"></a></h3>
+<p>The behavior of the default access control implementation is described in sections <a href="accesscontrol/default.html">Access Control Management: The Default Implementation</a><br />and <a href="authorization/restriction.html">Restriction Management</a>.</p>
+<p><a name="configuration"></a></p></div>
+<div class="section">
<h3>Configuration<a name="Configuration"></a></h3>
<p>The configuration of the access control management implementation is handled within 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 access control related methods:</p>
@@ -966,79 +662,7 @@ session.save();
</ul>
<div class="section">
<h4>Configuration Parameters<a name="Configuration_Parameters"></a></h4>
-<p>The default implementation supports the following configuration parameters:</p>
-
-<table border="0" class="table table-striped">
- <thead>
-
-<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
- </tr>
- </thead>
- <tbody>
-
-<tr class="b">
-
-<td><tt>PARAM_RESTRICTION_PROVIDER</tt> </td>
-
-<td>RestrictionProvider </td>
-
-<td>RestrictionProviderImpl </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>
- </tr>
-
-<tr class="b">
-
-<td><tt>PARAM_IMPORT_BEHAVIOR</tt> </td>
-
-<td>String (“abort”, “ignore”, “besteffort”) </td>
-
-<td>“abort” </td>
- </tr>
-
-<tr class="a">
-
-<td> </td>
-
-<td> </td>
-
-<td> </td>
- </tr>
- </tbody>
-</table>
-<p>Differences to Jackrabbit 2.x:</p>
-
-<ul>
-
-<li>The “omit-default-permission” configuration option present with the Jackrabbit’s AccessControlProvider implementations is no longer supported with Oak.</li>
-
-<li>As of OAK no extra access control content is installed by default which renders that flag superfluous.</li>
-</ul></div></div>
-<div class="section">
-<h3>Pluggability<a name="Pluggability"></a></h3>
-<p>There are multiple levels for plugging access control related custom implementations:</p>
-
-<ol style="list-style-type: decimal">
-
-<li>replace <tt>AuthorizationConfiguration</tt>: if you want to completely replace the way authorization is handled in the repository. In OSGi-base setup this is achieved by making the configuration implementation a service. In a non-OSGi-base setup the custom configuration must be exposed by the <tt>SecurityProvider</tt> implementation.</li>
-
-<li>extend <tt>AuthorizationConfiguration</tt>: it is planned to provide a <tt>CompositeAuthorizationConfiguration</tt> that allows to aggregate different authorization implementations (see <a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1268">OAK-1268</a>).</li>
-
-<li>extend the existing implementation by providing custom restrictions (see <a href="authorization/restriction.html">RestrictionManagement</a>.</li>
-</ol></div>
+<p>The supported configuration options of the default implementation are described in the corresponding <a href="accesscontrol/default.html#configuration">section</a>.</p></div></div>
<div class="section">
<h3>Further Reading<a name="Further_Reading"></a></h3>
@@ -1046,7 +670,11 @@ session.save();
<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/restriction.html">Restriction Management</a></li>
+
+<li><a href="accesscontrol/editing.html">Using the Access Control Management API</a></li>
</ul>
<!-- hidden references --></div></div>
</div>
Added: jackrabbit/site/live/oak/docs/security/accesscontrol/default.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/accesscontrol/default.html?rev=1730074&view=auto
==============================================================================
--- jackrabbit/site/live/oak/docs/security/accesscontrol/default.html (added)
+++ jackrabbit/site/live/oak/docs/security/accesscontrol/default.html Fri Feb 12 17:09:05 2016
@@ -0,0 +1,918 @@
+<!DOCTYPE html>
+<!--
+ | Generated by Apache Maven Doxia at 2016-02-10
+ | Rendered using Apache Maven Fluido Skin 1.3.0
+-->
+<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="20160210" />
+ <meta http-equiv="Content-Language" content="en" />
+ <title>Jackrabbit Oak - Access Control Management : The Default Implementation</title>
+ <link rel="stylesheet" href="../../css/apache-maven-fluido-1.3.0.min.css" />
+ <link rel="stylesheet" href="../../css/site.css" />
+ <link rel="stylesheet" href="../../css/print.css" media="print" />
+
+
+ <script type="text/javascript" src="../../js/apache-maven-fluido-1.3.0.min.js"></script>
+
+
+ </head>
+ <body class="topBarEnabled">
+
+
+
+
+
+
+ <a href="http://github.com/apache/jackrabbit-oak">
+ <img style="position: absolute; top: 0; right: 0; border: 0; z-index: 10000;"
+ src="https://s3.amazonaws.com/github/ribbons/forkme_right_red_aa0000.png"
+ alt="Fork me on GitHub">
+ </a>
+
+
+
+
+
+ <div id="topbar" class="navbar navbar-fixed-top ">
+ <div class="navbar-inner">
+ <div class="container-fluid">
+ <a data-target=".nav-collapse" data-toggle="collapse" class="btn btn-navbar">
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </a>
+
+ <a class="brand" href="../../" title="Oak logo">
+
+
+ <img src="../../oak_logo.png" alt="Oak logo" />
+
+ </a>
+
+ <ul class="nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Overview <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="../../index.html" title="Jackrabbit Oak">Jackrabbit Oak</a>
+</li>
+
+ <li> <a href="../../license.html" title="License">License</a>
+</li>
+
+ <li> <a href="../../downloads.html" title="Downloads">Downloads</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Concepts and Architecture <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="../../architecture/overview.html" title="Overview">Overview</a>
+</li>
+
+ <li> <a href="../../architecture/nodestate.html" title="The Node State Model">The Node State Model</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Main APIs <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="http://www.day.com/specs/jcr/2.0/index.html" title="JCR API">JCR API</a>
+</li>
+
+ <li> <a href="../../oak_api/overview.html" title="Oak API">Oak API</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Features and Plugins <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="../../features/atomic-counter.html" title="Atomic Counter">Atomic Counter</a>
+</li>
+
+ <li> <a href="../../plugins/blobstore.html" title="Blob Storage">Blob Storage</a>
+</li>
+
+ <li> <a href="../../clustering.html" title="Clustering">Clustering</a>
+</li>
+
+ <li> <a href="../../nodestore/documentmk.html" title="DocumentNodeStore">DocumentNodeStore</a>
+</li>
+
+ <li> <a href="../../nodestore/overview.html" title="Node Storage">Node Storage</a>
+</li>
+
+ <li> <a href="../../nodestore/persistent-cache.html" title="Persistent Cache">Persistent Cache</a>
+</li>
+
+ <li> <a href="../../query/query.html" title="Query">Query</a>
+</li>
+
+ <li> <a href="../../security/overview.html" title="Security">Security</a>
+</li>
+
+ <li> <a href="../../nodestore/segment/overview.html" title="Segment Node Store">Segment Node Store</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Using Oak <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="../../use_getting_started.html" title="Getting Started">Getting Started</a>
+</li>
+
+ <li> <a href="../../construct.html" title="Repository Construction">Repository Construction</a>
+</li>
+
+ <li> <a href="../../osgi_config.html" title="Configuring Oak">Configuring Oak</a>
+</li>
+
+ <li> <a href="../../command_line.html" title="Command Line Tools">Command Line Tools</a>
+</li>
+
+ <li> <a href="../../migration.html" title="Migration">Migration</a>
+</li>
+
+ <li> <a href="../../differences.html" title="Differences to Jackrabbit 2">Differences to Jackrabbit 2</a>
+</li>
+
+ <li> <a href="../../known_issues.html" title="Known Issues">Known Issues</a>
+</li>
+
+ <li> <a href="../../dos_and_donts.html" title="Dos and Don'ts">Dos and Don'ts</a>
+</li>
+
+ <li> <a href="../../coldstandby/coldstandby.html" title="Cold Standby">Cold Standby</a>
+</li>
+
+ <li> <a href="../../FAQ.html" title="FAQ">FAQ</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Developing Oak <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="../../dev_getting_started.html" title="Getting Started">Getting Started</a>
+</li>
+
+ <li> <a href="../../participating.html" title="Participating">Participating</a>
+</li>
+
+ <li> <a href="../../developing-with-git.html" title="Developing with Git">Developing with Git</a>
+</li>
+
+ <li> <a href="../../diagnostic-builds.html" title="Cutting diagnostic builds">Cutting diagnostic builds</a>
+</li>
+
+ <li> <a href="../../attribution.html" title="Attribution">Attribution</a>
+</li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown">Links <b class="caret"></b></a>
+ <ul class="dropdown-menu">
+
+ <li> <a href="http://jackrabbit.apache.org/oak" title="Apache Jackrabbit Oak">Apache Jackrabbit Oak</a>
+</li>
+
+ <li> <a href="http://jackrabbit.apache.org/" title="Apache Jackrabbit">Apache Jackrabbit</a>
+</li>
+ </ul>
+ </li>
+ </ul>
+
+
+
+
+ </div>
+
+ </div>
+ </div>
+ </div>
+
+ <div class="container-fluid">
+ <div id="banner">
+ <div class="pull-left">
+ <div id="bannerLeft">
+ <h2>Oak Documentation</h2>
+ </div>
+ </div>
+ <div class="pull-right"> </div>
+ <div class="clear"><hr/></div>
+ </div>
+
+ <div id="breadcrumbs">
+ <ul class="breadcrumb">
+
+
+ <li id="publishDate">Last Published: 2016-02-10</li>
+ <li class="divider">|</li> <li id="projectVersion">Version: 1.4-SNAPSHOT</li>
+
+
+
+
+ </ul>
+ </div>
+
+
+ <div class="row-fluid">
+ <div id="leftColumn" class="span3">
+ <div class="well sidebar-nav">
+
+
+ <ul class="nav nav-list">
+ <li class="nav-header">Overview</li>
+
+ <li>
+
+ <a href="../../index.html" title="Jackrabbit Oak">
+ <i class="none"></i>
+ Jackrabbit Oak</a>
+ </li>
+
+ <li>
+
+ <a href="../../license.html" title="License">
+ <i class="none"></i>
+ License</a>
+ </li>
+
+ <li>
+
+ <a href="../../downloads.html" title="Downloads">
+ <i class="none"></i>
+ Downloads</a>
+ </li>
+ <li class="nav-header">Concepts and Architecture</li>
+
+ <li>
+
+ <a href="../../architecture/overview.html" title="Overview">
+ <i class="none"></i>
+ Overview</a>
+ </li>
+
+ <li>
+
+ <a href="../../architecture/nodestate.html" title="The Node State Model">
+ <i class="none"></i>
+ The Node State Model</a>
+ </li>
+ <li class="nav-header">Main APIs</li>
+
+ <li>
+
+ <a href="http://www.day.com/specs/jcr/2.0/index.html" class="externalLink" title="JCR API">
+ <i class="none"></i>
+ JCR API</a>
+ </li>
+
+ <li>
+
+ <a href="../../oak_api/overview.html" title="Oak API">
+ <i class="none"></i>
+ Oak API</a>
+ </li>
+ <li class="nav-header">Features and Plugins</li>
+
+ <li>
+
+ <a href="../../features/atomic-counter.html" title="Atomic Counter">
+ <i class="none"></i>
+ Atomic Counter</a>
+ </li>
+
+ <li>
+
+ <a href="../../plugins/blobstore.html" title="Blob Storage">
+ <i class="none"></i>
+ Blob Storage</a>
+ </li>
+
+ <li>
+
+ <a href="../../clustering.html" title="Clustering">
+ <i class="none"></i>
+ Clustering</a>
+ </li>
+
+ <li>
+
+ <a href="../../nodestore/documentmk.html" title="DocumentNodeStore">
+ <i class="none"></i>
+ DocumentNodeStore</a>
+ </li>
+
+ <li>
+
+ <a href="../../nodestore/overview.html" title="Node Storage">
+ <i class="none"></i>
+ Node Storage</a>
+ </li>
+
+ <li>
+
+ <a href="../../nodestore/persistent-cache.html" title="Persistent Cache">
+ <i class="none"></i>
+ Persistent Cache</a>
+ </li>
+
+ <li>
+
+ <a href="../../query/query.html" title="Query">
+ <i class="none"></i>
+ Query</a>
+ </li>
+
+ <li>
+
+ <a href="../../security/overview.html" title="Security">
+ <i class="none"></i>
+ Security</a>
+ </li>
+
+ <li>
+
+ <a href="../../nodestore/segment/overview.html" title="Segment Node Store">
+ <i class="none"></i>
+ Segment Node Store</a>
+ </li>
+ <li class="nav-header">Using Oak</li>
+
+ <li>
+
+ <a href="../../use_getting_started.html" title="Getting Started">
+ <i class="none"></i>
+ Getting Started</a>
+ </li>
+
+ <li>
+
+ <a href="../../construct.html" title="Repository Construction">
+ <i class="none"></i>
+ Repository Construction</a>
+ </li>
+
+ <li>
+
+ <a href="../../osgi_config.html" title="Configuring Oak">
+ <i class="none"></i>
+ Configuring Oak</a>
+ </li>
+
+ <li>
+
+ <a href="../../command_line.html" title="Command Line Tools">
+ <i class="none"></i>
+ Command Line Tools</a>
+ </li>
+
+ <li>
+
+ <a href="../../migration.html" title="Migration">
+ <i class="none"></i>
+ Migration</a>
+ </li>
+
+ <li>
+
+ <a href="../../differences.html" title="Differences to Jackrabbit 2">
+ <i class="none"></i>
+ Differences to Jackrabbit 2</a>
+ </li>
+
+ <li>
+
+ <a href="../../known_issues.html" title="Known Issues">
+ <i class="none"></i>
+ Known Issues</a>
+ </li>
+
+ <li>
+
+ <a href="../../dos_and_donts.html" title="Dos and Don'ts">
+ <i class="none"></i>
+ Dos and Don'ts</a>
+ </li>
+
+ <li>
+
+ <a href="../../coldstandby/coldstandby.html" title="Cold Standby">
+ <i class="none"></i>
+ Cold Standby</a>
+ </li>
+
+ <li>
+
+ <a href="../../FAQ.html" title="FAQ">
+ <i class="none"></i>
+ FAQ</a>
+ </li>
+ <li class="nav-header">Developing Oak</li>
+
+ <li>
+
+ <a href="../../dev_getting_started.html" title="Getting Started">
+ <i class="none"></i>
+ Getting Started</a>
+ </li>
+
+ <li>
+
+ <a href="../../participating.html" title="Participating">
+ <i class="none"></i>
+ Participating</a>
+ </li>
+
+ <li>
+
+ <a href="../../developing-with-git.html" title="Developing with Git">
+ <i class="none"></i>
+ Developing with Git</a>
+ </li>
+
+ <li>
+
+ <a href="../../diagnostic-builds.html" title="Cutting diagnostic builds">
+ <i class="none"></i>
+ Cutting diagnostic builds</a>
+ </li>
+
+ <li>
+
+ <a href="../../attribution.html" title="Attribution">
+ <i class="none"></i>
+ Attribution</a>
+ </li>
+ <li class="nav-header">Links</li>
+
+ <li>
+
+ <a href="http://jackrabbit.apache.org/oak" class="externalLink" title="Apache Jackrabbit Oak">
+ <i class="none"></i>
+ Apache Jackrabbit Oak</a>
+ </li>
+
+ <li>
+
+ <a href="http://jackrabbit.apache.org/" class="externalLink" title="Apache Jackrabbit">
+ <i class="none"></i>
+ Apache Jackrabbit</a>
+ </li>
+ </ul>
+
+
+
+ <hr class="divider" />
+
+ <div id="poweredBy">
+
+ <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
+
+
+ <div class="g-plusone" data-href="http://jackrabbit.apache.org/oak/docs/" data-size="tall" ></div>
+
+ <div class="clear"></div>
+ <div class="clear"></div>
+ <div class="clear"></div>
+ <a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
+ <img class="builtBy" alt="Built by Maven" src="../../images/logos/maven-feather.png" />
+ </a>
+ </div>
+ </div>
+ </div>
+
+
+ <div id="bodyColumn" class="span9" >
+
+ <!-- Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License. --><div class="section">
+<h2>Access Control Management : The Default Implementation<a name="Access_Control_Management_:_The_Default_Implementation"></a></h2>
+<div class="section">
+<h3>General<a name="General"></a></h3>
+<p>In general the authorization related code in Oak clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation (see also <a href="../permission/differences.html">Permission Evaluation</a>).</p></div>
+<div class="section">
+<h3>Differences wrt Jackrabbit 2.x<a name="Differences_wrt_Jackrabbit_2.x"></a></h3>
+<p>see the corresponding <a href="differences.html">documentation</a>.</p></div>
+<div class="section">
+<h3>Resource vs Principal Based Access Control<a name="Resource_vs_Principal_Based_Access_Control"></a></h3>
+<p>The default implementation present with Oak 1.0 is natively resource-based which corresponds to the way JCR defines access control. Nevertheless the principal based approach as defined by the Jackrabbit API is supported using a best-effort approach: principal-based policies are created using the Oak query API and fully respect the access rights imposed on the different policies that contain entries for a given principal. These principal-based policies can also be modified using the corresponding methods provided by the access control, except for <tt>JackrabbitAccessControlList.orderBefore</tt>.</p>
+<p>Thus the default implementation corresponds to the default implementation present with Jackrabbit 2.x. Note however, that the former principal-base approach that stored policies per principal in a dedicated tree is no longer available.</p></div>
+<div class="section">
+<h3>The Elements of Access Control Management<a name="The_Elements_of_Access_Control_Management"></a></h3>
+<div class="section">
+<h4>Access Control Policies<a name="Access_Control_Policies"></a></h4>
+<p>The Oak access control management exposes two types of policies that cover all use case defined by the specification and required by the default setup:</p>
+
+<table border="0" class="table table-striped">
+ <thead>
+
+<tr class="a">
+
+<th>Name </th>
+
+<th>Policy </th>
+
+<th>Description </th>
+ </tr>
+ </thead>
+ <tbody>
+
+<tr class="b">
+
+<td>Default ACL </td>
+
+<td><tt>JackrabbitAccessControlList</tt> </td>
+
+<td>access control on individual nodes </td>
+ </tr>
+
+<tr class="a">
+
+<td>Repo-Level ACL </td>
+
+<td><tt>JackrabbitAccessControlList</tt> </td>
+
+<td>repo-level access control for the <tt>null</tt> path </td>
+ </tr>
+
+<tr class="b">
+
+<td>Read Policy </td>
+
+<td><tt>NamedAccessControlPolicy</tt> </td>
+
+<td>trees that are configured to be readable to everyone </td>
+ </tr>
+
+<tr class="a">
+
+<td> </td>
+
+<td> </td>
+
+<td> </td>
+ </tr>
+ </tbody>
+</table>
+<div class="section">
+<h5>Default ACL<a name="Default_ACL"></a></h5>
+<p>The default access control lists are bound to individual nodes. They may be used to grant/deny access for all operations that are in some way related to JCR items: regular read/write, access control management, versioning, locking and as of Oak 1.0 user management and writing index definitions.</p>
+<p>These policies are designed to take effect on the complete subtree spanned by the node they are bound to. The individual access control entries are evaluated in strict order (first entries in a given list, second entries inherited from list bound to parent nodes) with one notable exception: access control entries created for non-group principals always take precedence irrespective of their inheritance status.</p>
+<p>Further details are described in section <a href="../permission.html">Permissions</a>.</p></div>
+<div class="section">
+<h5>Repo-Level ACL<a name="Repo-Level_ACL"></a></h5>
+<p>The access control lists bound to the <tt>null</tt> path can be used to grant/deny privileges associated with operations on repository-level such as namespace, node type, privilege and workspace management.</p>
+<p>The effect of these entries is limited to the repository operations and is no inherited to any items inside the repository.</p></div>
+<div class="section">
+<h5>Read Policy<a name="Read_Policy"></a></h5>
+<p>These immutable policy has been introduced in Oak 1.0 in order to allow for opening up trees that need to be readable to all sessions irrespective of other effective policies.</p>
+<p>By default these policies are bound to the following trees:</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>The 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>
+<div class="section">
+<h4>Access Control Entries<a name="Access_Control_Entries"></a></h4>
+<p>The access control entries present in a given list are subject to the following rules applied upon editing but not enforced by <tt>CommitHook</tt>s:</p>
+
+<ul>
+
+<li><i>uniqueness</i>: a given entry may only appear onces in a list</li>
+
+<li><i>merging</i>: if an entry exists for a given principal with the same allow-status and restrictions, the existing entry will be updated without being moved in the list.</li>
+
+<li><i>redundancy</i>: if an new entry makes an existing entry (partially) redundant the existing entry will be updated or removed altogether.</li>
+</ul></div>
+<div class="section">
+<h4>Restrictions<a name="Restrictions"></a></h4>
+<p>Access control entries may be created by limiting their effect by adding restrictions as mentioned by JSR 283. Details about the restriction management in Oak 1.0 as well as a list of built-in restrictions and extensibility can be found in section <a href="../authorization/restriction.html">Restriction Management</a>.</p></div></div>
+<div class="section">
+<h3>Representation in the Repository<a name="Representation_in_the_Repository"></a></h3>
+<p>All access control policies defined with an Oak repository are stores child of the node they are bound to. The node type definition used to represent access control content:</p>
+
+<div class="source">
+<pre>[rep:AccessControllable]
+ mixin
+ + rep:policy (rep:Policy) protected IGNORE
+
+[rep:RepoAccessControllable]
+ mixin
+ + rep:repoPolicy (rep:Policy) protected IGNORE
+
+[rep:Policy]
+ abstract
+
+[rep:ACL] > rep:Policy
+ orderable
+ + * (rep:ACE) = rep:GrantACE protected IGNORE
+
+[rep:ACE]
+ - rep:principalName (STRING) protected mandatory
+ - rep:privileges (NAME) protected mandatory multiple
+ - rep:nodePath (PATH) protected /* deprecated in favor of restrictions */
+ - rep:glob (STRING) protected /* deprecated in favor of restrictions */
+ - * (UNDEFINED) protected /* deprecated in favor of restrictions */
+ + rep:restrictions (rep:Restrictions) = rep:Restrictions protected /* since oak 1.0 */
+
+[rep:GrantACE] > rep:ACE
+
+[rep:DenyACE] > rep:ACE
+
+/**
+ * @since oak 1.0
+ */
+[rep:Restrictions]
+ - * (UNDEFINED) protected
+ - * (UNDEFINED) protected multiple
+</pre></div>
+<div class="section">
+<div class="section">
+<h5>Examples<a name="Examples"></a></h5>
+<div class="section">
+<h6>Regular ACL at /content<a name="Regular_ACL_at_content"></a></h6>
+
+<div class="source">
+<pre>"": {
+ "jcr:primaryType": "rep:root",
+ "content": {
+ "jcr:primaryType": "oak:Unstructured",
+ "jcr:mixinTypes": "rep:AccessControllable",
+ "rep:policy": {
+ "jcr:primaryType": "rep:ACL",
+ "allow": {
+ "jcr:primaryType": "rep:GrantACE",
+ "rep:principalName": "jackrabbit",
+ "rep:privileges": ["jcr:read", "rep:write"]
+ },
+ "deny": {
+ "jcr:primaryType": "rep:DenyACE",
+ "rep:principalName": "jackrabbit",
+ "rep:privileges": ["jcr:addNodes", "rep:addProperties"],
+ "rep:restrictions" {
+ "jcr:primaryType": "rep:Restrictions",
+ "rep:ntNames": ["nt:hierarchyNode", "nt:resource"]
+ }
+ }
+ }
+ }
+}
+</pre></div></div>
+<div class="section">
+<h6>Repo-Level Policy<a name="Repo-Level_Policy"></a></h6>
+
+<div class="source">
+<pre>"": {
+ "jcr:primaryType": "rep:root",
+ "jcr:mixinTypes": "rep:RepoAccessControllable",
+ "rep:repoPolicy": {
+ "jcr:primaryType": "rep:ACL",
+ "allow": {
+ "jcr:primaryType": "rep:GrantACE",
+ "rep:principalName": "elefant",
+ "rep:privileges": ["rep:privilegeManagement"]
+ }
+ }
+}
+</pre></div></div></div></div></div>
+<div class="section">
+<h3>XML Import<a name="XML_Import"></a></h3>
+<p>As of OAK 1.0 access control content can be imported both with Session and Workspace import.</p>
+<p>In addition the JCR XML import behavior has been extended to respect the <tt>o.a.j.oak.spi.xml.ImportBehavior</tt> flags instead of just performing a best effort import.</p>
+<p>Currently the <tt>ImportBehavior</tt> is only used to switch between different ways of handling principals unknown to the repository. For consistency and in order to match the validation requirements as specified by <tt>AccessControlList#addAccessControlEntry</tt> the default behavior is ABORT (while in Jackrabbit 2.x the behavior always was BESTEFFORT).</p>
+<p>The different <tt>ImportBehavior</tt> flags are implemented as follows: - <tt>ABORT</tt>: throws an <tt>AccessControlException</tt> if the principal is unknown - <tt>IGNORE</tt>: ignore the entry defining the unknown principal - <tt>BESTEFFORT</tt>: import the access control entry with an unknown principal.</p>
+<p>In order to get the same best effort behavior as present with Jackrabbit 2.x the configuration parameters of the <tt>AuthorizationConfiguration</tt> must contain the following entry:</p>
+
+<div class="source">
+<pre>importBehavior = "besteffort"
+</pre></div>
+<p>See also (<a class="externalLink" href="https://issues.apache.org/jira/browse/OAK-1350">OAK-1350</a>))</p>
+<p><a name="validation"></a></p></div>
+<div class="section">
+<h3>Validation<a name="Validation"></a></h3>
+<p>The consistency of this content structure is asserted by a dedicated <tt>AccessControlValidator</tt>. The corresponding errors are all of type <tt>AccessControl</tt> with the following codes:</p>
+
+<table border="0" class="table table-striped">
+ <thead>
+
+<tr class="a">
+
+<th>Code </th>
+
+<th>Message </th>
+ </tr>
+ </thead>
+ <tbody>
+
+<tr class="b">
+
+<td>0001 </td>
+
+<td>Generic access control violation </td>
+ </tr>
+
+<tr class="a">
+
+<td>0002 </td>
+
+<td>Access control entry node expected </td>
+ </tr>
+
+<tr class="b">
+
+<td>0003 </td>
+
+<td>Invalid policy name </td>
+ </tr>
+
+<tr class="a">
+
+<td>0004 </td>
+
+<td>Invalid policy node: Order of children is not stable </td>
+ </tr>
+
+<tr class="b">
+
+<td>0005 </td>
+
+<td>Access control policy within access control content </td>
+ </tr>
+
+<tr class="a">
+
+<td>0006 </td>
+
+<td>Isolated policy node </td>
+ </tr>
+
+<tr class="b">
+
+<td>0007 </td>
+
+<td>Isolated access control entry </td>
+ </tr>
+
+<tr class="a">
+
+<td>0008 </td>
+
+<td>ACE without principal name </td>
+ </tr>
+
+<tr class="b">
+
+<td>0009 </td>
+
+<td>ACE without privileges </td>
+ </tr>
+
+<tr class="a">
+
+<td>0010 </td>
+
+<td>ACE contains invalid privilege name </td>
+ </tr>
+
+<tr class="b">
+
+<td>0011 </td>
+
+<td>ACE uses abstract privilege </td>
+ </tr>
+
+<tr class="a">
+
+<td>0012 </td>
+
+<td>Repository level policies defined with non-root node </td>
+ </tr>
+
+<tr class="b">
+
+<td>0013 </td>
+
+<td>Duplicate ACE found in policy </td>
+ </tr>
+ </tbody>
+</table>
+<p><a name="configuration"></a></p></div>
+<div class="section">
+<h3>Configuration<a name="Configuration"></a></h3>
+<div class="section">
+<h4>Configuration Parameters<a name="Configuration_Parameters"></a></h4>
+<p>The default implementation supports the following configuration parameters:</p>
+
+<table border="0" class="table table-striped">
+ <thead>
+
+<tr class="a">
+
+<th>Parameter </th>
+
+<th>Type </th>
+
+<th>Default </th>
+ </tr>
+ </thead>
+ <tbody>
+
+<tr class="b">
+
+<td><tt>PARAM_RESTRICTION_PROVIDER</tt> </td>
+
+<td>RestrictionProvider </td>
+
+<td>RestrictionProviderImpl </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>
+ </tr>
+
+<tr class="b">
+
+<td><tt>PARAM_IMPORT_BEHAVIOR</tt> </td>
+
+<td>String (“abort”, “ignore”, “besteffort”) </td>
+
+<td>“abort” </td>
+ </tr>
+
+<tr class="a">
+
+<td> </td>
+
+<td> </td>
+
+<td> </td>
+ </tr>
+ </tbody>
+</table>
+<p>Differences to Jackrabbit 2.x:</p>
+
+<ul>
+
+<li>The “omit-default-permission” configuration option present with the Jackrabbit’s AccessControlProvider implementations is no longer supported with Oak.</li>
+
+<li>As of OAK no extra access control content is installed by default which renders that flag superfluous.</li>
+</ul>
+<!-- hidden references --></div></div></div>
+ </div>
+ </div>
+ </div>
+
+ <hr/>
+
+ <footer>
+ <div class="container-fluid">
+ <div class="row span12">Copyright © 2012-2016
+ <a href="http://www.apache.org/">The Apache Software Foundation</a>.
+ All Rights Reserved.
+
+ </div>
+
+
+
+
+
+
+
+ <div id="ohloh" class="pull-right">
+ <script type="text/javascript" src="http://www.ohloh.net/p/jackrabbit-oak/widgets/project_thin_badge.js"></script>
+ </div>
+ </div>
+ </footer>
+ </body>
+</html>
\ No newline at end of file
Propchange: jackrabbit/site/live/oak/docs/security/accesscontrol/default.html
------------------------------------------------------------------------------
svn:eol-style = native
Modified: jackrabbit/site/live/oak/docs/security/accesscontrol/differences.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/accesscontrol/differences.html?rev=1730074&r1=1730073&r2=1730074&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/accesscontrol/differences.html (original)
+++ jackrabbit/site/live/oak/docs/security/accesscontrol/differences.html Fri Feb 12 17:09:05 2016
@@ -1,15 +1,15 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia at 2016-02-08
+ | Generated by Apache Maven Doxia at 2016-02-10
| Rendered using Apache Maven Fluido Skin 1.3.0
-->
<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="20160208" />
+ <meta name="Date-Revision-yyyymmdd" content="20160210" />
<meta http-equiv="Content-Language" content="en" />
- <title>Jackrabbit Oak - AccessControl Management : Differences wrt Jackrabbit 2.x</title>
+ <title>Jackrabbit Oak - Access Control Management : Differences wrt Jackrabbit 2.x</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="../../css/site.css" />
<link rel="stylesheet" href="../../css/print.css" media="print" />
@@ -213,7 +213,7 @@
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2016-02-08</li>
+ <li id="publishDate">Last Published: 2016-02-10</li>
<li class="divider">|</li> <li id="projectVersion">Version: 1.4-SNAPSHOT</li>
@@ -508,7 +508,7 @@
See the License for the specific language governing permissions and
limitations under the License. --><div class="section">
<div class="section">
-<h3>AccessControl Management : Differences wrt Jackrabbit 2.x<a name="AccessControl_Management_:_Differences_wrt_Jackrabbit_2.x"></a></h3>
+<h3>Access Control Management : Differences wrt Jackrabbit 2.x<a name="Access_Control_Management_:_Differences_wrt_Jackrabbit_2.x"></a></h3>
<div class="section">
<h4>Characteristics of the Default Implementation<a name="Characteristics_of_the_Default_Implementation"></a></h4>
<div class="section">
@@ -535,32 +535,8 @@
<p>The principal-based access control management as present in Jackrabbit-core is no longer present with OAK. The main benefit of the principal-based approach has been incorporated with the changes in the default <a href="differences_permissions.html">permission evaluation</a>). In addition the default access control manager implementation supports all methods defined by <tt>JackrabbitAccessControlManager</tt>; i.e. editing access control information by principal is possible as long as the editing session has sufficient permission on the target node(s). Similarly, the per principal policies exposed to a given session will always respect that access rights of that session.</p></div>
<div class="section">
<h6>Restrictions<a name="Restrictions"></a></h6>
-<p>The implementation of the additional restrictions associated with an ACE has been modified/extended 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>restrictions can be multi-valued (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>backwards compatible behavior for restrictions stored underneath the ACE node directly</li>
- </ul></li>
-
-<li>New restrictions:
-
-<ul>
-
-<li>“rep:ntNames”, which allows to limit the affected ACE to nodes of the specified node type(s)</li>
-
-<li>“rep:prefixes”, which allows to limit the effect to item names that have a specific namespace prefix.</li>
- </ul></li>
-</ul></div></div>
+<p>The implementation of the additional restrictions associated with an ACE has been slighly modified/extended.</p>
+<p>See section <a href="../authorization/restriction.html">Restriction Management</a> for details. </p></div></div>
<div class="section">
<h5>Import<a name="Import"></a></h5>
Modified: jackrabbit/site/live/oak/docs/security/accesscontrol/editing.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/accesscontrol/editing.html?rev=1730074&r1=1730073&r2=1730074&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/accesscontrol/editing.html (original)
+++ jackrabbit/site/live/oak/docs/security/accesscontrol/editing.html Fri Feb 12 17:09:05 2016
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia at 2016-02-08
+ | Generated by Apache Maven Doxia at 2016-02-10
| Rendered using Apache Maven Fluido Skin 1.3.0
-->
<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="20160208" />
+ <meta name="Date-Revision-yyyymmdd" content="20160210" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak - Using the Access Control Management API</title>
<link rel="stylesheet" href="../../css/apache-maven-fluido-1.3.0.min.css" />
@@ -213,7 +213,7 @@
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2016-02-08</li>
+ <li id="publishDate">Last Published: 2016-02-10</li>
<li class="divider">|</li> <li id="projectVersion">Version: 1.4-SNAPSHOT</li>
@@ -546,7 +546,8 @@
<ul>
-<li><tt>AccessControlManager</tt>
+<li>
+<p><tt>AccessControlManager</tt></p>
<ul>
@@ -554,11 +555,9 @@
<li><tt>getPolicies(String)</tt></li>
</ul></li>
-</ul>
-
-<ul>
-<li><tt>JackrabbitAccessControlManager</tt>
+<li>
+<p><tt>JackrabbitAccessControlManager</tt></p>
<ul>
Modified: jackrabbit/site/live/oak/docs/security/authentication.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authentication.html?rev=1730074&r1=1730073&r2=1730074&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authentication.html (original)
+++ jackrabbit/site/live/oak/docs/security/authentication.html Fri Feb 12 17:09:05 2016
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia at 2016-02-08
+ | Generated by Apache Maven Doxia at 2016-02-12
| Rendered using Apache Maven Fluido Skin 1.3.0
-->
<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="20160208" />
+ <meta name="Date-Revision-yyyymmdd" content="20160212" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak - Authentication</title>
<link rel="stylesheet" href="../css/apache-maven-fluido-1.3.0.min.css" />
@@ -213,7 +213,7 @@
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2016-02-08</li>
+ <li id="publishDate">Last Published: 2016-02-12</li>
<li class="divider">|</li> <li id="projectVersion">Version: 1.4-SNAPSHOT</li>
@@ -553,9 +553,10 @@
<li><b>Optional</b>: The LoginModule is not required to succeed. If it succeeds or fails, authentication still continues to proceed down the LoginModule list.</li>
</ul>
-<p>The overall authentication succeeds <b>only</b> if <b>all</b> Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed.</p></div></div></div>
+<p>The overall authentication succeeds <b>only</b> if <b>all</b> Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed.</p>
+<p><a href="jcr_api"></a></p></div></div></div>
<div class="section">
-<h3>JCR Authentication<a name="JCR_Authentication"></a></h3>
+<h3>JCR API<a name="JCR_API"></a></h3>
<p>Within the scope of JCR <tt>Repository.login</tt> is used to authenticate a given user. This method either takes a <tt>Credentials</tt> argument if the validation is performed by the repository itself or <tt>null</tt> in case the user has be pre-authenticated by an external system.</p>
<p>Furthermore JCR defines two types of <tt>Credentials</tt> implementations:</p>
@@ -580,11 +581,10 @@
<li><tt>JackrabbitRepository.login(Credentials credentials, String workspaceName, Map<String, Object> attributes)</tt>: in addition allows to pass implementation specific session attributes.</li>
</ul>
<p>See <a class="externalLink" href="http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/Repository.html">javax.jcr.Repository</a> and <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/JackrabbitRepository.java">org.apache.jackrabbit.api.JackrabbitRepository</a> for further details.</p>
-<p>In addition JCR defines <tt>Session.impersonate(Credentials)</tt> to impersonate another user or - as of JSR 333 - clone an existing session.</p></div>
+<p>In addition JCR defines <tt>Session.impersonate(Credentials)</tt> to impersonate another user or - as of JSR 333 - clone an existing session.</p>
+<p><a href="oak_api"></a></p></div>
<div class="section">
-<h3>Oak Authentication<a name="Oak_Authentication"></a></h3>
-<div class="section">
-<h4>Oak API<a name="Oak_API"></a></h4>
+<h3>Oak API<a name="Oak_API"></a></h3>
<p>The Oak API contains the following authentication related methods and interfaces</p>
<ul>
@@ -596,175 +596,10 @@
<li><tt>ContentSession.getAuthInfo()</tt>: exposes the <tt>AuthInfo</tt> associated with the <tt>ContentSession</tt>.</li>
</ul></div>
<div class="section">
-<h4>Differences wrt Jackrabbit 2.x<a name="Differences_wrt_Jackrabbit_2.x"></a></h4>
-<p>See section <a href="authentication/differences.html">differences</a> for complete list of differences wrt authentication between Jackrabbit 2.x and Oak.</p></div>
-<div class="section">
-<h4>Guest Login<a name="Guest_Login"></a></h4>
-<p>The proper way to obtain an guest session as of Oak is as specified by JSR 283:</p>
-
-<div class="source">
-<pre>String wspName = null;
-Session anonymous = repository.login(new GuestCredentials(), wspName);
-</pre></div>
-<p>As of Oak 1.0 <tt>Repository#login()</tt> and <tt>Repository#login(null, wspName)</tt> is no longer treated as guest login. This behavior of Jackrabbit-core is violating the specification, which defines that null-login should be used for those cases where the authentication process is handled outside of the repository (see <a href="authentication/preauthentication.html">Pre-Authentication</a>).</p>
-<p>Similarly, any special treatment that Jackrabbit core applied for the guest (anonymous) user has been omitted altogether from the default <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/user/LoginModuleImpl.html">LoginModuleImpl</a>. In the default setup the built-in anonymous user will be created without any password. Therefore explicitly uid/pw login using the anonymous userId will no longer work. This behavior is now consistent with the default login of any other user which doesn’t have a password set.</p>
-<div class="section">
-<h5>Guest Login Module<a name="Guest_Login_Module"></a></h5>
-<p>The aim of the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/GuestLoginModule.html">GuestLoginModule</a> implementation is to provide backwards compatibility with Jackrabbit 2.x with respect to the guest (anonymous) login: the <tt>GuestLoginModule</tt> can be added as <i>optional</i> entry to the chain of login modules in the JAAS (or corresponding OSGi) configuration.</p>
-<p>Example JAAS Configuration:</p>
-
-<div class="source">
-<pre>jackrabbit.oak {
- org.apache.jackrabbit.oak.spi.security.authentication.GuestLoginModule optional;
- org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required;
-};
-</pre></div>
-<p>The behavior of the <tt>GuestLoginModule</tt> is as follows:</p>
-<p><i>Phase 1: Login</i></p>
-
-<ul>
-
-<li>tries to retrieve JCR credentials from the [CallbackHandler] using the [CredentialsCallback]</li>
-
-<li>in case no credentials could be obtained it pushes a new instance of [GuestCredentials] to the shared stated and <b>returns</b> <tt>true</tt></li>
-
-<li>otherwise it <b>returns</b> <tt>false</tt></li>
-</ul>
-<p><i>Phase 2: Commit</i></p>
-
-<ul>
-
-<li>if the phase 1 succeeded it will add the <tt>GuestCredentials</tt> created above and <tt>EveryonePrincipal</tt> the <tt>Subject</tt> in phase 2 of the login process and <b>returns</b> <tt>true</tt></li>
-
-<li>otherwise it <b>returns</b> <tt>false</tt></li>
-</ul></div></div>
-<div class="section">
-<h4>UserId/Password Login<a name="UserIdPassword_Login"></a></h4>
-<p>Oak 1.0 comes with 2 different login module implementations that can handle <tt>SimpleCredentials</tt>:</p>
-
-<ul>
-
-<li>Default (<tt>LoginModuleImpl</tt>) as described below</li>
-
-<li><tt>ExternalLoginModule</tt> as described in section <a href="authentication/externalloginmodule.html">External Authentication</a></li>
-</ul>
-<div class="section">
-<h5>Default Login Module<a name="Default_Login_Module"></a></h5>
-<p>The <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/user/LoginModuleImpl.html">LoginModuleImpl</a> defines a regular userId/password login and requires a repository setup that supports <a href="user.html">User Management</a> and is designed to supports the following <tt>Credentials</tt>:</p>
-
-<ul>
-
-<li><tt>SimpleCredentials</tt></li>
-
-<li><tt>GuestCredentials</tt> (see above)</li>
-
-<li><tt>ImpersonationCredentials</tt> (see below)</li>
-</ul>
-<p>This login module implementations behaves as follows:</p>
-<p><i>Phase 1: Login</i></p>
-
-<ul>
-
-<li>if a user does not exist in the repository (i.e. cannot be provided by the user manager) it <b>returns <tt>false</tt></b>.</li>
-
-<li>if an authorizable with the respective userId exists but is a group or a disabled users, it <b>throws <tt>LoginException</tt></b></li>
-
-<li>if a user exists in the repository and the credentials don’t match, it <b>throws <tt>LoginException</tt></b></li>
-
-<li>if a user exists in the repository and the credentials match, it <b>returns <tt>true</tt></b>
-
-<ul>
-
-<li>also, it adds the credentials to the shared state</li>
-
-<li>also, it adds the login name to the shared state</li>
-
-<li>also, it calculates the principals and adds them to the private state</li>
-
-<li>also, it adds the credentials to the private state</li>
- </ul></li>
-</ul>
-<p><i>Phase 2: Commit</i></p>
-
-<ul>
-
-<li>if the private state contains the credentials and principals, it adds them (both) to the subject and <b>returns <tt>true</tt></b></li>
-
-<li>if the private state does not contain credentials and principals, it clears the state and <b>returns <tt>false</tt></b></li>
-</ul></div></div>
-<div class="section">
-<h4>Impersonation<a name="Impersonation"></a></h4>
-<p>Another flavor of the Oak authentication implementation is covered by <tt>javax.jcr.Session#impersonate(Credentials)</tt>, which allows to obtain an new <tt>Session</tt> for user identified by the specified credentials. As of JSR 333 this method can also be used in order to clone the existing session (i.e. self-impersonation of the user that holds the session.</p>
-<p>With Oak 1.0 impersonation is implemented as follows:</p>
-
-<ol style="list-style-type: decimal">
-
-<li><tt>Session#impersonate</tt> takes any kind of <tt>Credentials</tt></li>
-
-<li>the specified credentials are wrapped in a new instance of <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/ImpersonationCredentials.html">ImpersonationCredentials</a> along with the current <tt>AuthInfo</tt> object.</li>
-
-<li>these <tt>ImpersonationCredentials</tt> are passed to <tt>Repository.login</tt></li>
-</ol>
-<p>Whether or not impersonation succeeds consequently both depends on the authentication setup and on some implementation specific validation that make sure the editing session is allowed to impersonate the user identified by the credentials passed to the impersonate call.</p>
-<p>With Oak 1.0 only the default login module (<a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/user/LoginModuleImpl.html">LoginModuleImpl</a>) is able to deal with <tt>ImpersonationCredentials</tt> and applies the following logic:</p>
-
-<ul>
-
-<li><b>Self-Impersonation</b>: Any attempt to impersonate the same session will succeed as long as the user is still valid (i.e. exists and has not been disabled).</li>
-
-<li><b>Regular Impersonation</b>: Impersonation another user will only succeed if the impersonated user is valid (i.e. exists and is not disabled) <i>and</i> the the user associated with the editing session is allowed to impersonate this user. The latter depends on the <a href="user.html">User Management</a> implementation specifically on the return value of <tt>User.getImpersonation().allows(Subject subject)</tt>.</li>
-</ul>
-<div class="section">
-<h5>ImpersonationCredentials<a name="ImpersonationCredentials"></a></h5>
-<p>Since the implementation of <tt>Session.impersonate</tt> no longer uses <tt>SimpleCredentials</tt> to transport the original <tt>Subject</tt> but rather performs the login with dedicated <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/ImpersonationCredentials.html">ImpersonationCredentials</a>, impersonation is no longer restricted to <tt>SimpleCredentials</tt> being passed to <tt>Session#impersonate</tt> call. Instead the specified credentials are passed to a new instance of <tt>ImpersonationCredentials</tt> delegating the evaluation and validation of the specified <tt>Credentials</tt> to the configured login module(s).</p>
-<p>This modification will not affect applications that used JCR API to impersonate a given session. Note however that applications relying on the Jackrabbit implementation and manually creating <tt>SimpleCredentials</tt> with a <tt>SecurityConstants.IMPERSONATOR_ATTRIBUTE</tt>, would need to be refactor after migration to Oak.</p></div>
-<div class="section">
-<h5>Impersonation with Custom Authentication Setup<a name="Impersonation_with_Custom_Authentication_Setup"></a></h5>
-<p>Applications that wish to use a custom authentication setup need to ensure the following steps in order to get JCR impersonation working:</p>
-
-<ul>
-
-<li>Respect <tt>ImpersonationCredentials</tt> in the authentication setup.</li>
-
-<li>Identify the impersonated from <tt>ImpersonationCredentials.getBaseCredentials</tt> and verify if it can be authenticated.</li>
-
-<li>Validate that the editing session is allowed to impersonate: The user associated with the editing session can be identified by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/api/AuthInfo.html">AuthInfo</a> obtained from from <tt>ImpersonationCredentials.getImpersonatorInfo()</tt>.</li>
-</ul></div></div>
-<div class="section">
-<h4>Token Login<a name="Token_Login"></a></h4>
-<p>See section <a href="authentication/tokenmanagement.html">Token Authentication</a> for details regarding token based authentication.</p>
-<div class="section">
-<h5>Token Login Module<a name="Token_Login_Module"></a></h5>
-<p>The <tt>TokenLoginModule</tt> is in charge of creating new login tokens and validate repository logins with <tt>TokenCredentials</tt>. The exact behavior of this login module is described in section <a href="authentication/tokenmanagement.html">Token Authentication</a>.</p></div></div>
-<div class="section">
-<h4>Pre-Authenticated Login<a name="Pre-Authenticated_Login"></a></h4>
-<p>Oak provides two different mechanisms to create pre-authentication that doesn’t involve the repositories internal authentication mechanism for credentials validation.</p>
-
-<ul>
-
-<li>Pre-Authentication combined with Login Module Chain</li>
-
-<li>Pre-Authentication without Repository Involvement (aka <tt>null</tt> login)</li>
-</ul>
-<p>See section <a href="authentication/preauthentication.html">Pre-Authentication Login</a> for further details and examples.</p></div>
-<div class="section">
-<h4>External Login<a name="External_Login"></a></h4>
-<p>While the default setup in Oak is solely relying on repository functionality to ensure proper authentication it quite common to authenticate against different systems (e.g. LDAP). For those setups that wish to combine initial authentication against a third party system with repository functionality, Oak provides a default implementation with extension points:</p>
-
-<ul>
-
-<li><a href="authentication/externalloginmodule.html">External Authentication</a>: Summary of the external authentication and details about the <tt>ExternalLoginModule</tt>.</li>
-
-<li><a href="authentication/usersync.html">User and Group Synchronization</a>: Details regarding user and group synchronization as well as a list of configuration options provided by the the default implementations present with Oak.</li>
-
-<li><a href="authentication/identitymanagement.html">Identity Management</a>: Further information regarding extenal identity management.</li>
-
-<li><a href="authentication/ldap.html">LDAP Integration</a>: How to make use of the <tt>ExternalLoginModule</tt> with the LDAP identity provider implementation. This combination is aimed to replace <a class="externalLink" href="http://dev.day.com/docs/en/crx/current/administering/ldap_authentication.html">com.day.crx.security.ldap.LDAPLoginModule</a>, which relies on Jackrabbit internals and will no longer work with Oak.</li>
-</ul>
-<div class="section">
-<h5>External Login Module<a name="External_Login_Module"></a></h5>
-<p>The external login module is a base implementation that allows easy integration of 3rd party authentication and identity systems, such as <a href="ldap.html">LDAP</a>. The general mode of the external login module is to use the external system as authentication source and as a provider for users and groups that may also be synchronized into the repository.</p>
-<p>This login module implementation requires an valid <tt>SyncHandler</tt> and <tt>IdentityProvider</tt> to be present. The detailed behavior of the <tt>ExternalLoginModule</tt> is described in section <a href="authentication/externalloginmodule.html">External Authentication</a>.</p></div></div></div>
+<h3>Oak Authentication Implementation<a name="Oak_Authentication_Implementation"></a></h3>
+<p>A description of the various requirements covered by Oak by default as well as the characteristics of the corresponding implementations can be found in section [Authentication: Implementation Details].</p>
+<p>See section <a href="authentication/differences.html">differences</a> for comprehensive list of differences wrt authentication between Jackrabbit 2.x and Oak.</p>
+<p><a name="api_extensions"></a></p></div>
<div class="section">
<h3>API Extension<a name="API_Extension"></a></h3>
<div class="section">
@@ -779,15 +614,15 @@ Session anonymous = repository.login(new
<li><tt>Authentication</tt>: Aimed to validate credentials during the first phase of the (JAAS) login process.</li>
</ul>
-<p>In addition this package contains various utilities and base implementations. Most notably an abstract login module implementation ([AbstractLoginModule]) as described below and a default implementation of the AuthInfo interface (<a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthInfoImpl.html">AuthInfoImpl</a>).</p>
+<p>In addition this package contains various utilities and base implementations. Most notably an abstract login module implementation (<a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.html">AbstractLoginModule</a>) as described below and a default implementation of the AuthInfo interface (<a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthInfoImpl.html">AuthInfoImpl</a>).</p>
<div class="section">
<h5>Abstract Login Module<a name="Abstract_Login_Module"></a></h5>
-<p>This package also contains a abstract <tt>LoginModule</tt> implementation ([AbstractLoginModule]) providing common functionality. In particular it contains Oak specific methods that allow subclasses to retrieve the <tt>SecurityProvider</tt>, a <tt>Root</tt> and accesss to various security related interfaces (e.g. <tt>PrincipalManager</tt>).</p>
+<p>This package also contains a abstract <tt>LoginModule</tt> implementation (<a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.html">AbstractLoginModule</a>) providing common functionality. In particular it contains Oak specific methods that allow subclasses to retrieve the <tt>SecurityProvider</tt>, a <tt>Root</tt> and accesss to various security related interfaces (e.g. <tt>PrincipalManager</tt>).</p>
<p>Subclasses are required to implement the following methods:</p>
<ul>
-<li>`getSupportedCredentials(): return a set of supported credential classes.</li>
+<li><tt>getSupportedCredentials()</tt>: return a set of supported credential classes.</li>
<li><tt>login()</tt>: The login method defined by <tt>LoginModule</tt></li>
@@ -837,56 +672,8 @@ Session anonymous = repository.login(new
return false;
}
}
-</pre></div></div></div></div>
-<div class="section">
-<h4>Token Management<a name="Token_Management"></a></h4>
-<p>See section <a href="authentication/tokenmanagement.html">token management</a> for details.</p>
-
-<ul>
-
-<li><tt>TokenConfiguration</tt>: Interface to obtain a <tt>TokenProvider</tt> instance.</li>
-
-<li><tt>TokenProvider</tt>: Interface to manage login tokens.</li>
-
-<li><tt>TokenInfo</tt>: Information related to a login token and token validity.</li>
-</ul></div>
-<div class="section">
-<h4>User and Group Synchronization<a name="User_and_Group_Synchronization"></a></h4>
-<p>See section <a href="authentication/usersync.html">Synchronization</a> for details.</p>
-
-<ul>
-
-<li><tt>SyncManager</tt>: factory for the <tt>SyncHandler</tt></li>
-
-<li><tt>SyncHandler</tt>: responsible for synchronizing users/groups from an <tt>ExternalIdentityProvider</tt> into the repository.</li>
-
-<li><tt>SyncContext</tt>: executes the synchronization</li>
-
-<li><tt>SyncedIdentity</tt>: represents a synchronized identity</li>
-
-<li><tt>SyncResult</tt>: the result of a sync operation</li>
-</ul></div>
-<div class="section">
-<h4>External Identity Management<a name="External_Identity_Management"></a></h4>
-<p>Oak in addition provides interfaces to ease custom implementation of the external authentication with optional user/group synchronization to the repository. See section <a href="authentication/identitymanagement.html">identity management</a> for details.</p>
-
-<ul>
-
-<li><tt>ExternalIdentityProviderManager</tt>: factory for the <tt>ExternalIdentityProvider</tt></li>
-
-<li><tt>ExternalIdentityProvider</tt>: provides user/group information from a third party system.</li>
-
-<li><tt>ExternalIdentity</tt>: base interface for an external user/group
-
-<ul>
-
-<li><tt>ExternalUser</tt></li>
-
-<li><tt>ExternalGroup</tt></li>
- </ul></li>
-
-<li><tt>ExternalIdentityRef</tt>: reference to an external user/group</li>
-</ul></div></div>
+</pre></div>
+<p><a name="configuration"></a></p></div></div></div></div>
<div class="section">
<h3>Configuration<a name="Configuration"></a></h3>
<p>The configuration of the authentication setup is defined by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/AuthenticationConfiguration.html">AuthenticationConfiguration</a>. This interface provides the following method:</p>
@@ -909,11 +696,12 @@ Session anonymous = repository.login(new
<li><tt>GuestLoginModule</tt>: null login falls back to anonymous</li>
-<li><tt>TokenLoginModule</tt>: covers token base authentication</li>
+<li><tt>TokenLoginModule</tt>: covers token based authentication</li>
<li><tt>LoginModuleImpl</tt>: covering regular uid/pw login</li>
</ul></li>
-</ul></div></div>
+</ul>
+<p><a name="pluggability"></a></p></div></div>
<div class="section">
<h3>Pluggability<a name="Pluggability"></a></h3>
<p>The default security setup as present with Oak 1.0 is able to provide custom implementation on various levels:</p>
@@ -923,14 +711,15 @@ Session anonymous = repository.login(new
<li>The complete authentication setup can be changed by plugging a different <tt>AuthenticationConfiguration</tt> implementations. In OSGi-base setup this is achieved by making the configuration a service. In a non-OSGi-base setup the custom configuration must be exposed by the <tt>SecurityProvider</tt> implementation.</li>
<li>Within the default authentication setup you replace or extend the set of login modules and their individual settings. In an OSGi-base setup is achieved by making the modules accessible to the framework and setting their execution order accordingly. In a Non-OSGi setup this is specified in the <a class="externalLink" href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html">JAAS config</a>.</li>
-
-<li>The <tt>LoginModuleImpl</tt> uses <tt>UserAuthentication</tt>-implementations for performing the authentication process. Which user-authentication implementation to use is determined by the available <tt>UserAuthenticationFactory</tt>s which provide user- authentication implementations if a given <tt>UserConfiguration</tt> is accepted. Which user-authentication-factory is chosen depends on its OSGi service ranking property. The default factory has a ranking of 0 (OSGi default). Services with the highest ranking take precedence.</li>
-</ol></div>
+</ol>
+<p><a name="further_reading"></a></p></div>
<div class="section">
<h3>Further Reading<a name="Further_Reading"></a></h3>
<ul>
+<li><a href="authentication/default.html">Authentication: Implementation Details</a></li>
+
<li><a href="authentication/differences.html">Differences wrt Jackrabbit 2.x</a></li>
<li><a href="authentication/tokenmanagement.html">Token Authentication and Token Management</a></li>