I am trying the Webdav plugin for working with files in MS Office. Everything works well except that each time you open a docx file or any other MS Office format, authorization is requested. It is very uncomfortable.
It turns out that the implementation of Webdav in Cuba Platform differs from the implementation in SharePoint, namely, I cannot refer to Webdav as a network drive, therefore, the NTLM authorization of Windows does not work. I began to study what can be done and found the following
How do I avoid login dialog when using Microsoft Office?
Microsoft Office applications always ask for the authentication when used with Basic and Digest authentication. If you check āRemember my passwordā checkbox it will still display the login dialog, but the username and password will be already filled in, so you just click āOKā.
Here are some options to consider to totally avoid login dialog with Microsoft Office:
Use NTLM or Kerberos authentication. By default MS Office will ask for credentials only 1 time during first document access. The login dialog default configuration can be changed in Active Directory settings.
Cuba Webdav use Digest authentication. Do I understand correctly that the only sure way to get rid of the authorization window is to implement authorization through NTLM (for example Jespa) or Kerberos? Please tell me if there are any other ways to fix the problem?
I think you right, there are hardly any other ways to get rid of this window.
Authentication is required before accessing the document. And the only way to perform it without MS Word login prompt is to implement transparent SSO authentication (for example, via Kerberos, as you mentioned).
You can take advantage of the spring-security-kerberos component and integrate its authentication mechanisms to the WebDAV dispatcher servlet. In the add-onās documentation section about Digest auth you can find steps to replace default WebDAV dispatcher config.
We also found some errors in the Catalina.out log:
Error creating bean with name 'org.springframework.security.filterChainProxy': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: A universal match pattern ('/**') is defined before other patterns in the filter chain, causing them to be ignored. Please check the ordering in your <security:http> namespace or FilterChainProxy bean configuration
it seems thereās a kind of conflict with another security configuration in Spring.
Do you have any clue to how to solve the situation and avoid the password prompt in MS Office?
Digest auth, as well as the basic auth, requires user to enter credentials. The difference is in the algorithms: basic auth uses base64 encoding, while digest auth applies hashing and hence creds are not sent over the network as plaintext, which allows you to use non-SSL connection (although, there are other pros and cons you should be aware of). Never mind, both approaches will not allow you to get rid of the login prompt in MS Office. The only way I can see is to implement SSO auth, as i mentioned in my previous post.
I think the problem here is that you have defined 2 WebDAV dispatcher configs by putting + prefix in the webdav.dispatcherSpringContextConfig property value. If yes, please, remove the plus sign. If no, try performing gradle clean undeploy task and then deploy your application again.
Hi @shalyganov, thanks for your answer.
We really want to adopt WebDAV in our organization but the feature that Office applications doesnāt asks for password is a must.
So, excluded Digest Authentication (I though it worked in another way) the only viable solution is SSO with Kerberos. Iām not expert at all in this, can you give us some help how to use and configure this in Cuba + WebDAV Application?
With this feature, every time a document will be opened in an office application, the user will be checked against AD/LDAP, right? So also the Cuba Application must be configured with AD/LDAP Authentication.
Currently, there are no demo-projects demonstrating how to integrate Kerberos SSO to Cuba applications. Nevertheless, spring-security-kerberos component is an extension to Spring Security and we have involved Spring Security authentication mechanisms in the SAML-addon and also in the WebDAV-addon (corresponding beans are declared in the webdav-dispatcher-spring.xml file). So you can use these projects as examples.
As for Kerberos, there are well-written articles on Baeldung: link1, link2.
If you want to implement Kerberos only for a transparent authentication in MS Office, I think you donāt need to implement it for the standard login page as well. In this case you only need to implement Kerberos auth in the WebDAV dispatcher servlet. The problem here is that Kerberos user principals have their own naming format: user@DOMAIN.COM and you will need to correlate Cuba users with users in AD/LDAP somehow.
In case you want to go further and implement Kerberos auth for the Cuba login page as well, you can follow this guide.
Their main goal is to enable Office integration, without auth prompt or at least once only, for both internal (intranet) and external users (extranet/internet).
Do you think itās possible in any way?
Being Kerberos in AD tied with the domain, this wonāt work for extranet users, accessing from personal devices not joined to the domain (plus they donāt want to use VPNs or RDP).
Do you see alternatives? Maybe an external Kerberos server (not AD) used by both intranet/extranet users to authenticate against WebDAV? (and that should also be kept in sync with CUBA users in some wayā¦)
Iāve never used Kerberos outside of AD, but maybe you have previous experience with such setup.
You right that approach with the Kerberos auth is not suitable for the case with external users. The main reason to use Kerberos is to achieve a transparent authentication, but itās just not possible for users outside a domain.
Probably the option 2 is not easy to implement in Java (thereās a ready-made server side implementation for .Net, obviously).
So what about 1 (cookies auth) and 3 (URL auth)?
They seem both achievable, probably the latter (URL auth) being the easiest one.
This implies that anyone having the document URL has R/W access to it, but if you tie the token with the user session this can be mitigated (that is the auth token embedded in the URL is valid only as long the session is valid).
The solution with URL auth seems achievable, although, apart from authentication implementation, it will require changes in links generation logic. While an approach with cookies auth needs more analysis.
Iāve created a ticket for this problem.
