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 <anchela@adobe.com <mailto:anchela@adobe.com>>
>
> 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!
>
>
|