On 23 Jan 2010, at 15:11, Felix Meschberger wrote: > Hi, > > On 23.01.2010 10:17, Ian Boston wrote: >> Hi, >> This may be a non starter for Sling, but I am seeing a need to reuse the >> pattern used by the PluggableLoginModule and the >> PluggableDefaultAccessManager. >> >> I need to re-use that pattern on the PrincipalManager and the UserManager so >> that I can associate a Sling instance with externally held user objects and >> not have to push all the user information into Slings internal UserManager. >> >> At the moment this is just at the planning stage, and I havent written any >> code, but it would mean replacing the standard DefaultSecurityManager that >> comes with Sling with a modified one (PluggableDefaultSecurityManager) that >> instances PluggablePrincipalManager(s) and PluggableUserManager(s). >> >> Firstly: >> WDYT? > > Basically a good idea, I am sure. > >> Secondly: >> Can you see any problems ? > > Well, complexity ? > >> >> If this is not for Sling, its not a blocker for me as I have customised >> server bundle already with modifications to the ACLProvider and patches to >> group permissions. > > I would like to see this coming in my Jackrabbit 2 Bundelization > work-in-progress: I think, I will try to convert the Jackrabbit Core > library into a bundle and add all the dynamically pluggable stuff > support in there. (I already have a prototype for the PluggableLoginModule)
great. > > We could coordinate this work in the Jackrabbit sandbox [1]. > > WDYT ? yes, although it looks like the PrincipalManagerImp already has PrincipalProviders which covers that area, and the PrincipalProviderRegistry allows registration of providers, so that looks covered. Following the same pattern, there could be an interface AuthorizableProvider, and a new UserManagerProviderImpl that tried the UserManagerImpl and then all registered AuthorizableProvider implementations as appropriate (first match or accumulate depending on the call). This structure would work with the providers in bundles and a service tracker in the central implementations. The only problem I can see (in my naivety) is the Group and User implementations. If the core binds to Impl versions then it will be hard to create custom implementations capable of answering the membership questions. Ian > > Regards > Felix > > [1] http://svn.apache.org/repos/asf/jackrabbit/sandbox/ > > >> >> There is documentation in progress at [1], scroll to the bottom of the page >> where the relevant part is. >> >> Ian >> >> >> 1 >> http://confluence.sakaiproject.org/display/KERNDOC/KERN-504+Groups+Pull+Integration
