jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Security on JR through Webdav
Date Wed, 18 Apr 2012 22:22:02 GMT
 @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 <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!
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message