The requirement seems strange to me, because the WebDAV interface (like the REST interface) are just another way of accessing the repository. You're basically saying that when accessing the repository via WebDAV the security should be different than when accessing the repository via another interface (your own webapp in this case).
Nonetheless, assuming everything runs in EAP (ModeShape, ModeShape's Webdav application and your custom webapp), one thing you can try is to use different security domains:
- ModeShape's WebDAV web application has a hardcoded <security-domain>modeshape-security</security-domain> (in jboss-web.xml). So you would configure this security domain in EAP to use LDAP (like you've described above)
- Define an additional non-LDAP security domain in EAP. For example: <security-domain name="modeshape-internal-security" cache-type="default"> either with your own custom login module with with some built-in login module that "plays nice" with the LDAP one (see below). After that, you configure the repository to use this security domain: <repository name="sample" security-domain="modeshape-internal-security"/>
The way I see it, you have 2 options for the "modeshape-internal-security" domain:
- try to see if there's a built-in implementation in EAP for a pass-through login module (e.g. UnauthenticatedIdentiy) - by pass-through I mean that whatever is already authenticated & stored as a principal is sent down unchanged. In the case of your own (internal webapp) you need to decide how any action coming from the webapp should be authorized (e.g. always use "admin")
- implement your own custom login module(Chapter 10. JBoss Login Modules) and take into account the fact that the there may already be an authenticated principal (coming via the WebDAV webapp).
The important thing to remember is that for the repository to function properly (assuming anonymous authentication is not allowed), the authenticated principal (or an "anonymous" call) needs to make use of the built-in roles: admin, readonly, readwrite
It works! I had no idea webdav interface has hardcoded security domain name. That was the key.
Solution: like has Horia explained. 2 security domain. modeshape-security is used by webdav interface, 2nd one defined e.g. modeshape-internal-security will be used by repository <repository name="sample" security-domain="modeshape-internal-security"/>.
Why such a configuration? It might sound strange to have 2 level of access to the same resource but that's our current requirements. Besides it's not practical to authenticate and authorize web client based on LDAP. With webdav protocol and external users - it's has more sense.