hi francisco
@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?
sure. the access control is stored and enforced in the repository
irrespective on how you access that repository.
(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?
i am inclined to say: the latter.
you can have some sort of user management since the sessions
importXML has separate handling for user (and for access control).
but that's not what i would call user-friendly and what i would
look for when i wanted to do user-administration with webdav.
again: patches welcome
kind regards
angela
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] <mailto:[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!
