jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "JackrabbitOsgi" by FelixMeschberger
Date Fri, 29 Jan 2010 10:46:03 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "JackrabbitOsgi" page has been changed by FelixMeschberger.
http://wiki.apache.org/jackrabbit/JackrabbitOsgi?action=diff&rev1=2&rev2=3

--------------------------------------------------

    * Provide some degree of dynamic extensibility (at least provide the pluggability currently
supported by the Sling Jackrabbit Server bundle)
  
  
- === Jackrabbit Core Bundle and Embedded Dependencies ===
+ ==== Jackrabbit Core Bundle and Embedded Dependencies ====
  
  The biggest issue when bundelizing the Jackrabbit Core bundle is the is the list of dependencies
and extensibility. 
  
@@ -52, +52 @@

  The current approach followed in the [[http://svn.apache.org/repos/asf/jackrabbit/sandbox/jackrabbit2-bundle|Jackrabbit
2 Bundle Sandbox]] is to embed libraries, which are not available as bundles and to not embed
libraries available as bundles.
  
  
- === Easy Startup and Access ===
+ ==== Easy Startup and Access ====
  
  For easy startup and access the OSGi specification offers great functionalities: To startup
an embedded repository instance, we need a location to store the filesystem data to and a
location to access a configuration. Both properties can easily be provided through the OSGi
Configuration Admin Service. This is what we do in the Sling Jackrabbit Server bundle and
thus this is also implemented in the current approach.
  
@@ -63, +63 @@

  As for the configuration file: The Jackrabbit Core library contains a default repository.xml
file ({{{OSGI-INF/repository_osgi.xml}}}) which is used as a configuration file if none is
provided.
  
  
- === Extensibility ===
+ ==== Extensibility ====
  
  
  Jackrabbit configuration is the subject of a book of its own. Yet some things may be setup
rather dynamically in the sense of extensible at runtime by the system administrator. Things
in this area, we have at the moment in the Sling Jackrabbit Server bundle are a framework
to extend login modules and a support to plugin extensible access controllers.
  
  Both should, if possible, be migrated to the Jackrabbit Core bundle; possibly even enhancing
it. Of course such extensibility points will have to be exported from the Jackrabbit Core
bundle and as such will be placed into separate locations.
  
+ 
+ 
+ == Pluggable LoginModule ==
+ 
+ The goal of a pluggable login module system is to provide a simple means to extend the functionality
of the {{{DefaultLoginModule}}} which is part of the internal API (but is one of those things,
which cannot easily be exported without exposing internal implementation). One major use case
of such pluggable login module functionality is to account for authentication mechanisms which
require more than just the final {{{SimpleCredentials}}} class but otherwise would benefit
from all the {{{Principal}}} resolution support of the {{{DefaultLoginModule}}}.
+ 
+ The {{{PluggableDefaultLoginModule}}} overwrites the following methods of the {{{DefaultLoginModule}}}
and the {{{AbstractLoginModule}}}:
+ 
+  doInit:: Locates a login module plugin which is capable of handling the credentials provided
in the {{{Repository.login}}} method.
+  commit:: Allows the login module plugin to properly cleanup after a successful login attempt
+  abort:: Allows the login module plugin to properly cleanup after a failed login attempt
+  supportsCredentials:: Locates a login module plugin which is capable of handlig the credentials.
If none can be found, the base class implementation is called.
+  getUserID:: Overwrites the {{{AbstractLoginModule}}} implementation to check whether one
of the plugins can provide the user ID for the given credentials. If not the base class implementation
is called.
+  getPrincipal:: Overwrites the {{{DefaultLoginModule}}} implementation to check whether
one of the plugins can provide a Principal. If not the base class implementation is called.
+  getPrincipals:: Calls base class implementation to get the base set of principals and the
calls the currently used plugin to add further prinicipals and returns the completed set.
+  authenticate:: Calls the authenticate method of the plugin handling the given credentials
and returns {{{true}}}. If no plugin can handle the credentials the result of calling the
base class implementation is returned. If the plugin fails to authenticate the credentials
for the principal a {{{FailedLoginException}}} is thrown.
+  impersonate:: Calls the impersonate method of the plugin handling the given credentials
and returns {{{true}}} or {{{false}}} if the plugin handles impersonation. If no plugin can
handle the credentials or the selected plugin does not handle impersonation the result of
calling the base class implementation is returned. If impersonation either by the plugin or
the base class implementation fails a {{{FailedLoginException}}} is thrown.
+ 
+ 
+ Because login modules are created for each login request and may keep internal state while
handling the login request, the service API for pluggable login modules defines a factory
interface:
+ 
+ 
+ 
+ 
+ == Pluggable Access Control Manager ==
+ 
+ TBD
+ 

Mime
View raw message