Thanks for the hint, I’ve added it to the roadmap for DAVx⁵:
https://gitlab.com/bitfireAT/davx5-ose/wikis/Roadmap
As you can see, there are a lot of possible enhancements, so maybe this will take while…
My groupdav-server is behind a client certificate authenticated webserver but still needs username/password. I tried using davdroid’s client certificate option and
https://user:password@domain
for the base URL, but that doesn’t work as well
Hey, in fact what we need is both.
First certificate based auth for the SSL connection, then the usual username/password inside the HTTPS “tunnel”.
Is that possible?
The reason for this is that the options of our backend are limited. What we do with Davdroid is to connect to a reverse proxy that allows us to add/mangle stuff that the client sends. In this case we would like to add a client certificate for overall access to the reverse proxy, and then continue as usual with username/password for the actual Caldav/Carddav connection (as it is not possible to have TWO http-based authentications going on one after the other for example).
Well, if you are currently implementing this, then please keep that scenario in mind.
This is more of a “me too” but it would be nice if an implementation for this worked with the system-wide user certificate management.
Den
@diener What do you mean? The client certificates used by DAVdroid are taken from the system-wide user certificate management.
I have the same problem as you. My groupdav-server is behind a client certificate authenticated webserver but still needs username/password. I tried using davdroid’s client certificate option and
https://user:password@domain
for the base URL, but that doesn’t work as well
At the moment, DAVdroid only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.
I recommend to use client certificates for authentication.
I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.
BTW, I cannot reply using firefox 59.0.2. In the webconsole I get:
[composer/drafts] Could not read list of open/available drafts
nodebb.min.js:1:437938
[composer/drafts] Could not read list of open/available drafts
client.js:13:2
TypeError: t is null
Stack trace:
@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:435313
execCb@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:255806
check@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:249946
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252519
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254924
enable/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252394
z/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244494
y@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244056
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:251928
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254924
enable/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252394
z/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244494
y@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244056
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:251928
init@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:249068
c/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254292
storage.js:63:2
localStorage failed, falling back on sessionStorage
storage.js:64:2
TypeError: t is null
Stack trace:
@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:435544
execCb@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:255806
check@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:249946
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252519
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254924
enable/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252394
z/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244494
y@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244056
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:251928
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254924
enable/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:252394
z/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244494
y@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:244056
enable@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:251928
init@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:249068
c/<@https://forums.bitfire.at/assets/nodebb.min.js?v=pr9stu5o9ec:1:254292
storage.js:77:3
sessionStorage failed, falling back on memory storage
storage.js:78:3
TypeError: localStorage is null[Learn More]
resize.js:1:238
Source map error: SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
Resource URL: https://forums.bitfire.at/assets/src/modules/composer/resize.js?v=pr9stu5o9ec
Source Map URL: node_modules/nodebb-plugin-composer-default/static/lib/composer/resize.js.map[Learn More]
@xyzzy said in Support for SSL client certificate and Basic/Digest at same time:
I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.
It doesn’t remove anything, but it doesn’t use username/password from the URL. At the moment, DAVdroid unfortunately only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.
BTW, I cannot reply using firefox 59.0.2. In the webconsole I get:
I’m typing this reply with Firefox 59.0.2 (MozillaFirefox-59.0.2-lp150.1.6.x86_64 from OpenSUSE Leap 15 Beta). If you can find out what the problem is, it would be kind if you could report it to NodeBB directly. We’re currently using NodeBB 1.8.2 (latest release) without modifications.
@rfc2822 Any update on using client certificates with username and password authentication? I’m in the same situation as above, where the reverse proxy requires the client certificate and the DAV server requires username and password authentication. There doesn’t seem to be a way to disable the username and password authentication for any of the implementations I’ve tried (NextCloud, Radicale, Baikal).
@dg10a You could write an authentication plugin for Radicale, which authenticates against the certificate: https://radicale.org/plugins/
Not sure I’m following. The certificate is authenticated at the reverse proxy level, before any traffic reaches Radicale.
@dg10a You could then pass the authentication info to Radicale (simply said: pass /originalPath?$originalArgs&authenticatedUser=MyUserFromCertificate
) and evaluate it with a custom plugin
@rfc2822 I guess the point still is that you can use either a certificate or HTTP basic auth, not both.
@marki Yes, these are two different topics:
@rfc2822 Hmm, from what @dg10a wrote (“There doesn’t seem to be a way to disable the username and password authentication…”) I guess this was about 1)?
As far as 2) goes that would only work if the backend CalDAV server supported some mode where you could just tell it “trust me, I’m user XXX, go”. In that case you would use the reverse proxy as a trusted source and just send the required data somehow using HTTP as you have shown. Albeit, not all CalDAV backends support such a thing.
@dg10a #1 is also more secure. First, it authenticates the device (certificate), then it authenticates the user (password). It would be so elegant. ^^
Now I’m not sure what you’re planning to do. I hope you’re still using an encrypted private key and you’re not just asking for no credentials anymore. If you’re doing that, you might as well just save the password.
@marki I was asking about disabling user/pass authentication to be able to test client certificate authentication in the current DAVdroid build. My ideal setup would be as you described, with the device authenticated via certificate and the user via password.
I have created a new thread for that.
Technically, username/password together with client certificates are not that hard. As always, the UI part is more difficult.
All these possiblities:
should be grouped in a way that makes sense (and is “material”), and for the most common methods (printed bold above), there should be as little distraction as possible (no talking about strange “certificates” etc. when you choose one of these two methods). Maybe hide everything then 1+2 behind some “expert” button?
It should be possible to change the credentials in the account settings, like now. Maybe it would make sense to change the authentication method, too? For instance, could you change from username/password to client certificates without password at all? In this case, the username/password field would have to disappear.
I guess the whole login activity should be re-worked and probably “materialized” (colors, images, whatever). Would be nice if someone could provide a good draft for the login fragments
You could probably combine everything like this:
By default, only “password” is checked. Like that you can choose to either have no authentication at all (“password” is unselected), one of the two, or both (“password” as well as “client certificate” are selected).
Depending on what is selected, you either show both password and certificate selection at the top (below whatever connection method is chosen), one of the two, or nothing at all (email or username/URL only).
Maybe you could hide the entire lower part “Authenticate using” behind some “Advanced mode” button.
Remains OAuth. I’m not sure about that, would have to read up on how it works first (what data is needed to connect).