Hi Ian, On 24.01.2010 15:14, Ian Boston wrote: > > 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.
Fine. > > 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). I would assume, yes. > > > 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. That *is* a problem, though I assume such hard links would rather be oversight than intent.... So such things will have to be solved. AFAICT internally the Jackrabbit security system works on Prinicipal instances which are gathered during the authentication process. So any setup making this more pluggable should theoretically be properly extensible. Experience will tell .. Regards Felix > > 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 > >
