Hi, I am just catching up on this thread, since it all happened when I was sleeping, and wanted to share some of my many past misdemeanors and mistakes.
I too once had a need for Time based and Rule based ACLs associated with JCR based paths. I did this rightly or wrongly by extending the Jackrabbit access control managers. With hindsight, I think that was the correct way of doing it since it put all the AuthZ in one place and didn't open bypass mechanisms. I also added a second repository more suited to the use case where we needed millions (term used loosely) of child nodes, but didn't care about versioning the structure. Initially it was based on Cassandra and I had to implement path based ACL security ontop of Cassandra. I should have used the existing ResourceProvider mechanism, but didn't because I needed users to be stored in that repo (millions of users, and I mean millions this time), so I extended the UserManager area of jackrabbit so it got all its users from this alternative store. I think that was a mistake and made upgrades to Jackrabbit really hard. We also had all sorts of problems with Resources from one repository context appearing in the other repository context. The other major issue was Sessions. We had to always run 2 sessions the Jackrabbit Session delegating to the other repo Session for user information. The third and final past experience relevant to this discussion is a utility to bypass all security. In this instance the feature was called a "SecurityAdvisor" and was both incredibly useful and a complete nightmare from a QA point of view. In the project in question (not Sling based), once the pandoras box was opened, it could not be closed. Essentially it allowed developers to set a switch to bypass ACL evaluation within an enter exit pattern. They (myself included) did frequently making QA a costly and lengthy process at times. With the benefit of hindsight, imho this feature should never have been added. I am not 100% certain I understand the outcome of this thread, but if I can share anything, in the context of Sling (please): 1. Make security the responsibility of the ResourceProvider implementation, or in the case of JCR the ResourceResolver impl (ie Jackrabbit itself) 2. Don't provide mechanisms to bypass security by exposing anything above the ResourceResolver API that can weaken security. (Strengthening it is Ok IMHO, but slightly dubious as its too easy to bypass where not applied) 3. If an enhanced ACL environment is needed, extend and work with the core repository team to provide that, or implement your own ResourceProvider to cover that use case. Sorry if this is all a little late and contradictory, but in my defence the thread started a little over 15h ago. Ian BTW, I say "in the context of Sling" since Sling is special in making everything a Resource which pushes the security assertions on that resource lower down the stack. Other frameworks like Django and Rails often prefer to make those assertions at the URL resolution layer, and effectively make the space blow that all admin access, effectively a free for all. Sometimes additional assertions are scattered throughout the code based. There is nothing wrong with this approach, but its not intrinsically secure, and relies on a high level of vigilance from all developers involved. As soon as there are multiple routes to access information, or perform an action, the application leaks. I can (offlist) reference sound jaw dropping examples. On 7 March 2013 04:31, Alexander Klimetschek <[email protected]> wrote: > On 06.03.2013, at 16:22, Carsten Ziegeler <[email protected]> wrote: > >> Just to throw in some more ideas :) what about a decorator for >> resource providers? This would also solve the use case of easily >> adding additional checks to resource providers who don't have their >> own access checks without needing to code this into each and every >> provider. > > +1 to the ResourceProviderDecorator - that keeps it where it belongs, doesn't > sound like security and is still a simple interface. > > On 06.03.2013, at 16:45, Mike Müller <[email protected]> wrote: > >> I don't think so. If someone changes a resource it's not important from which >> provider the resource is provided. In addition with the methods revert and >> commit >> on the ResourceResolver we could implement transactionality over more than >> one >> provider (even if I don't think we want to do that). > > I am not sure if moving resources from one provider to another is a good idea > (even if transaction-less)... > > Cheers, > Alex
