jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tri...@apache.org
Subject svn commit: r1581601 - in /jackrabbit/site/live/oak/docs: META-INF/ overview.html security/external_login_module.html
Date Tue, 25 Mar 2014 23:32:39 GMT
Author: tripod
Date: Tue Mar 25 23:32:39 2014
New Revision: 1581601

URL: http://svn.apache.org/r1581601
Log:
OAK-936: Site checkin for project Oak Documentation-0.20-SNAPSHOT

Removed:
    jackrabbit/site/live/oak/docs/META-INF/
Modified:
    jackrabbit/site/live/oak/docs/overview.html
    jackrabbit/site/live/oak/docs/security/external_login_module.html

Modified: jackrabbit/site/live/oak/docs/overview.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/overview.html?rev=1581601&r1=1581600&r2=1581601&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/overview.html (original)
+++ jackrabbit/site/live/oak/docs/overview.html Tue Mar 25 23:32:39 2014
@@ -386,6 +386,8 @@
 <ul>
     
 <li><a href="security/permission_eval.html">Permission Evaluation</a></li>
+    
+<li><a href="security/external_login_module.html">Authentication / Login Modules</a></li>
   </ul></li>
   
 <li><a class="externalLink" href="https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/README.md">Oak
Core</a></li>

Modified: jackrabbit/site/live/oak/docs/security/external_login_module.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/security/external_login_module.html?rev=1581601&r1=1581600&r2=1581601&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/security/external_login_module.html (original)
+++ jackrabbit/site/live/oak/docs/security/external_login_module.html Tue Mar 25 23:32:39
2014
@@ -359,42 +359,7 @@
    See the License for the specific language governing permissions and
    limitations under the License. --><h1>The Oak Security Layer</h1>
 <div class="section">
-<h2>External Login Module<a name="External_Login_Module"></a></h2>
-<div class="section">
-<h3>Overview<a name="Overview"></a></h3>
-<p>The purpose of the external login module is to provide a base implementation that
allows easy integration of 3rd party authentication and identity systems, such as LDAP. 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.</p>
-<p>what it does:</p>
-
-<ul>
-  
-<li>facilitate the use of a 3rd party system for authentication</li>
-  
-<li>simplify populating the oak user manager with identities from a 3rd party system</li>
-</ul>
-<p>what it does not:</p>
-
-<ul>
-  
-<li>provide a transparent oak user manager</li>
-  
-<li>provide a transparent oak principal provider.</li>
-  
-<li>offer services for background synchronization of users and groups</li>
-</ul></div>
-<div class="section">
-<h3>Structure<a name="Structure"></a></h3>
-<p>The external identity and login handling is split into 3 parts:</p>
-
-<ol style="list-style-type: decimal">
-  
-<li>An external identity provider (IDP). This is a service implementing the <tt>ExternalIdentityProvider</tt>
interface and is responsible to retrieve and authenticate identities towards an external system
(e.g. LDAP).</li>
-  
-<li>An synchronization handler. This is a service implementing the <tt>SyncHandler</tt>
interface and is responsible to actually managing the external identities within the Oak user
management. A very trivial implementation might just create users and groups for external
ones on demand.</li>
-  
-<li>The external login module (ExtLM). This is the connection between JAAS login mechanism,
the external identity provider and the synchronization handler.</li>
-</ol>
-<p>This modularization allows to reuse the same external login module for different
combinations of IDPs and synchronization handlers. Although in practice, systems usually have
1 of each. </p>
-<p>An example where multiple such entities come into play would be the case to use
several LDAP servers for authentication. Here we would configure 2 LDAP IDPs, 1 Sync handler
and 2 ExtLMs.</p></div>
+<h2>Authentication / Login Modules<a name="Authentication__Login_Modules"></a></h2>
 <div class="section">
 <h3>Types of login modules<a name="Types_of_login_modules"></a></h3>
 <p>In order to understand how login modules work and how Oak can help providing extension
points we need to look at how JAAS authentication works in general and discuss where the actual
credential-verification is performed.</p>
@@ -402,26 +367,21 @@
 <h4>Brief recap of the JAAS authentication<a name="Brief_recap_of_the_JAAS_authentication"></a></h4>
 <p>The following section is copied and adapted from the javadoc of <a class="externalLink"
href="http://docs.oracle.com/javase/6/docs/api/javax/security/auth/spi/LoginModule.html">javax.security.auth.spi.LoginModule</a>:</p>
 <p>The authentication process within the <tt>LoginModule</tt> proceeds
in two distinct phases. </p>
+<p>1.</p>
 
 <ol style="list-style-type: decimal">
   
-<li>
-  
-<ol style="list-style-type: decimal">
-    
 <li>In the first phase, the <tt>LoginModule</tt>&#x2019;s <tt>login</tt>
method gets invoked by the <tt>LoginContext</tt>&#x2019;s <tt>login</tt>
method.</li>
-  </ol></li>
   
 <li>The <tt>login</tt> method for the <tt>LoginModule</tt>
then performs the actual authentication (prompt for and verify a  password for example) and
saves its authentication status as private state information.</li>
   
 <li>Once finished, the <tt>LoginModule</tt>&#x2019;s login method either
returns <tt>true</tt> (if it succeeded) or <tt>false</tt> (if it should
 be ignored), or throws a <tt>LoginException</tt> to specify a failure. In the
failure case, the <tt>LoginModule</tt> must not  retry the authentication or introduce
delays. The responsibility of such tasks belongs to the application.  If the application attempts
to retry the authentication, the <tt>LoginModule</tt>&#x2019;s <tt>login</tt>
method will be called again.</li>
-  
-<li>
-  
+</ol>
+<p>2.</p>
+
 <ol style="list-style-type: decimal">
-    
+  
 <li>In the second phase, if the <tt>LoginContext</tt>&#x2019;s overall
authentication succeeded (the relevant REQUIRED, REQUISITE,  SUFFICIENT and OPTIONAL LoginModules
succeeded), then the <tt>commit</tt> method for the <tt>LoginModule</tt>
gets invoked.</li>
-  </ol></li>
   
 <li>The <tt>commit</tt> method for a <tt>LoginModule</tt> checks
its privately saved state to see if its own authentication  succeeded.</li>
   
@@ -434,53 +394,24 @@
 <p>Very simply put, all the login modules that participate in JAAS authentication are
configured in a list and can have flags indicating how to treat their behaviors on the <tt>login()</tt>
calls.</p>
 <p>JAAS defines the following module flags:<br />(The following section is copied
and adapted from the javadoc of <a class="externalLink" href="http://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html">javax.security.auth.login.Configuration</a>)</p>
 
-<ol style="list-style-type: decimal">
-  
-<li><b>Required</b></li>
-</ol>
-<p>: The LoginModule is required to succeed.<br /> If it succeeds or fails, authentication
still continues to proceed down the LoginModule list.</p>
-
-<ol style="list-style-type: decimal">
-  
-<li><b>Requisite</b></li>
-</ol>
-<p>: The LoginModule is required to succeed.<br /> If it succeeds, authentication
continues down the LoginModule list.  If it fails, control immediately returns to the application
(authentication does not proceed down the LoginModule  list).</p>
-
-<ol style="list-style-type: decimal">
-  
-<li><b>Sufficient</b></li>
-</ol>
-<p>: The LoginModule is not required to succeed.<br /> If it does succeed, control
immediately returns to the application (authentication does not proceed down the  LoginModule
list).  If it fails, authentication continues down the LoginModule list.</p>
-
-<ol style="list-style-type: decimal">
-  
-<li><b>Optional</b></li>
-</ol>
-<p>: The LoginModule is not required to succeed.<br /> If it succeeds or fails,
authentication still continues to proceed down the LoginModule list.</p>
-<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>
+<dl>
+<dt><b>Required</b></dt>
+<dd>The LoginModule is required to succeed.<br /> If it succeeds or fails, authentication
still continues to proceed down the LoginModule list.</dd>
+<dt><b>Requisite</b></dt>
+<dd>The LoginModule is required to succeed.<br /> If it succeeds, authentication
continues down the LoginModule list.  If it fails, control immediately returns to the application
(authentication does not proceed down the LoginModule  list).</dd>
+<dt><b>Sufficient</b></dt>
+<dd>The LoginModule is not required to succeed.<br /> If it does succeed, control
immediately returns to the application (authentication does not proceed down the  LoginModule
list).  If it fails, authentication continues down the LoginModule list.</dd>
+<dt><b>Optional</b></dt>
+<dd>The LoginModule is not required to succeed.<br /> If it succeeds or fails,
authentication still continues to proceed down the LoginModule list.</dd>
+</dl>
+<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 class="section">
-<h4>Authentication and subject population<a name="Authentication_and_subject_population"></a></h4>
-<p>The goal of the external login module is to provide a very simple way of using <i>&#x201c;the
users stored in an external system for authentication and authorization in the Oak content
repository&#x201d;</i>. So the easiest way of doing this is to import the users
on-demand when they log in. </p></div>
+<h3>Pre Authenticated Logins<a name="Pre_Authenticated_Logins"></a></h3>
+<p>Pre authenticated logins allows to support 3rd party login modules that wish to
provide the login context with pre authenticated login names, but still want to rely on the
rest of the oak&#x2019;s login module chain. For example an external SSO login module
can extract the userid from a servlet request and use it to authenticate against the repository.
But instead of re-implementing the user lookup and subject population (and possible external
user synchronization) it just sets a respective <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/PreAuthenticatedLogin.html">org.apache.jackrabbit.oak.spi.security.authentication.PreAuthenticatedLogin</a>
on the shared state.</p></div></div>
 <div class="section">
-<h4>Password caching<a name="Password_caching"></a></h4>
-<p>In order to prevent extensive authentication calls against the 3rd party system
the user&#x2019;s credentials, in particular the passwords need to be cached. There are
two different way doing this.</p>
-<p>The first way is to only cache the password (encrypted) in memory and expire them
over time. this has the advantage that they are not copied to the local repository and can
be invalidated easier and with a different cycle than the actual user synchronization. It
has the disadvantage, that users won&#x2019;t be able to login, if the 3rd party system
is offline.</p>
-<p>The alternative is to cache the passwords in the repository together with the synced
user. this has the advantage that the 3rd party system can be offline and users will still
be able to login. It has the following disadvantages:</p>
-
-<ul>
-  
-<li>password are copied to the local system and stored with the users in a encrypted
form. This might be a security concern and might not comply with security policies.</li>
-  
-<li>it only works for simple password based credentials.</li>
-</ul></div></div>
+<h2>Default Login Module<a name="Default_Login_Module"></a></h2>
 <div class="section">
-<h3>Behavior of the External Login Module<a name="Behavior_of_the_External_Login_Module"></a></h3>
-<div class="section">
-<h4>General<a name="General"></a></h4>
-<p>The external login module has 2 main tasks. one is to authenticate credentials against
a 3rd party system, the other is to coordinate syncing of the respective users and groups
with the JCR repository (via the UserManager).</p>
-<p>If a user needs re-authentication (for example, if the cache validity expired or
if the user is not yet present in the local system at all), the login module must check the
credentials with the external system during the <tt>login()</tt> method. If authentication
succeeds, it must return <tt>true</tt> or throw a <tt>LoginException</tt>
if authentication failed. </p>
-<p>There are some nuances to this and it is important to understand the exact behavior
of the login module(s) so that the JAAS login can be configured correctly:</p>
-<p><b>LoginModuleImpl</b></p>
+<h3>Behavior of the Default Login Module<a name="Behavior_of_the_Default_Login_Module"></a></h3>
 <p>The behavior of the default login module is relatively simple, so it is explained
first:</p>
 <p>upon login():</p>
 
@@ -488,17 +419,22 @@
   
 <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&#x2019;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></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>upon commit():</p>
 
@@ -507,236 +443,433 @@
 <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>
-<p><b>ExternalLoginModule</b></p>
-<p>Note:</p>
+</ul></div></div>
+<div class="section">
+<h2>External Login Module<a name="External_Login_Module"></a></h2>
+<div class="section">
+<h3>Overview<a name="Overview"></a></h3>
+<p>The purpose of the external login module is to provide a base implementation that
allows easy integration of 3rd party authentication and identity systems, such as LDAP. 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.</p>
+<p>what it does:</p>
 
 <ul>
   
-<li>users (and groups) that are synced from the 3rd party system contain a <tt>rep:syncSource</tt>
(TBD) property. This allows to identify the external users and distinguish them from others.</li>
+<li>facilitate the use of a 3rd party system for authentication</li>
   
-<li>to reduce expensive syncing, the synced users and groups have sync timestamp <tt>rep:lastSynced</tt>
and are considered valid for a configurable time. if they expire, they need to be validated
against the 3rd party system again.</li>
+<li>simplify populating the oak user manager with identities from a 3rd party system</li>
 </ul>
-<p>upon login():</p>
+<p>what it does not:</p>
 
 <ul>
   
-<li>if the passwords are cached in memory and the credentials are valid, it puts the
credentials in the private state and <b>returns <tt>true</tt></b></li>
-  
-<li>if the user exists in the 3rd party system and the credentials match, it puts the
credentials in the private state and <b>returns <tt>true</tt></b></li>
+<li>provide a transparent oak user manager</li>
   
-<li>if the user exists in the 3rd party system but the credentials don&#x2019;t
match it <b>throws <tt>LoginException</tt></b></li>
+<li>provide a transparent oak principal provider.</li>
   
-<li>if the user does not exist in the 3rd party system, it <b>returns <tt>false</tt></b></li>
-</ul>
-<p>upon commit():</p>
+<li>offer services for background synchronization of users and groups</li>
+</ul></div>
+<div class="section">
+<h3>Structure<a name="Structure"></a></h3>
+<p>The external identity and login handling is split into 3 parts:</p>
 
-<ul>
+<ol style="list-style-type: decimal">
   
-<li>if there is no credentials in the private state, it <b>returns <tt>false</tt></b></li>
+<li>An external identity provider (IDP). This is a service implementing the <tt>ExternalIdentityProvider</tt>
interface and is responsible to retrieve and authenticate identities towards an external system
(e.g. LDAP).</li>
   
-<li>if there are credentials in the private state, possibly sync the user and then
propagate the subject and <b>return <tt>true</tt></b></li>
-</ul>
-<!-- * If a user does **not** exist in the 3rd party system, it could be that
-    1. the user was not and will never exist there, and authentication should proceed to
the next login module.
-       This is for example the case for the *admin* user that only exists locally.
-    2. the user was removed from the 3rd party system but still exists locally. In this case,
the user needs to be
-       removed locally and authentication needs to proceed to the next login module
-  
-  So in both cases above, the external login module needs to returns `false` in its `login()`
method.
-  
-* If a user **does** exist in the 3rd party system, it could be that
-    1. no local user with the same userid exists, so the result of the 3rd party authentication
is sufficient enough.
-    2. a local user with the same userid exists (who is not an imported 3rd party user) then
it depends on the
-       configuration if to rely on the external authentication or not. This problem is especially
important to note, 
-       if the external and local users cannot be distinguished by principal name (which is
usually the case).  
-       A good default is to decline authentication (i.e. return `false`) and rely on the
default login module in such
-       cases.
-       
-Any `ExternalLoginModule` needs to be configured as **sufficient** and listed **before**
the default `LoginModuleImpl`. 
-this will lead to the following behaviors:
-
-1. if a (remote) user does not exist in the repository, he is authenticated against the 3rd
party system and...
-    * if the user does not exist in the 3rd party system, the `login()` returns `false` and
the JAAS authentication 
-      continues with the next login module.
-    * if authentication fails, the `login()` throws a `LoginException` and the overall JAAS
authentication continues
-      with the next module. Note that this will allow local user override that also exist
in the external system.
-    * if authentication succeeds, the 1. phase of the JAAS authentication is completed. There
are extra steps that
-      the external login module needs to perform in order to sync the user.
-2. if a (remote) user exists in the repository and he does not need re-authentication, the
`login()` method returns
-   `true` and authentication completes. 
-3. if a (remote) user exists in the repository and he needs re-authentication then the user
is removed from the
-   repository and the same steps as in 1. above apply.
-   
-Since the module is configured as **sufficient** any successful authentication against the
3rd party system will
-complete the first phase of the JAAS authentication and the `ExternalLoginModule` has time
to actually sync the
-user during the 2nd phase in the `commit()` method. But this depends again on the mode of
operation. see pseudo
-code sections below. --></div>
-<div class="section">
-<h4>User Synchronization<a name="User_Synchronization"></a></h4>
-<p>TODO</p></div>
+<li>An synchronization handler. This is a service implementing the <tt>SyncHandler</tt>
interface and is responsible to actually managing the external identities within the Oak user
management. A very trivial implementation might just create users and groups for external
ones on demand.</li>
+  
+<li>The external login module (ExtLM). This is the connection between JAAS login mechanism,
the external identity provider and the synchronization handler.</li>
+</ol>
+<p>This modularization allows to reuse the same external login module for different
combinations of IDPs and synchronization handlers. Although in practice, systems usually have
1 of each. </p>
+<p>An example where multiple such entities come into play would be the case to use
several LDAP servers for authentication. Here we would configure 2 LDAP IDPs, 1 Sync handler
and 2 ExtLMs.</p>
 <div class="section">
-<h4>Groups Synchronization<a name="Groups_Synchronization"></a></h4>
-<p>TODO</p></div></div>
+<h4>Authentication and subject population<a name="Authentication_and_subject_population"></a></h4>
+<p>The goal of the external login module is to provide a very simple way of using <i>&#x201c;the
users stored in an external system for authentication and authorization in the Oak content
repository&#x201d;</i>. So the easiest way of doing this is to import the users
on-demand when they log in. </p></div></div>
 <div class="section">
-<h3>Configuration<a name="Configuration"></a></h3>
+<h3>Behavior of the External Login Module<a name="Behavior_of_the_External_Login_Module"></a></h3>
 <div class="section">
-<h4>JAAS Configuration<a name="JAAS_Configuration"></a></h4>
-<p>The external login module as usually configured as <b>sufficient</b>
and <b>before</b> the <tt>LoginModuleImpl</tt>.</p>
-<p>other config</p>
+<h4>General<a name="General"></a></h4>
+<p>The external login module has 2 main tasks. one is to authenticate credentials against
a 3rd party system, the other is to coordinate syncing of the respective users and groups
with the JCR repository (via the UserManager).</p>
+<p>If a user needs re-authentication (for example, if the cache validity expired or
if the user is not yet present in the local system at all), the login module must check the
credentials with the external system during the <tt>login()</tt> method. </p>
+<p><b>ExternalLoginModule</b></p>
+<p>Note:</p>
 
 <ul>
   
-<li>password caching expiration time (0 == disable password caching)</li>
-  
-<li>maximum passwords to cache (i.e. num users)</li>
+<li>users (and groups) that are synced from the 3rd party system contain a <tt>rep:externalId</tt>
property. This allows to identify the external users and distinguish them from others.</li>
   
-<li>synced user expiration</li>
-  
-<li>synced group expiration</li>
-  
-<li>synced membership expiration</li>
-  
-<li>sync groups</li>
-  
-<li>user intermediate path / split dn</li>
-  
-<li>group intermediate path / split dn</li>
-  
-<li>user sync modification attribute</li>
-  
-<li>group sync modification attribute</li>
-  
-<li>autoGroupMembership (user / groups)</li>
-  
-<li>userAttributeMapping</li>
-  
-<li>groupAttributeMapping</li>
-  
-<li>ldap user root (dn)</li>
-  
-<li>ldap group root (dn)</li>
-  
-<li>ldap userIdAttribute</li>
-  
-<li>ldap userFilter</li>
-  
-<li>ldap groupFilter</li>
-  
-<li>ldap groupNameAttribute</li>
+<li>to reduce expensive syncing, the synced users and groups have sync timestamp <tt>rep:lastSynced</tt>
and are considered valid for a configurable time. if they expire, they need to be validated
against the 3rd party system again.</li>
+</ul>
+<p>upon login():</p>
+
+<ul>
   
-<li>ldap groupMembershipAttribute</li>
+<li>if the user exists in the repository and is not an externally synced, <b>return
<tt>false</tt></b></li>
   
-<li>ldap searchTimeout</li>
+<li>if the user exists in the 3rd party system but the credentials don&#x2019;t
match it <b>throws <tt>LoginException</tt></b></li>
   
-<li>groupNestingDepth</li>
+<li>if the user exists in the 3rd party system and the credentials match
   
-<li>
-<p>local/external user precedence. default is: local wins. best use include/exclude
of user patterns. e.g. admin  should never be external.</p></li>
+<ul>
+    
+<li>put the credentials in the shared and private state</li>
+    
+<li>possibly sync the user</li>
+    
+<li>and <b>returns <tt>true</tt></b></li>
+  </ul></li>
   
-<li>password sync or not.</li>
+<li>if the user does not exist in the 3rd party system, checks if it needs to remove
the user and then it <b>returns <tt>false</tt></b></li>
+</ul>
+<p>upon commit():</p>
+
+<ul>
   
-<li>various cache expiration times (pwd, users, groups)</li>
+<li>if there is no credentials in the private state, it <b>returns <tt>false</tt></b></li>
   
-<li></li>
-</ul></div>
+<li>if there are credentials in the private state propagate the subject and <b>return
<tt>true</tt></b></li>
+</ul></div></div></div>
+<div class="section">
+<h2>User and Group Synchronization<a name="User_and_Group_Synchronization"></a></h2>
+<p>The synchronization of users and groups is triggered by the external login module,
after a user is successfully authenticated against the IDP or if it&#x2019;s no longer
present on the IDP.</p>
+<div class="section">
+<h3>Configuration of the DefaultSyncHandler<a name="Configuration_of_the_DefaultSyncHandler"></a></h3>
+<p>Oak provides a default synchronization handler that is configured via <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncConfig.html">org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncConfig</a>.
The handler is configured either via OSGi or during manual <a href="../construct.html">Repository
Construction</a>.</p>
+
+<table border="0" class="table table-striped">
+  <thead>
+    
+<tr class="a">
+      
+<th>Name </th>
+      
+<th>Property </th>
+      
+<th>Description </th>
+    </tr>
+  </thead>
+  <tbody>
+    
+<tr class="b">
+      
+<td>Sync Handler Name </td>
+      
+<td><tt>handler.name</tt> </td>
+      
+<td>Name of this sync configuration. This is used to reference this handler by the
login modules. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User auto membership </td>
+      
+<td><tt>user.autoMembership</tt> </td>
+      
+<td>List of groups that a synced user is added to automatically </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>User Expiration Time </td>
+      
+<td><tt>user.expirationTime</tt> </td>
+      
+<td>Duration until a synced user gets expired (eg. &#x2018;1h 30m&#x2019; or
&#x2018;1d&#x2019;). </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User Membership Expiration </td>
+      
+<td><tt>user.membershipExpTime</tt> </td>
+      
+<td>Time after which membership expires (eg. &#x2018;1h 30m&#x2019; or &#x2018;1d&#x2019;).
</td>
+    </tr>
+    
+<tr class="b">
+      
+<td>User membership nesting depth </td>
+      
+<td><tt>user.membershipNestingDepth</tt> </td>
+      
+<td>Returns the maximum depth of group nesting when membership relations are synced.
A value of 0 effectively disables group membership lookup. A value of 1 only adds the direct
groups of a user. This value has no effect when syncing individual groups only when syncing
a users membership ancestry. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User Path Prefix </td>
+      
+<td><tt>user.pathPrefix</tt> </td>
+      
+<td>The path prefix used when creating new users. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>User property mapping </td>
+      
+<td><tt>user.propertyMapping</tt> </td>
+      
+<td>List mapping definition of local properties from external ones. eg: &#x2018;profile/email=mail&#x2019;.Use
double quotes for fixed values. eg: &#x2019;profile/nt:primaryType=&#x201c;nt:unstructured&#x201d;
</td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Group auto membership </td>
+      
+<td><tt>group.autoMembership</tt> </td>
+      
+<td>List of groups that a synced group is added to automatically </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Group Expiration Time </td>
+      
+<td><tt>group.expirationTime</tt> </td>
+      
+<td>Duration until a synced group expires (eg. &#x2018;1h 30m&#x2019; or &#x2018;1d&#x2019;).
</td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Group Path Prefix </td>
+      
+<td><tt>group.pathPrefix</tt> </td>
+      
+<td>The path prefix used when creating new groups. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Group property mapping </td>
+      
+<td><tt>group.propertyMapping</tt> </td>
+      
+<td>List mapping definition of local properties from external ones. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;
</td>
+      
+<td> </td>
+      
+<td> </td>
+    </tr>
+  </tbody>
+</table></div></div>
 <div class="section">
-<h4>pseudo code for users with synced passwords<a name="pseudo_code_for_users_with_synced_passwords"></a></h4>
+<h2>LDAP Identity Provider<a name="LDAP_Identity_Provider"></a></h2>
+<p>Oak comes with a default implementation of an LDAP identity provider.</p>
+<div class="section">
+<h3>Configuration<a name="Configuration"></a></h3>
+<p>The LDAP IPDs are configured through the <a href="/oak/docs/apidocs/org/apache/jackrabbit/oak/security/authentication/ldap/impl/LdapProviderConfig.html">org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapProviderConfig</a>
which is populated either via OSGi or during manual <a href="../construct.html">Repository
Construction</a>.</p>
 
-<div class="source">
-<pre>login() {
-    extract userid and password from credentials    
-    find user in repository
-    if (user exists in repository) {
-        if (user is local user) {
-            // not our user - decline.
-            return false;
-        }
-        if (user needs sync) {
-            flag user to be synced
-        } else {
-            // delegate work to default login module
-            return false;    
-        }
-    }    
-    find user in remote system
-    if (user exists in remote system) {
-        authenticate user against remote system
-        if (authentication successful) {
-            sync user including the provided password locally
-            // delegate further work to default login module
-            return false;
-        } else {
-            throw LoginException();
-        }
-    } else {
-        if (user is flagged) {
-            remove user
-        }
-        return false;
-    }
-}
-commit() {
-    // nothing to do
-    return false;
-}
-</pre></div></div>
-<div class="section">
-<h4>pseudo code for users without synced passwords<a name="pseudo_code_for_users_without_synced_passwords"></a></h4>
-
-<div class="source">
-<pre>login() {
-    extract userid and password from credentials
-    find user in repository
-    if (user exists in repository) {
-        if (user is local user) {
-            // not our user - decline.
-            return false;    
-        }
-        if (user needs sync) {
-            flag user to be synced
-        } else {
-            check if users credentials are cached and not expired
-            if (cached credentials match) {
-                // authentication successful
-                return true;
-            }
-            // here it could be that the user changed his password on the IDP
-            // and he already provided the new password in the login. so we can't
-            // throw the LoginException here but need to revalidate him against the IDP.
-        }
-        clear cached credentials
-    }
-    find user in remote system
-    if (user exists in remote system) {
-        authenticate user against remote system
-        if (authentication successful) {
-            flag user to be  synced
-            cache credentials
-            return true;
-        } else {
-            throw LoginException();
-        }
-    } else {
-        if (user is flagged) {
-            remove user
-        }
-        return false;
-    }
-}
-commit() {
-    if (user needs to be synced ) {
-        sync user
-    }
-    if (this module did authenticate the user) {
-        populate subject with the correct principals
-        return true;
-    } else {
-        return false;
-    }
-}
-</pre></div>
-<!-- references --></div></div></div>
+<table border="0" class="table table-striped">
+  <thead>
+    
+<tr class="a">
+      
+<th>Name </th>
+      
+<th>Property </th>
+      
+<th>Description </th>
+    </tr>
+  </thead>
+  <tbody>
+    
+<tr class="b">
+      
+<td>LDAP Provider Name </td>
+      
+<td><tt>provider.name</tt> </td>
+      
+<td>Name of this LDAP provider configuration. This is used to reference this provider
by the login modules. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Bind DN </td>
+      
+<td><tt>bind.dn</tt> </td>
+      
+<td>DN of the user for authentication. Leave empty for anonymous bind. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Bind Password </td>
+      
+<td><tt>bind.password</tt> </td>
+      
+<td>Password of the user for authentication. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>LDAP Server Hostname </td>
+      
+<td><tt>host.name</tt> </td>
+      
+<td>Hostname of the LDAP server </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Disable certificate checking </td>
+      
+<td><tt>host.noCertCheck</tt> </td>
+      
+<td>Indicates if server certificate validation should be disabled. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>LDAP Server Port </td>
+      
+<td><tt>host.port</tt> </td>
+      
+<td>Port of the LDAP server </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Use SSL </td>
+      
+<td><tt>host.ssl</tt> </td>
+      
+<td>Indicates if an SSL (LDAPs) connection should be used. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Use TLS </td>
+      
+<td><tt>host.tls</tt> </td>
+      
+<td>Indicates if TLS should be started on connections. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Search Timeout </td>
+      
+<td><tt>searchTimeout</tt> </td>
+      
+<td>Time in until a search times out (eg: &#x2018;1s&#x2019; or &#x2018;1m
30s&#x2019;). </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User base DN </td>
+      
+<td><tt>user.baseDN</tt> </td>
+      
+<td>The base DN for user searches. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>User extra filter </td>
+      
+<td><tt>user.extraFilter</tt> </td>
+      
+<td>Extra LDAP filter to use when searching for users. The final filter is formatted
like: <tt>(&amp;(&lt;idAttr&gt;=&lt;userId&gt;)(objectclass=&lt;objectclass&gt;)&lt;extraFilter&gt;)</tt>
</td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User id attribute </td>
+      
+<td><tt>user.idAttribute</tt> </td>
+      
+<td>Name of the attribute that contains the user id. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>User DN paths </td>
+      
+<td><tt>user.makeDnPath</tt> </td>
+      
+<td>Controls if the DN should be used for calculating a portion of the intermediate
path. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>User object classes </td>
+      
+<td><tt>user.objectclass</tt> </td>
+      
+<td>The list of object classes an user entry must contain. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Group base DN </td>
+      
+<td><tt>group.baseDN</tt> </td>
+      
+<td>The base DN for group searches. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Group extra filter </td>
+      
+<td><tt>group.extraFilter</tt> </td>
+      
+<td>Extra LDAP filter to use when searching for groups. The final filter is formatted
like: <tt>(&amp;(&lt;nameAttr&gt;=&lt;groupName&gt;)(objectclass=&lt;objectclass&gt;)&lt;extraFilter&gt;)</tt>
</td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Group DN paths </td>
+      
+<td><tt>group.makeDnPath</tt> </td>
+      
+<td>Controls if the DN should be used for calculating a portion of the intermediate
path. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Group member attribute </td>
+      
+<td><tt>group.memberAttribute</tt> </td>
+      
+<td>Group attribute that contains the member(s) of a group. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>Group name attribute </td>
+      
+<td><tt>group.nameAttribute</tt> </td>
+      
+<td>Name of the attribute that contains the group name. </td>
+    </tr>
+    
+<tr class="a">
+      
+<td>Group object classes </td>
+      
+<td><tt>group.objectclass</tt> </td>
+      
+<td>The list of object classes a group entry must contain. </td>
+    </tr>
+    
+<tr class="b">
+      
+<td>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;
</td>
+      
+<td> </td>
+      
+<td> </td>
+    </tr>
+  </tbody>
+</table>
+<!-- references --></div></div>
                   </div>
             </div>
           </div>



Mime
View raw message