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 [18/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/authentication/token/default.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authentication/token/default.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authentication/token/default.html (original)
+++ jackrabbit/site/live/oak/docs/security/authentication/token/default.html Mon Jul 9 08:53:17 2018
@@ -1,13 +1,13 @@
<!DOCTYPE html>
<!--
- | Generated by Apache Maven Doxia Site Renderer 1.7.4 at 2018-05-24
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 at 2018-07-09
| Rendered using Apache Maven Fluido Skin 1.6
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
- <meta name="Date-Revision-yyyymmdd" content="20180524" />
+ <meta name="Date-Revision-yyyymmdd" content="20180709" />
<meta http-equiv="Content-Language" content="en" />
<title>Jackrabbit Oak – Token Management : The Default Implementation</title>
<link rel="stylesheet" href="../../../css/apache-maven-fluido-1.6.min.css" />
@@ -136,7 +136,7 @@
<div id="breadcrumbs">
<ul class="breadcrumb">
- <li id="publishDate">Last Published: 2018-05-24<span class="divider">|</span>
+ <li id="publishDate">Last Published: 2018-07-09<span class="divider">|</span>
</li>
<li id="projectVersion">Version: 1.10-SNAPSHOT</li>
</ul>
@@ -240,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="Token_Management_:_The_Default_Implementation"></a>Token Management : The Default Implementation</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
@@ -252,15 +253,17 @@
<p>The creation of a new token is triggered by valid and supported <tt>Credentials</tt> passed to the login module chain that contain an additional, empty <tt>.token</tt> attribute.</p>
<p>The <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/token/TokenLoginModule.html">TokenLoginModule</a> will obtain these <tt>Credentials</tt> from the shared state during the commit phase (i.e. phase 2 of the JAAS authentication) and will pass them to the configured <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/TokenProvider.html">TokenProvider</a> implementation the following sequence:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">Credentials shared = getSharedCredentials();
+<div>
+<div>
+<pre class="source">Credentials shared = getSharedCredentials();
if (shared != null && tokenProvider.doCreateToken(shared)) {
[...]
TokenInfo ti = tokenProvider.createToken(shared);
[...]
}
</pre></div></div>
-<p>In case of success these steps will have generated a new token and stored it’s hash along with all mandatory and informative attributes to the new content node representing the token.</p>
+
+<p>In case of success these steps will have generated a new token and stored it’s hash along with all mandatory and informative attributes to the new content node representing the token.</p>
<div class="section">
<h5><a name="Supported_Credentials_for_Token_Creation"></a>Supported Credentials for Token Creation</h5>
<p>By default the implementation deals with shared <tt>SimpleCredentials</tt>.</p>
@@ -270,11 +273,9 @@ if (shared != null && tokenProvi
<h4><a name="Token_Validation"></a>Token Validation</h4>
<p>Once a token has been created it can be used for subsequent repository logins with <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/authentication/token/TokenCredentials.java">TokenCredentials</a>. This time the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/token/TokenLoginModule.html">TokenLoginModule</a> will attempt to perform the login phase (i.e. phase 1 of the JAAS authentication).</p>
<p>This includes resolving the login token (<tt>TokenProvider.getTokenInfo</tt>) and asserting it’s validity in case it exists. The validation consists of following steps:</p>
-
<ul>
-
+
<li>check that the token has not expired (<tt>TokenInfo.isExpired</tt>)</li>
-
<li>verify that all mandatory attributes are present and match the expectations (<tt>TokenInfo.matches</tt>)</li>
</ul>
<p>Only if these steps have been successfully completed the login of the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/token/TokenLoginModule.html">TokenLoginModule</a> will succeed.</p></div>
@@ -284,21 +285,21 @@ if (shared != null && tokenProvi
<div class="section">
<h4><a name="Resetting_Expiration_Time"></a>Resetting Expiration Time</h4>
<p>The default <tt>TokenProvider</tt> implementation will automatically reset the expiration time of a given token upon successful authentication.</p>
-<p>This behavior can be disabled by setting the <tt>tokenRefresh</tt> configuration parameter to <tt>false</tt> (see <tt>PARAM_TOKEN_REFRESH</tt> below). In this case expiration time will not be reset and an attempt to do so using the API (e.g. calling <tt>
-TokenInfo.resetExpiration(long loginTime)</tt>) will return <tt>false</tt> indicating that the expiration time has not been reset. The token will consequently expire and the user will need to login again using the configured login mechanism (e.g. using the credentials support for token creation).</p></div>
+<p>This behavior can be disabled by setting the <tt>tokenRefresh</tt> configuration parameter to <tt>false</tt> (see <tt>PARAM_TOKEN_REFRESH</tt> below). In this case expiration time will not be reset and an attempt to do so using the API (e.g. calling <tt>TokenInfo.resetExpiration(long loginTime)</tt>) will return <tt>false</tt> indicating that the expiration time has not been reset. The token will consequently expire and the user will need to login again using the configured login mechanism (e.g. using the credentials support for token creation).</p></div>
<div class="section">
<h4><a name="Token_Cleanup"></a>Token Cleanup</h4>
<p>Automatic token cleanup can be enabled by setting the <tt>tokenCleanupThreshold</tt> parameter to a value larger than <tt>0</tt> (<tt>0</tt> means disabled). This will trigger a cleanup call if the number of tokens under a user exceeds this value. (As an implementation detail a throttling method was introduced to only allow the call to go through 1/8 times).</p>
<p>This is available with Oak 1.7.12 on, see also [OAK-6818]for additional information.</p>
-<p><a name="representation"></a></p></div></div>
-<div class="section">
-<h3><a name="Representation_in_the_Repository"></a>Representation in the Repository</h3>
+<a name="representation"></a>
+### Representation in the Repository
+</div>
<div class="section">
<h4><a name="Content_Structure"></a>Content Structure</h4>
<p>The login tokens issued for a given user are all located underneath a node named <tt>.tokens</tt> that will be created by the <tt>TokenProvider</tt> once the first token is created. The default implementation creates a distinct node for each login token as described below</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">testUser {
+<div>
+<div>
+<pre class="source">testUser {
"jcr:primaryType": "rep:User",
...
".tokens" {
@@ -316,32 +317,33 @@ TokenInfo.resetExpiration(long loginTime
}
}
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h4><a name="Token_Nodes"></a>Token Nodes</h4>
<p>As of Oak 1.0 the login token are represented in the repository as follows:</p>
-
<ul>
-
+
<li>the token node is referenceable with the dedicated node type <tt>rep:Token</tt> (used to be unstructured in Jackrabbit 2.x)</li>
-
<li>expiration and key properties are defined to be mandatory and protected</li>
-
-<li>expiration time is obtained from <tt>PARAM_TOKEN_EXPIRATION</tt> specified in the login attributes and falls back to the configuration parameter with the same name as specified in the configuration options of the <tt>TokenConfiguration</tt>.</li>
+<li>expiration time is obtained from <tt>PARAM_TOKEN_EXPIRATION</tt> specified in the login attributes and falls back to the configuration parameter with the same name as specified in the configuration options of the <tt>TokenConfiguration</tt>.</li>
</ul>
<p>The definition of the new built-in node type <tt>rep:Token</tt>:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">[rep:Token] > mix:referenceable
+<div>
+<div>
+<pre class="source">[rep:Token] > mix:referenceable
- rep:token.key (STRING) protected mandatory
- rep:token.exp (DATE) protected mandatory
- * (UNDEFINED) protected
- * (UNDEFINED) multiple protected
</pre></div></div>
+
<p>The following example illustrates the token nodes resulting from this node type definition:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">testUser {
+<div>
+<div>
+<pre class="source">testUser {
"jcr:primaryType": "rep:User",
...
".tokens" {
@@ -366,210 +368,119 @@ TokenInfo.resetExpiration(long loginTime
}
}
</pre></div></div>
-<p><a name="validation"></a></p></div></div>
-<div class="section">
-<h3><a name="Validation"></a>Validation</h3>
-<p>The consistency of this content structure both on creation and modification is asserted by a dedicated <tt>TokenValidator</tt>. The corresponding errors are all of type <tt>Constraint</tt> with the following codes:</p>
+<a name="validation"></a>
+### Validation
+<p>The consistency of this content structure both on creation and modification is asserted by a dedicated <tt>TokenValidator</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>0060 </td>
-
-<td>Attempt to create reserved token property in other ctx </td>
- </tr>
-
+<td> 0060 </td>
+<td> Attempt to create reserved token property in other ctx </td></tr>
<tr class="a">
-
-<td>0061 </td>
-
-<td>Attempt to change existing token key </td>
- </tr>
-
+<td> 0061 </td>
+<td> Attempt to change existing token key </td></tr>
<tr class="b">
-
-<td>0062 </td>
-
-<td>Change primary type of existing node to rep:Token </td>
- </tr>
-
+<td> 0062 </td>
+<td> Change primary type of existing node to rep:Token </td></tr>
<tr class="a">
-
-<td>0063 </td>
-
-<td>Creation/Manipulation of tokens without using provider </td>
- </tr>
-
+<td> 0063 </td>
+<td> Creation/Manipulation of tokens without using provider </td></tr>
<tr class="b">
-
-<td>0064 </td>
-
-<td>Create a token outside of configured scope </td>
- </tr>
-
+<td> 0064 </td>
+<td> Create a token outside of configured scope </td></tr>
<tr class="a">
-
-<td>0065 </td>
-
-<td>Invalid location of token node </td>
- </tr>
-
+<td> 0065 </td>
+<td> Invalid location of token node </td></tr>
<tr class="b">
-
-<td>0066 </td>
-
-<td>Invalid token key </td>
- </tr>
-
+<td> 0066 </td>
+<td> Invalid token key </td></tr>
<tr class="a">
-
-<td>0067 </td>
-
-<td>Mandatory token expiration missing </td>
- </tr>
-
+<td> 0067 </td>
+<td> Mandatory token expiration missing </td></tr>
<tr class="b">
-
-<td>0068 </td>
-
-<td>Invalid location of .tokens node </td>
- </tr>
-
+<td> 0068 </td>
+<td> Invalid location of .tokens node </td></tr>
<tr class="a">
-
-<td>0069 </td>
-
-<td>Change type of .tokens parent node </td>
- </tr>
- </tbody>
+<td> 0069 </td>
+<td> Change type of .tokens parent node </td></tr>
+</tbody>
</table>
-<p><a name="configuration"></a></p></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
-<p>The default Oak <tt>TokenConfiguration</tt> allows to define the following configuration options for the <tt>TokenProvider</tt>:</p>
+<a name="configuration"></a>
+### Configuration
+
+<p>The default Oak <tt>TokenConfiguration</tt> allows to define the following configuration options for the <tt>TokenProvider</tt>:</p></div>
<div class="section">
<h4><a name="Configuration_Parameters"></a>Configuration Parameters</h4>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td>PARAM_TOKEN_EXPIRATION </td>
-
-<td>long </td>
-
-<td>2 * 3600 * 1000 (2 hours)</td>
- </tr>
-
-<tr class="a">
-
-<td>PARAM_TOKEN_LENGTH </td>
-
-<td>int </td>
-
-<td>8 </td>
- </tr>
-
+<td> PARAM_TOKEN_EXPIRATION </td>
+<td> long </td>
+<td> 2 * 3600 * 1000 (2 hours)</td></tr>
+<tr class="a">
+<td> PARAM_TOKEN_LENGTH </td>
+<td> int </td>
+<td> 8 </td></tr>
<tr class="b">
-
-<td>PARAM_TOKEN_REFRESH </td>
-
-<td>boolean </td>
-
-<td>true </td>
- </tr>
-
-<tr class="a">
-
-<td>PARAM_PASSWORD_HASH_ALGORITHM </td>
-
-<td>String </td>
-
-<td>SHA-256 </td>
- </tr>
-
+<td> PARAM_TOKEN_REFRESH </td>
+<td> boolean </td>
+<td> true </td></tr>
+<tr class="a">
+<td> PARAM_PASSWORD_HASH_ALGORITHM </td>
+<td> String </td>
+<td> SHA-256 </td></tr>
<tr class="b">
-
-<td>PARAM_PASSWORD_HASH_ITERATIONS </td>
-
-<td>int </td>
-
-<td>1000 </td>
- </tr>
-
-<tr class="a">
-
-<td>PARAM_PASSWORD_SALT_SIZE </td>
-
-<td>int </td>
-
-<td>8 </td>
- </tr>
-
+<td> PARAM_PASSWORD_HASH_ITERATIONS </td>
+<td> int </td>
+<td> 1000 </td></tr>
+<tr class="a">
+<td> PARAM_PASSWORD_SALT_SIZE </td>
+<td> int </td>
+<td> 8 </td></tr>
<tr class="b">
-
-<td>PARAM_TOKEN_CLEANUP_THRESHOLD </td>
-
-<td>long </td>
-
-<td>0 (no cleanup) </td>
- </tr>
-
+<td> PARAM_TOKEN_CLEANUP_THRESHOLD </td>
+<td> long </td>
+<td> 0 (no cleanup) </td></tr>
<tr class="a">
-
-<td> </td>
-
<td> </td>
-
<td> </td>
- </tr>
- </tbody>
+<td> </td></tr>
+</tbody>
</table>
-<p><a name="pluggability"></a></p></div></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
+<a name="pluggability"></a>
+### Pluggability
+
<p>In an OSGi-based setup the default <tt>TokenConfiguration</tt> you can bind a custom implementation of the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/credentials/CredentialsSupport.html">CredentialsSupport</a> interface. Doing so allows to support any type of custom credentials, which do not reveal the ID of the user logging into repository.</p>
<p>In particular when chaining the <tt>TokenLoginModule</tt> and the <tt>ExternalLoginModule</tt> the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/credentials/CredentialsSupport.html">CredentialsSupport</a> can be used to authenticate and synchronize users provided by third party systems during phase 1 (login) and generate a login token during phase 2 (commit). See section <a href="../externalloginmodule.html">Authentication with the External Login Module</a> for additional details. For this to work the same <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/credentials/CredentialsSupport.html">CredentialsSupport</a> must be configured with the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/ExternalIdentityProvider.html">ExternalIdentityProvider</a> and the <tt>TokenConfiguration</tt> and <tt>CredentialsSupport.getUserId</tt> must reveal the ID of the synced user (i.e. <tt>Ex
ternalUser.getId</tt>).</p>
<p>In general the following steps are required in order to plug a different <tt>CredentialsSupport</tt> into the default <tt>TokenConfiguration</tt>:</p>
-
<ul>
-
+
<li>implement the <tt>CredentialsSupport</tt> interface (e.g. as extension to the <tt>ExternalIdentityProvider</tt>)</li>
-
<li>make sure the implementation is an OSGi service and deploy it 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="Example_CredentialsSupport"></a>Example CredentialsSupport</h6>
<p>In an OSGi-based setup it’s sufficient to make the service available to the repository in order to enable a custom <tt>CredentialsSupport</tt>.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">@Component
+<div>
+<div>
+<pre class="source">@Component
@Service(value = {CredentialsSupport.class})
/**
* Custom implementation of the {@code CredentialsSupport} interface.
@@ -605,14 +516,14 @@ final class MyCredentialsSupport impleme
// TODO: optional implementation
return false;
}
-
+
[...]
}
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h6><a name="Example_CredentialsSupport_in_Combination_with_External_Authentication"></a>Example CredentialsSupport in Combination with External Authentication</h6>
-<p>See section <a href="../externalloginmodule.html#pluggability">Authentication with the External Login Module</a> for an example.</p>
-<!-- references --></div></div></div></div></div>
+<p>See section <a href="../externalloginmodule.html#pluggability">Authentication with the External Login Module</a> for an example.</p><!-- references --></div></div></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/authentication/tokenmanagement.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authentication/tokenmanagement.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authentication/tokenmanagement.html (original)
+++ jackrabbit/site/live/oak/docs/security/authentication/tokenmanagement.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 – Token Authentication and Token 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,18 +240,16 @@
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="Token_Authentication_and_Token_Management"></a>Token Authentication and Token Management</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
<p>The token based authentication has been completely refactor in Oak and has the following general characteristics.</p>
-
<ul>
-
+
<li>Dedicated API for managing login tokens defined in the package <tt>org.apache.jackrabbit.oak.spi.security.authentication.token</tt>.</li>
-
<li>Pluggable configuration of the new token management API</li>
-
<li>Complete separation of token based authentication into a separate <tt>LoginModule</tt>.</li>
</ul></div>
<div class="section">
@@ -262,80 +260,66 @@
<h4><a name="TokenLoginModule"></a>TokenLoginModule</h4>
<p>The <tt>TokenLoginModule</tt>designed to support and issue <tt>TokenCredentials</tt>. The authentication phases behave as follows:</p>
<p><i>Phase 1: Login</i></p>
-
<ul>
-
+
<li>if no <tt>TokenProvider</tt> is available <b>returns <tt>false</tt></b></li>
-
<li>if a <tt>TokenProvider</tt> has been configured it retrieves JCR credentials from the [CallbackHandler] using the [CredentialsCallback]</li>
-
-<li>in case of <tt>TokenCredentials</tt> validates these credentials: if it succeeds it pushes the users ID to the shared state and returns <tt>true</tt>; otherwise throws <tt>LoginException</tt></li>
-
+<li>in case of <tt>TokenCredentials</tt> validates these credentials: if it succeeds it pushes the users ID to the shared state and returns <tt>true</tt>; otherwise throws <tt>LoginException</tt></li>
<li>for other credentials the method returns <tt>false</tt></li>
</ul>
<p><i>Phase 1: Commit</i></p>
-
<ul>
-
+
<li>if phase 1 succeeded the subject is populated and the method returns <tt>true</tt></li>
-
-<li>in case phase 1 did not succeed this method will test if the shared state contain credentials that ask for a new token being created; if this succeeds it will create a new instance of <tt>TokenCredentials</tt>, push the public attributes to the shared stated and update the subject with the new credentials; finally the commit call <b>returns <tt>false</tt></b></li>
+<li>in case phase 1 did not succeed this method will test if the shared state contain credentials that ask for a new token being created; if this succeeds it will create a new instance of <tt>TokenCredentials</tt>, push the public attributes to the shared stated and update the subject with the new credentials; finally the commit call <b>returns <tt>false</tt></b></li>
</ul>
<div class="section">
<h5><a name="Example_JAAS_Configuration"></a>Example JAAS Configuration</h5>
-<p>jackrabbit.oak { org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule sufficient; org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required; };</p>
-<p><a name="api_extensions"></a></p></div></div></div>
-<div class="section">
-<h3><a name="Token_Management_API"></a>Token Management API</h3>
-<p>Oak 1.0 defines the following interfaces used to manage login tokens:</p>
+<p>jackrabbit.oak { org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule sufficient; org.apache.jackrabbit.oak.security.authentication.user.LoginModuleImpl required; };</p>
+<a name="api_extensions"></a>
+### Token Management API
+<p>Oak 1.0 defines the following interfaces used to manage login tokens:</p>
<ul>
-
+
<li>[TokenConfiguration]: Interface to obtain a <tt>TokenProvider</tt> instance (see section <a href="#configuration">configuration</a> below).</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/TokenProvider.html">TokenProvider</a>: Interface to read and manage login tokens.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/TokenInfo.html">TokenInfo</a>: Information associated with a given login token and token validity.</li>
</ul>
<p>In addition Oak comes with a default implementation of the provider interface that is able to aggregate multiple <tt>TokenProvider</tt>s:</p>
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/CompositeTokenConfiguration.html">CompositeTokenConfiguration</a>: Extension of the <tt>CompositeConfiguration</tt> to combined different token management implementations.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/token/CompositeTokenProvider.html">CompositeTokenProvider</a>: Aggregation of the <tt>TokenProvider</tt> implementations defined by the configurations contained the <tt>CompositeTokenConfiguration</tt></li>
</ul>
<p>See section <a href="#pluggability">Pluggability</a> for an example.</p>
-<p><a name="default_implementation"></a></p></div>
-<div class="section">
-<h3><a name="Characteristics_of_the_Default_Implementation"></a>Characteristics of the Default Implementation</h3>
-<p>The characteristics of the default token management implementation is described in section <a href="token/default.html">Token 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="default_implementation"></a>
+### Characteristics of the Default Implementation
+
+<p>The characteristics of the default token management implementation is described in section <a href="token/default.html">Token Management : The Default Implementation</a>.</p>
+<a name="configuration"></a>
+### Configuration
+
<p>The configuration options of the default implementation are described in the <a href="token/default.html#configuration">Configuration</a> section.</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 deal with custom token management implementations and will collect multiple implementations within <tt>CompositeTokenConfiguration</tt> present with the <tt>SecurityProvider</tt>. The <tt>CompositeTokenConfiguration</tt> itself will combine the different <tt>TokenProvider</tt> implementations using the <tt>CompositeTokenProvider</tt>.</p>
<p>In an OSGi setup the following steps are required in order to add a custom token provider implementation:</p>
-
<ul>
-
+
<li>implement <tt>TokenProvider</tt> interface</li>
-
<li>expose the custom provider by your custom <tt>TokenConfiguration</tt> service</li>
-
<li>make the configuration available to the Oak repository.</li>
-</ul>
-<div class="section">
+</ul></div>
<div class="section">
<h5><a name="Examples"></a>Examples</h5>
<div class="section">
<h6><a name="Example_TokenConfiguration"></a>Example TokenConfiguration</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">@Component()
+<div>
+<div>
+<pre class="source">@Component()
@Service({TokenConfiguration.class, SecurityConfiguration.class})
public class MyTokenConfiguration extends ConfigurationBase implements TokenConfiguration {
Modified: jackrabbit/site/live/oak/docs/security/authentication/usersync.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authentication/usersync.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authentication/usersync.html (original)
+++ jackrabbit/site/live/oak/docs/security/authentication/usersync.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 – User and Group Synchronization</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,76 +240,59 @@
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="User_and_Group_Synchronization"></a>User and Group Synchronization</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
<p>The synchronization of users and groups is triggered by the <a href="externalloginmodule.html">ExternalLoginModule</a>, after a user is successfully authenticated against the IDP or if it’s no longer present on the IDP.</p></div>
<div class="section">
<h3><a name="Synchronization_API"></a>Synchronization API</h3>
-
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncManager.html">SyncManager</a>: factory for all configured <tt>SyncHandler</tt> implementations.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncHandler.html">SyncHandler</a>: responsible for synchronizing users/groups from an <tt>ExternalIdentityProvider</tt> into the repository.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncContext.html">SyncContext</a>: executes the synchronization</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncedIdentity.html">SyncedIdentity</a>: represents a synchronized identity</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncResult.html">SyncResult</a>: the result of a sync operation</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncException.html">SyncException</a>: marker for sync related errors</li>
</ul>
<div class="section">
<h4><a name="JMX_Synchronization_Tool"></a>JMX Synchronization Tool</h4>
<p>In addition to the synchronization API Oak 1.0 defines utilities to manage synchronized external identities within JMX (<tt>SynchronizationMBean</tt>) which allows for the following tasks:</p>
-
<ul>
-
+
<li><tt>syncUsers(String[] userIds, boolean purge)</tt></li>
-
<li><tt>syncAllUsers(boolean purge)</tt></li>
-
<li><tt>syncExternalUsers(String[] externalIds)</tt></li>
-
<li><tt>syncAllExternalUsers()</tt></li>
-
<li><tt>listOrphanedUsers()</tt></li>
-
<li><tt>purgeOrphanedUsers()</tt></li>
</ul></div></div>
<div class="section">
<h3><a name="Default_Implementation"></a>Default Implementation</h3>
-<p>Oak 1.0 provides a default implementation of the user synchronization API that allow to plug additional <tt>SyncHandler</tt> implementations. </p>
+<p>Oak 1.0 provides a default implementation of the user synchronization API that allow to plug additional <tt>SyncHandler</tt> implementations.</p>
<p>Default implementation is described in section <a href="external/defaultusersync.html">User and Group Synchronization : The Default Implementation</a>.</p></div>
<div class="section">
<h3><a name="Pluggability"></a>Pluggability</h3>
<p>There are two ways to replace/change the user synchronization behavior</p>
-
<ol style="list-style-type: decimal">
-
+
<li>Write custom <tt>SyncManager</tt></li>
-
<li>Write custom <tt>SyncHandler</tt></li>
</ol>
<p>The following steps are required in order to replace the default <tt>SyncManager</tt> implementation or plug a new implementation of the <tt>SyncHandler</tt>:</p>
-
<ul>
-
+
<li>write your custom implementation of the interface</li>
-
<li>make the manager/handler available to the authentication setup or sync manager
-
<ul>
-
+
<li>OSGi setup: making the implementation an OSGi service</li>
-
<li>non-OSGi setup: configure the manager/handler during manual <a href="../../construct.html">Repository Construction</a>.</li>
- </ul></li>
</ul>
-<!-- references --></div></div>
+</li>
+</ul><!-- references --></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/authorization.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authorization.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authorization.html (original)
+++ jackrabbit/site/live/oak/docs/security/authorization.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 – Authorization</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,54 +240,47 @@
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="Authorization"></a>Authorization</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
<p>One of main goals for Oak security, was to clearly separates between access control management (such as defined by the JCR and Jackrabbit API) and the internal permission evaluation.</p>
<p>While access control management is defined to be an optional feature added in JCR 2.0, permission evaluation was mandated since the very first version of JCR even though it remained an implementation detail.</p>
<p>The documentation follows this separations and handles access control and permission evaluation separately:</p>
-
<ul>
-
+
<li><a href="accesscontrol.html">Access Control Management</a></li>
-
<li><a href="permission.html">Permissions</a></li>
</ul>
<p>Despite the fact that there is a distinction between the public facing access control management and the internal permission evaluation, these two topics remain connected to one another and a given authorization model is expected to define and handle both in a consistent manner. Consequently the main entry point for authorization related operations is a single <tt>AuthorizationConfiguration</tt> (see section <a href="#configuration">configuration</a> below).</p>
-<p><a name="api_extensions"></a></p></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
-<p>The API extensions provided by Oak are covered in the following sections:</p>
+<a name="api_extensions"></a>
+### API Extensions
+<p>The API extensions provided by Oak are covered in the following sections:</p>
<ul>
-
+
<li><a href="accesscontrol.html#api_extensions">Access Control Management</a></li>
-
<li><a href="permission.html#api_extensions">Permissions</a></li>
-
<li><a href="authorization/restriction.html#api_extensions">Restriction Management</a></li>
</ul>
-<p><a name="configuration"></a></p></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
-<p>The configuration of the authorization related parts is handled by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html">AuthorizationConfiguration</a>. This class provides the following methods:</p>
+<a name="configuration"></a>
+### Configuration
+<p>The configuration of the authorization related parts is handled by the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/AuthorizationConfiguration.html">AuthorizationConfiguration</a>. This class provides the following methods:</p>
<ul>
-
+
<li><tt>getAccessControlManager</tt>: get a new ac manager instance (see <a href="accesscontrol.html">Access Control Management</a>).</li>
-
<li><tt>getPermissionProvider</tt>: get a new permission provider instance (see <a href="permission.html">Permissions</a>).</li>
-
<li><tt>getRestrictionProvider</tt>: get a new instance of the restriction provider (see <a href="authorization/restriction.html">Restriction Management</a>.</li>
</ul>
<div class="section">
<h4><a name="Configuration_Parameters"></a>Configuration Parameters</h4>
<p>The supported configuration options of the default implementation are described separately for <a href="accesscontrol/default.html#configuration">access control management</a> and <a href="permission/default.html#configuration">permission evalution</a> .</p>
-<p><a name="pluggability"></a></p></div></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
-<p>There are multiple options for plugging authorization related custom implementations:</p>
+<a name="pluggability"></a>
+### Pluggability
+
+<p>There are multiple options for plugging authorization related custom implementations:</p></div>
<div class="section">
<h4><a name="Aggregation_of_Different_Authorization_Models"></a>Aggregation of Different Authorization Models</h4>
<div class="section">
@@ -297,26 +290,21 @@
<div class="section">
<h5><a name="Previous_Versions"></a>Previous Versions</h5>
<p>In previous versions of Oak aggregation of multiple authorization models was not supported and it was only possible to replace the existing <tt>AuthorizationConfiguration</tt>. This would completely replace the default way of handling authorization in the repository.</p>
-<p>In OSGi-base setup this is achieved by making the configuration implementation a service such that it takes precendece over the default. </p>
+<p>In OSGi-base setup this is achieved by making the configuration implementation a service such that it takes precendece over the default.</p>
<p>In a non-OSGi-base setup the custom configuration must be exposed by the <tt>SecurityProvider</tt> implementation.</p></div></div>
<div class="section">
<h4><a name="Extending_the_Restriction_Provider"></a>Extending the Restriction Provider</h4>
<p>In all versions of Oak it is possible to plug custom implementation(s) for the restriction management that allows to narrow the effect of permissions to items matching a given, defined behavior. Details can be found in section <a href="authorization/restriction.html#pluggability">RestrictionManagement</a>.</p>
-<p><a name="further_reading"></a></p></div></div>
-<div class="section">
-<h3><a name="Further_Reading"></a>Further Reading</h3>
+<a name="further_reading"></a>
+### Further Reading
<ul>
-
+
<li><a href="accesscontrol.html">Access Control Management</a></li>
-
<li><a href="permission.html">Permission Evalution</a></li>
-
<li><a href="authorization/restriction.html">Restriction Management</a></li>
-
<li><a href="authorization/composite.html">Combining Multiple Authorization Models</a></li>
-</ul>
-<!-- hidden references --></div></div>
+</ul><!-- hidden references --></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/authorization/composite.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authorization/composite.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authorization/composite.html (original)
+++ jackrabbit/site/live/oak/docs/security/authorization/composite.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 – Combining Multiple Authorization Models</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,22 +240,21 @@
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="Combining_Multiple_Authorization_Models"></a>Combining Multiple Authorization Models</h2>
<div class="section">
<h3><a name="General_Notes"></a>General Notes</h3>
<p>Since Oak 1.4 it is possible to combine multiple authorization models within the default security setup.</p>
<p>The main entry point for the aggregation of multiple authorization models is the <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/composite/CompositeAuthorizationConfiguration.java">CompositeAuthorizationConfiguration</a>, which is in charge of generating composite variants of the <tt>AccessControlManager</tt>, <tt>PermissionProvider</tt> and <tt>RestrictionProvider</tt> if multiple authorization modules have been configured (see section <a href="#details">Implementation Details</a> below.</p>
<p><i>Please note:</i> Despite the fact that Oak supports the aggregation of multiple authorization models, this extension is only recommended for experts that have in-depth knowledge and understanding of Jackrabbit/Oak authorization concepts. Doing so might otherwise result in severe security issues and heavily impact overall performance.</p>
-<p><a name="api_extensions"></a></p></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
-<p>There are two interfaces required to make a given authorization model deployable in an aggregated setup:</p>
+<a name="api_extensions"></a>
+### API Extensions
+<p>There are two interfaces required to make a given authorization model deployable in an aggregated setup:</p>
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/PolicyOwner.html">PolicyOwner</a>: Extension to the <tt>AccessControlManager</tt>, that allows a given implementation to claim responsibility for handling certain <tt>AccessControlPolicy</tt> implementations.</li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/permission/AggregatedPermissionProvider.html">AggregatedPermissionProvider</a>: Subclass of <tt>PermissionProvider</tt> which is mandated for permission evaluation once multiple providers are configured.</li>
</ul>
<div class="section">
@@ -267,21 +266,18 @@
<div class="section">
<h5><a name="Example"></a>Example</h5>
<p>The permission provider shipped with the <a href="cug.html#details">oak-authorization-cug</a> module has a very limited scope: it only evaluates read-access to regular items at the configured supported paths. This means e.g. that the implementation is not able to determine if write access is granted to a given set of <tt>Principal</tt>s and indicates this fact by just returning the subset of supported read permissions upon <tt>supportedPermissions(Tree, PropertyState, long)</tt>. The aggregated permission provider will consequently not consult this implementation for the evaluation of write permissions and move on to other providers in the aggregate.</p>
-<p><a name="details"></a></p></div></div></div>
-<div class="section">
-<h3><a name="Implementation_Details"></a>Implementation Details</h3>
+<a name="details"></a>
+### Implementation Details
+
<p>As soon as multiple authorization models are configured with the security setup, the <tt>CompositeAuthorizationConfiguration</tt> will return a dedicated <tt>JackrabbitAccessControlManager</tt> and <tt>PermissionProvider</tt> that are wrapping the objects provided by the aggregated implementations.</p>
-<p>Note: as long as a single authorization model is configured (default setup) the <tt>CompositeAuthorizationConfiguration</tt> will omit any extra wrapping.</p>
+<p>Note: as long as a single authorization model is configured (default setup) the <tt>CompositeAuthorizationConfiguration</tt> will omit any extra wrapping.</p></div></div>
<div class="section">
<h4><a name="Access_Control"></a>Access Control</h4>
<p>Once multiple modules are deployed a <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/composite/CompositeAccessControlManager.java">CompositeAccessControlManager</a> with the following characteristics will be returned:</p>
-
<ul>
-
+
<li>API calls reading information will return the combined result of the wrapped implementations.</li>
-
<li>Methods defined solely by <tt>JackrabbitAccessControlManager</tt> additionally test for the delegatees to implement that extension.</li>
-
<li>API calls writing back policies will look for the responsible <tt>PolicyOwner</tt> and specifically delegate the call. If no owner can be found an <tt>AccessControlException</tt> is thrown.</li>
</ul>
<p>Hence, a given authorization model is free to implement JCR <tt>AccessControlManager</tt> or the Jackrabbit extension.</p>
@@ -290,16 +286,12 @@
<h4><a name="Permission_Evaluation"></a>Permission Evaluation</h4>
<p>Only models implementing the <tt>AggregatedPermissionProvider</tt> extensions will be respected for aggregation into the <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/composite/CompositePermissionProvider.java">CompositePermissionProvider</a>. This allows individual models to cover only a subset of permissions and|or a subset of paths within the repository.</p>
<p>The composite wrapper subsequently applies the following logic to evaluate the effective permissions:</p>
-
<ul>
-
-<li>each delegatee is in ask to evaluate the subset of supported permissions if it claims responsible for the given item/path,</li>
-
+
+<li>each delegatee is in ask to evaluate the subset of supported permissions if it claims responsible for the given item/path,</li>
<li>a delegatee that doesn’t handle any of the permissions in question it is ignored,</li>
-
<li>a delegatee that doesn’t claim responsible for the item/path is ignored,</li>
-
-<li>a given set of permissions is ultimately granted for a given item/path, if <i>all</i> permissions have been successfully processed and none of the delegatees involved denied access.</li>
+<li>a given set of permissions is ultimately granted for a given item/path, if <i>all</i> permissions have been successfully processed and none of the delegatees involved denied access.</li>
</ul>
<p>This implies that evaluation of permissions across multiple implementations is strictly additive: as soon as one provider denies access (either by an explicit deny or by a missing explicit allow) permissions are denied.</p>
<p>Similarly, if a given combination of permission providers fails to process the complete set of permissions (e.g. one permission is not covered by any of the modules) the access will be denied as none of the provider was in charge of proper evaluation.</p>
@@ -307,34 +299,30 @@
<div class="section">
<h4><a name="Restriction_Management"></a>Restriction Management</h4>
<p>Support for multiple restriction providers has already been been present with the default authorization implementation since Oak 1.0. The mechanism described in section <a href="restriction.html">Restriction Management</a> is not affected by the new functionality.</p>
-<p>The <tt>CompositeAuthorizationConfiguration</tt> is in charge of collecting the <tt>RestrictionProvider</tt>s from the aggregated modules and expose the complete set of restrictions in order to meet the API contract. </p>
+<p>The <tt>CompositeAuthorizationConfiguration</tt> is in charge of collecting the <tt>RestrictionProvider</tt>s from the aggregated modules and expose the complete set of restrictions in order to meet the API contract.</p>
<p>Nevertheless, each authorization model is responsible for exposing, validating and evaluating the subset of restrictions it can handle through the access control API extensions and the permission evaluation, respectively. A given model may decide to provide no support for restrictions. Examples include modules that deal with different types of <tt>AccessControlPolicy</tt> where restriction management doesn’t apply (see for example <a href="cug.html#details">oak-authorization-cug</a>).</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>By default the <tt>CompositeAuthorizationConfiguration</tt> aggregates results by applying an <tt>AND</tt> operation to the current set of providers. This can be changed via configuration to an <tt>OR</tt>. See section <a href="../../introduction.html#configuration">Introduction to Oak Security</a> for further details.</p>
-<p><a name="pluggability"></a></p></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
-<p>The following steps are required to plug an additional authorization model into the Oak repository:</p>
+<a name="pluggability"></a>
+### Pluggability
+<p>The following steps are required to plug an additional authorization model into the Oak repository:</p>
<ul>
-
+
<li>Implement your custom <tt>AuthorizationConfiguration</tt></li>
-
<li>Deploy the bundle containing the implementation</li>
-
<li>Bind your <tt>AuthorizationConfiguration</tt> to the <tt>SecurityProvider</tt>:
-
<ul>
-
-<li>in an OSGi setup this is achieved by adding the configuration to the <tt>requiredServicePids</tt> property of the <tt>SecurityProviderRegistration</tt> <i>(“Apache Jackrabbit Oak SecurityProvider”)</i> i.e. forcing the recreation of the <tt>SecurityProvider</tt>.</li>
-
-<li>in a non-OSGi setup this requires adding the configuration to the <tt>SecurityProvider</tt> (e.g. <i>SecurityProviderBuilder.newBuilder().with(params).build()</i>) and subsequently creating the JCR/Oak repository object.</li>
- </ul></li>
+
+<li>in an OSGi setup this is achieved by adding the configuration to the <tt>requiredServicePids</tt> property of the <tt>SecurityProviderRegistration</tt> <i>(“Apache Jackrabbit Oak SecurityProvider”)</i> i.e. forcing the recreation of the <tt>SecurityProvider</tt>.</li>
+<li>in a non-OSGi setup this requires adding the configuration to the <tt>SecurityProvider</tt> (e.g. <i>SecurityProviderBuilder.newBuilder().with(params).build()</i>) and subsequently creating the JCR/Oak repository object.</li>
+</ul>
+</li>
</ul>
-<p><b>Important Note</b><br />Despite the fact that Oak supports the aggregation of multiple authorization models, this extension is only recommended for experts that have in-depth knowledge and understanding of Jackrabbit/Oak authorization concepts. Doing so might otherwise result in severe security issues and heavily impact overall performance.</p>
-<!-- hidden references --></div></div>
+<p><b>Important Note</b><br />
+Despite the fact that Oak supports the aggregation of multiple authorization models, this extension is only recommended for experts that have in-depth knowledge and understanding of Jackrabbit/Oak authorization concepts. Doing so might otherwise result in severe security issues and heavily impact overall performance.</p><!-- hidden references --></div></div></div>
</div>
</div>
</div>
Modified: jackrabbit/site/live/oak/docs/security/authorization/cug.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/authorization/cug.html?rev=1835390&r1=1835389&r2=1835390&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/authorization/cug.html (original)
+++ jackrabbit/site/live/oak/docs/security/authorization/cug.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 – Managing Access with Closed User Groups (CUG)</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="Managing_Access_with_Closed_User_Groups_CUG"></a>Managing Access with “Closed User Groups” (CUG)</h2>
<div class="section">
<h3><a name="General"></a>General</h3>
@@ -249,32 +250,27 @@
<p>This implies that the CUG-authorization model solely evaluates and enforces read access to regular nodes and properties. Therefore it may only be used as an additional, complementary authorization scheme while the primary module(s) is/are in charge of enforcing the complete set of permissions including read/write access, repository operations and any kind of special permissions like reading and writing access control content. See section <a href="composite.html">Combining Multiple Authorization Models</a> for information aggregating access control management and permission evaluation from different implementations.</p>
<p>By default the <tt>oak-authorization-cug</tt> model is disabled and it requires manual <a href="#configuration">configuration</a> steps in order to plug it into the Oak security setup.</p>
<p>Once deployed this authorization configuration can be used in the following two operation modes:</p>
-
<ol style="list-style-type: decimal">
-
+
<li>Evaluation disabled: Access control management is supported and policies may be applied to the repository without taking effect.</li>
-
<li>Evaluation enabled: All policies edited and applied by this module will take effect upon being persisted, i.e. access to items located in a restricted are will be subject to the permission evaluation associated with the authorization model.</li>
</ol>
-<p><a name="jackrabbit_api"></a></p></div>
-<div class="section">
-<h3><a name="Jackrabbit_API"></a>Jackrabbit API</h3>
-<p>The Jackrabbit API defines an extension of the JCR <a class="externalLink" href="http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/security/AccessControlPolicy.html">AccessControlPolicy</a> interface intended to grant the ability to perform certain actions to a set of <a class="externalLink" href="http://docs.oracle.com/javase/7/docs/api/java/security/Principal.html">Principal</a>s:</p>
+<a name="jackrabbit_api"></a>
+### Jackrabbit API
+<p>The Jackrabbit API defines an extension of the JCR <a class="externalLink" href="http://www.day.com/specs/javax.jcr/javadocs/jcr-2.0/javax/jcr/security/AccessControlPolicy.html">AccessControlPolicy</a> interface intended to grant the ability to perform certain actions to a set of <a class="externalLink" href="http://docs.oracle.com/javase/7/docs/api/java/security/Principal.html">Principal</a>s:</p>
<ul>
-
+
<li><tt>PrincipalSetPolicy</tt></li>
</ul>
<p>See <a class="externalLink" href="http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/authorization/PrincipalSetPolicy.java">Jackrabbit API</a> for details and the methods exposed by the interface.</p>
-<p><a name="api_extensions"></a></p></div>
-<div class="section">
-<h3><a name="API_Extensions"></a>API Extensions</h3>
-<p>The module comes with the following extension in the <tt>org.apache.jackrabbit.oak.spi.security.authorization.cug</tt> package space:</p>
+<a name="api_extensions"></a>
+### API Extensions
+<p>The module comes with the following extension in the <tt>org.apache.jackrabbit.oak.spi.security.authorization.cug</tt> package space:</p>
<ul>
-
+
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/cug/CugPolicy.html">CugPolicy</a></li>
-
<li><a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/cug/CugExclude.html">CugExclude</a></li>
</ul>
<div class="section">
@@ -282,28 +278,28 @@
<h5><a name="CugPolicy"></a>CugPolicy</h5>
<p>The <tt>CugPolicy</tt> interface extends the <tt>PrincipalSetPolicy</tt> and <tt>JackrabbitAccessControlPolicy</tt> interfaces provided by Jackrabbit API. It comes with the following set of methods that allow to read and modify the set of <tt>Principal</tt>s that will be allowed to access the restricted area defined by a given policy instance.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">CugPolicy extends PrincipalSetPolicy, JackrabbitAccessControlPolicy
-
+<div>
+<div>
+<pre class="source">CugPolicy extends PrincipalSetPolicy, JackrabbitAccessControlPolicy
+
Set<Principal> getPrincipals();
boolean addPrincipals(@Nonnull Principal... principals) throws AccessControlException;
boolean removePrincipals(@Nonnull Principal... principals) throws AccessControlException;
-</pre></div></div></div>
+</pre></div></div>
+</div>
<div class="section">
<h5><a name="CugExclude"></a>CugExclude</h5>
<p>The <tt>CugExclude</tt> allows to customize the set of principals excluded from evaluation of the restricted areas. These principals will consequently never be prevented from accessing any of the configured CUGs and read permission evaluation is delegated to any other module present in the setup.</p>
<p>The feature ships with two implementations out of the box:</p>
-
<ul>
-
+
<li><tt>CugExclude.Default</tt>: Default implementation that excludes admin, system and system-user principals. It will be used as fallback if no other implementation is configured.</li>
-
<li><tt>CugExcludeImpl</tt>: OSGi service extending from the default that additionally allows to excluded principals by their names at runtime.</li>
</ul>
-<p>See also section <a href="#pluggability">Pluggability</a> below. </p>
-<p><a name="details"></a></p></div></div></div>
-<div class="section">
-<h3><a name="Implementation_Details"></a>Implementation Details</h3>
+<p>See also section <a href="#pluggability">Pluggability</a> below.</p>
+<a name="details"></a>
+### Implementation Details
+</div></div>
<div class="section">
<h4><a name="Access_Control_Management"></a>Access Control Management</h4>
<p>The access control management part of the CUG authorization models follows the requirements defined by JSR 283 the extensions defined by Jackrabbit API (see section <a href="../accesscontrol.html">Access Control Management</a> with the following characterstics:</p>
@@ -312,7 +308,7 @@
<p>This implemenation of the <tt>JackrabbitAccessControlManager</tt> only supports a subset of privileges, namely <tt>jcr:read</tt>, <tt>rep:readProperties</tt>, <tt>rep:readNodes</tt>.</p></div>
<div class="section">
<h5><a name="Access_Control_Policies"></a>Access Control Policies</h5>
-<p>Only a single type of access control policies (<tt>CugPolicy</tt>) is exposed and accepted by the access control manager. Once effective each CUG policy creates a restricted area starting at the target node and inherited to the complete subtree defined therein. </p>
+<p>Only a single type of access control policies (<tt>CugPolicy</tt>) is exposed and accepted by the access control manager. Once effective each CUG policy creates a restricted area starting at the target node and inherited to the complete subtree defined therein.</p>
<p>Depending on the value of the mandatory <tt>PARAM_CUG_SUPPORTED_PATHS</tt> <a href="#configuration">configuration</a> option creation (and evaluation) of CUG policies can be limited to certain paths within the repository. Within these supported paths CUGs can be nested. Note however, that the principal set defined with a given <tt>CugPolicy</tt> is not inherited to the nested policies applied in the subtree.</p>
<p><i>Note:</i> For performance reasons it is recommended to limited the usage of <tt>CugPolicy</tt>s to a single or a couple of subtrees in the repository.</p></div>
<div class="section">
@@ -322,205 +318,134 @@
<h4><a name="Permission_Evaluation"></a>Permission Evaluation</h4>
<p>As stated above evaluation of the restricted areas requires the <tt>PARAM_CUG_ENABLED</tt> <a href="#configuration">configuration</a> option to be set to <tt>true</tt>. This switch allows to setup restricted areas in a staging enviroment and only let them take effect in the public facing production instance.</p>
<p>If permission evaluation is enabled, the <tt>PermissionProvider</tt> implementation associated with the authorization model will prevent read access to all restricted areas defined by a <tt>CugPolicy</tt>. Only <tt>Principal</tt>s explicitly allowed by the policy itself or the globally configured <tt>CugExclude</tt> will be granted read permissions to the affected items in the subtree.</p>
-<p>For example, applying and persisting a new <tt>CugPolicy</tt> at path _/content/restricted/apache<i>foundation</i>, setting the principal names to <i>apache-members</i> and <i>jackrabbit-pmc</i> will prevent read access to the tree defined by this path for all <tt>Subject</tt>s that doesn’t match any of the two criteria:</p>
-
+<p>For example, applying and persisting a new <tt>CugPolicy</tt> at path <i>/content/restricted/apache_foundation</i>, setting the principal names to <i>apache-members</i> and <i>jackrabbit-pmc</i> will prevent read access to the tree defined by this path for all <tt>Subject</tt>s that doesn’t match any of the two criteria:</p>
<ul>
-
+
<li>the <tt>Subject</tt> contains<tt>Principal</tt> <i>apache-members</i> and|or <i>jackrabbit-pmc</i> (as defined in the <tt>CugPolicy</tt>)</li>
-
<li>the <tt>Subject</tt> contains at least one <tt>Principal</tt> explicitly excluded from CUG evaluation in the configured, global <tt>CugExclude</tt></li>
</ul>
-<p>This further implies that the <tt>PermissionProvider</tt> will only evaluate regular read permissions (i.e. <tt>READ_NODE</tt> and <tt>READ_PROPERTY</tt>). Evaluation of any other <a href="../permission.html#oak_permissions">permissions</a> including reading the cug policy node (access control content) is consequently delegated to other authorization modules. In case there was no module dealing with these permissions, access will be denied (see in section <i>Combining Multiple Authorization Models</i> for <a href="composite.html#details">details</a>). </p></div></div>
+<p>This further implies that the <tt>PermissionProvider</tt> will only evaluate regular read permissions (i.e. <tt>READ_NODE</tt> and <tt>READ_PROPERTY</tt>). Evaluation of any other <a href="../permission.html#oak_permissions">permissions</a> including reading the cug policy node (access control content) is consequently delegated to other authorization modules. In case there was no module dealing with these permissions, access will be denied (see in section <i>Combining Multiple Authorization Models</i> for <a href="composite.html#details">details</a>).</p></div></div>
<div class="section">
<h3><a name="Representation_in_the_Repository"></a>Representation in the Repository</h3>
<p>CUG policies defined by this module in a dedicate node name <tt>rep:cugPolicy</tt> of type <tt>rep:CugPolicy</tt>. This node is defined by a dedicate mixin type <tt>rep:CugMixin</tt> (similar to <tt>rep:AccessControllable</tt>) and has a single mandatory, protected property which stores the name of principals that are granted read access in the restricted area:</p>
-<div class="source">
-<div class="source"><pre class="prettyprint">[rep:CugMixin]
+<div>
+<div>
+<pre class="source">[rep:CugMixin]
mixin
+ rep:cugPolicy (rep:CugPolicy) protected IGNORE
-
+
[rep:CugPolicy] > rep:Policy
- rep:principalNames (STRING) multiple protected mandatory IGNORE
</pre></div></div>
-<p><i>Note:</i> the multivalued <tt>rep:principalNames</tt> property reflects the fact that CUGs are intended to be used for small principal sets, preferably <tt>java.security.acl.Group</tt> principals. </p>
-<p><a name="validation"></a></p></div>
-<div class="section">
-<h3><a name="Validation"></a>Validation</h3>
-<p>The consistency of this content structure both on creation and modification is asserted by a dedicated <tt>CugValidatorProvider</tt>. The corresponding error are all of type <tt>AccessControl</tt> with the following codes:</p>
+<p><i>Note:</i> the multivalued <tt>rep:principalNames</tt> property reflects the fact that CUGs are intended to be used for small principal sets, preferably <tt>java.security.acl.Group</tt> principals.</p>
+<a name="validation"></a>
+### Validation
+
+<p>The consistency of this content structure both on creation and modification is asserted by a dedicated <tt>CugValidatorProvider</tt>. The corresponding error are all of type <tt>AccessControl</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>0020 </td>
-
-<td>Attempt to change primary type of/to cug policy </td>
- </tr>
-
+<td> 0020 </td>
+<td> Attempt to change primary type of/to cug policy </td></tr>
<tr class="a">
-
-<td>0021 </td>
-
-<td>Wrong primary type of ‘rep:cugPolicy’ node </td>
- </tr>
-
+<td> 0021 </td>
+<td> Wrong primary type of ‘rep:cugPolicy’ node </td></tr>
<tr class="b">
-
-<td>0022 </td>
-
-<td>Access controlled not not of mixin ‘rep:CugMixin’ </td>
- </tr>
-
+<td> 0022 </td>
+<td> Access controlled not not of mixin ‘rep:CugMixin’ </td></tr>
<tr class="a">
-
-<td>0023 </td>
-
-<td>Wrong name of node with primary type ‘rep:CugPolicy’ </td>
- </tr>
- </tbody>
+<td> 0023 </td>
+<td> Wrong name of node with primary type ‘rep:CugPolicy’ </td></tr>
+</tbody>
</table>
-<p><a name="configuration"></a></p></div>
-<div class="section">
-<h3><a name="Configuration"></a>Configuration</h3>
+<a name="configuration"></a>
+### Configuration
+
<p>The CUG authorization extension is an optional feature that requires mandatory configuration: this includes defining the supported paths and enabling the permission evaluation.</p>
<div class="section">
<h4><a name="Configuration_Parameters"></a>Configuration Parameters</h4>
<p>The <tt>org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration</tt> supports the following configuration parameters:</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>PARAM_CUG_ENABLED</tt> </td>
-
-<td>boolean </td>
-
-<td>false </td>
-
-<td>Flag to enable evaluation of CUG policies upon read-access. </td>
- </tr>
-
+<td> <tt>PARAM_CUG_ENABLED</tt> </td>
+<td> boolean </td>
+<td> false </td>
+<td> Flag to enable evaluation of CUG policies upon read-access. </td></tr>
<tr class="a">
-
-<td><tt>PARAM_CUG_SUPPORTED_PATHS</tt> </td>
-
-<td>Set<String> </td>
-
-<td>- </td>
-
-<td>Paths under which CUGs can be created and will be evaluated. </td>
- </tr>
-
+<td> <tt>PARAM_CUG_SUPPORTED_PATHS</tt> </td>
+<td> Set<String> </td>
+<td> - </td>
+<td> Paths under which CUGs can be created and will be evaluated. </td></tr>
<tr class="b">
-
-<td><tt>PARAM_RANKING</tt> </td>
-
-<td>int </td>
-
-<td>200 </td>
-
-<td>Ranking within the composite authorization setup. </td>
- </tr>
-
+<td> <tt>PARAM_RANKING</tt> </td>
+<td> int </td>
+<td> 200 </td>
+<td> Ranking within the composite authorization setup. </td></tr>
<tr class="a">
-
-<td> </td>
-
<td> </td>
-
<td> </td>
-
<td> </td>
- </tr>
- </tbody>
+<td> </td></tr>
+</tbody>
</table>
<p><i>Note:</i> depending on other the authorization models deployed in the composite setup, the number of CUGs used in a given deployment as well as other factors such as predominant read vs. read-write, the performance of overall permission evaluation may benefit from changing the default ranking of the CUG authorization model.</p></div>
<div class="section">
<h4><a name="Excluding_Principals"></a>Excluding Principals</h4>
<p>The CUG authorization setup can be further customized by configuring the <tt>CugExcludeImpl</tt> service with allows to list additional principals that need to be excluded from the evaluation of restricted areas:</p>
-
<table border="0" class="table table-striped">
- <thead>
-
+<thead>
+
<tr class="a">
-
-<th>Parameter </th>
-
-<th>Type </th>
-
-<th>Default </th>
-
-<th>Description </th>
- </tr>
- </thead>
- <tbody>
-
+<th> Parameter </th>
+<th> Type </th>
+<th> Default </th>
+<th> Description </th></tr>
+</thead><tbody>
+
<tr class="b">
-
-<td><tt>principalNames</tt> </td>
-
-<td>Set<String> </td>
-
-<td>- </td>
-
-<td>Name of principals that are always excluded from CUG evaluation. </td>
- </tr>
-
+<td> <tt>principalNames</tt> </td>
+<td> Set<String> </td>
+<td> - </td>
+<td> Name of principals that are always excluded from CUG evaluation. </td></tr>
<tr class="a">
-
-<td> </td>
-
<td> </td>
-
<td> </td>
-
<td> </td>
- </tr>
- </tbody>
+<td> </td></tr>
+</tbody>
</table>
<p><i>Note:</i> This implementation extends the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authorization/cug/CugExclude.Default.html">default</a> exclusion list. Alternatively, it is possible to plug a custom <tt>CugExclude</tt> implementation matching specific needs (see <a href="#pluggability">below</a>).</p>
-<p><a name="pluggability"></a></p></div></div>
-<div class="section">
-<h3><a name="Pluggability"></a>Pluggability</h3>
+<a name="pluggability"></a>
+### Pluggability
+
<p>The following section describes how to deploy the CUG authorization model into an Oak repository and how to customize the <tt>CugExclude</tt> extension point.</p>
-<p><i>Note:</i> the reverse steps can be used to completely disable the CUG authorization model in case it is not needed for a given repository installation but shipped by a vendor such as e.g. Adobe AEM 6.3.</p>
+<p><i>Note:</i> the reverse steps can be used to completely disable the CUG authorization model in case it is not needed for a given repository installation but shipped by a vendor such as e.g. Adobe AEM 6.3.</p></div>
<div class="section">
<h4><a name="Deploy_CugConfiguration"></a>Deploy CugConfiguration</h4>
<div class="section">
<h5><a name="OSGi_Setup"></a>OSGi Setup</h5>
<p>The following steps are required in order to deploy the CUG authorization model in an OSGi-base Oak repository:</p>
-
<ol style="list-style-type: decimal">
-
+
<li>Deploy the <tt>oak-authorization-cug</tt> bundle</li>
-
<li>Activate the <tt>CugConfiguration</tt> <i>(“Apache Jackrabbit Oak CUG Configuration”)</i> by providing the desired component configuration (<i>ConfigurationPolicy.REQUIRE</i>)</li>
-
<li>Find the <tt>SecurityProviderRegistration</tt> <i>(“Apache Jackrabbit Oak SecurityProvider”)</i> configuration and enter <i><tt>org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration</tt></i> as additional value to the <tt>requiredServicePids</tt> property.</li>
</ol>
<p>The third step will enforce the recreation of the <tt>SecurityProvider</tt> and hence trigger the <tt>RepositoryInitializer</tt> provided by the CUG authorization module.</p></div>
@@ -528,28 +453,29 @@
<h5><a name="Non-OSGi_Setup"></a>Non-OSGi Setup</h5>
<p>The following example shows a simplified setup that contains the <tt>CugConfiguration</tt> as additional authorization model (second position in the aggregation). See also unit tests for an alternative approach.</p>
-<div class="source">
-<div class="source"><pre class="prettyprint"> // setup CugConfiguration
+<div>
+<div>
+<pre class="source"> // setup CugConfiguration
ConfigurationParameters params = ConfigurationParameters.of(AuthorizationConfiguration.NAME,
ConfigurationParameters.of(ConfigurationParameters.of(
CugConstants.PARAM_CUG_SUPPORTED_PATHS, "/content",
CugConstants.PARAM_CUG_ENABLED, true)));
CugConfiguration cug = new CugConfiguration();
cug.setParameters(params);
-
+
// bind it to the security provider
SecurityProvider securityProvider = SecurityProviderBuilder.newBuilder().with(configuration).build();
-
+
CompositeConfiguration<AuthorizationConfiguration> composite = (CompositeConfiguration) securityProvider
.getConfiguration(AuthorizationConfiguration.class);
AuthorizationConfiguration defConfig = composite.getDefaultConfig();
-
+
cug.setSecurityProvider(securityProvider);
cug.setRootProvider(((ConfigurationBase) defConfig).getRootProvider());
cug.setTreeProvider(((ConfigurationBase) defConfig).getTreeProvider());
composite.addConfiguration(cug);
composite.addConfiguration(defConfig);
-
+
// create the Oak repository (alternatively: create the JCR repository)
Oak oak = new Oak()
.with(new InitialContent())
@@ -557,27 +483,25 @@
.with(securityProvider);
withEditors(oak);
ContentRepository contentRepository = oak.createContentRepository();
-</pre></div></div></div></div>
+</pre></div></div>
+</div></div>
<div class="section">
<h4><a name="Customize_CugExclude"></a>Customize CugExclude</h4>
<p>The following steps are required in order to customize the <tt>CugExclude</tt> implementation in a OSGi-based repository setup. Ultimately the implementation needs to be referenced in the <tt>org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration</tt>.</p>
-
<ol style="list-style-type: decimal">
-
+
<li>implement <tt>CugExclude</tt> interface according to you needs,</li>
-
<li>make your implementation an OSGi service</li>
-
<li>deploy the bundle containing your implementation in the OSGi container and activate the service.</li>
-
<li>make sure the default CUGExclude service is properly replaced by the custom implementation.</li>
</ol>
<div class="section">
<div class="section">
<h6><a name="Example"></a>Example</h6>
-<div class="source">
-<div class="source"><pre class="prettyprint">@Component()
+<div>
+<div>
+<pre class="source">@Component()
@Service(CugExclude.class)
public class MyCugExclude implements CugExclude {