Thanks to all for the inputs. We will start with a custom LoginModulePlugin & AccessManagerPlugin.
Christophe 2009/9/15 Ian Boston <[email protected]>: > > On 15 Sep 2009, at 00:59, Christophe Lombart wrote: > >> Hi, >> >> In our Sling application, we would like to externalize the user/group >> management. >> I'm not the jackrabbit security expert but it seems that should be >> possible with a custom UserManager. I think it is not possible to plug >> my custom UserManager implementation as a bundle. >> >> So, what is the best approach for that kind of externalisation ? Do I >> have create my own JackrabbitSecurityManager ? > > > Creating or extending the default JackrabbitSecurityManager impl will give > you complete control over the various other security related classes that > are required by Jackrabbit. > I have also extended/reimplented that class so that I could replace the > AccessControlProvider and other core items. The only difficulty with doing > this is the default JackrabbitSecurityManager implementation is relatively > complex and has some package protection, so I had to repackage/extend the > standard jackrabbit server bundle in order to modify the behavior. > > If you decide that you want to get near to externalizing AuthZ as apposed to > AuthN, then one thing that becomes relevant is the performance of the AuthZ > system, which is highly optimized and is unlikely to work with external > sources of information unless some care is taken. For instance, the > principals associated with a user are resolved at the session login which in > sling is pooled with user affinity (ie the same session can be retrieved > from the pool with some state on subsequent requests), so if you modify the > AccessControlProvider (or reimpliment it) then you will need to make certain > that each ACL resolution does not result in a network operation, as > Jackrabbit will certainly crawl if that happens. > > The same is true, to a lesser extent with the UserManager which needs to > resolve group membership questions. If these result in masses of network > operations, Jackrabbit will also crawl. > > Rather than replace the highly efficient UserManager and > AccessControlProvider, we have opted to create patched versions that use the > default functionality for many of the operations, but provide extension > hooks for integration with 3rd party data sources where necessary. I > recently updated some of the documentation associated with the project at > [1],[2] which may give you an insight into the approach, with code at [3]. > This is not core Sling or Jackrabbit and represents a patch to both, which > cant easily be accommodated in core Jackrabbit. > > Ian > > [1] > http://confluence.sakaiproject.org/display/KERNDOC/Sling+AuthZ+Implementation+Plan > [2] > http://confluence.sakaiproject.org/display/KERNDOC/Configuring+Users+and+Groups > [3] > http://github.com/ieb/open-experiments/tree/master/slingtests/osgikernel/bundles/server/ > >> Can you just let me know if I'm in the good direction ? >> >> thanks >> Christophe > >
