@Justin With "ACLs don't work through WebDAV" i mean that managing them through webdav access is not supported. I have no idea if ACLs can be setup getting via JNDI and then they are effective then for each authenticated user (that seems to be what Angela mentioned in her response).
@Angela Sorry for the confusion about authentication and authorization maybe my last post mixed the things a bit up. This time i will try to separate this two topics more: *Authorization* About the solution you mentioned to avoid Webdav to manage authorization i guess that CRX obtains the repository through JNDI and then it can manage ACLs, ACEs and so on... The settings done through this solution are effective then to the access through Webdav, isn't it? (e.g.: set through CRX ACLs for a node that allow Peter to read and write only that node down, no read or write permissions on any other. Then Peter authenticates himself in through Webdav and he will perform read / write operations on such nodes uneventfully and will get authorization exceptions if he tries to do any operation on any other node). By the way, is user management (creating, updating, deleting...) fully supported through Webdav or should be carried up getting the repository through JNDI as well? In case this is not supported i suppose it can be carried through the circumvention described above. Thank you (both) very much for your attention! 2012/4/12 Angela Schreiber <[email protected]> > hi francisco > > > regarding security on Webdav accessed JR repositories i would like to hear >> expertise opinions as access control is very permissive by default >> > > that depends on your configuration. in the default jackrabbit setup > you can configure the AccessControlProvider such that it doesn't > setup any permissions by default. in that case only admin had > access to the repository. > > > (and ACLs don't work through Webdav). >> > > that's correct. > > > About authentication, what would be necessary in order to authenticate all >> kinds of access?? >> > > that should already be the case. and again there are configuration > options with the webdav server that define how request without > any kind of user identification should be dealt with (it's called > missing-auth-param or similar) > > > (i.e.: opening a session with read / write permissions >> through Java code and access through the web browser too). >> > > sorry. you lost me here... authentication is a different story > than authorization. you may allow access for GuestCredentials > (such as the default login module does) but it might well be > that this session is not able to read anything. > > > Would suffice creating a custom access manager? >> > > i don't think this is required. > > > I did it previously but i don't know if >> this is the best practice... >> > > that maybe depends a bit on your use-cases... > > > Any orientation (or expertise opinion) about the right way of providing >> authentication and authorization on webdav accessed JR repositories will >> be >> appreciated. >> > > what we did at adobe (former day) to circumvent the missing access > control management in the webdav layer: we have a separate repository > browser (crx) that allowed to edit access control from a browser, so > we don't have to do this in the webdav access. > > alternatively, you may want to provide patches that would help > us implement RFC 3744 in the standard webdav implementation (the simple > server)... your contribution was definitely welcome. > > kind regards > angela > > > Thanks in advance for your time! >> >
