Support for SSL client certificate and Basic/Digest at same time
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:
- Use two authentication methods (client-certificate authentication and user name/password) at the same time with DAVdroid
- How to use client-certificate authentication with a common server, like Radicale
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.
@rfc2822 Thank you, I will look into writing a plugin. However, I think #1 is my preferred solution as it is server agnostic (as @marki mentioned) and does not require the reverse proxy to treat particular applications differently.
@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:
- Service discovery (email) + password
- URL (+ service discovery) + password
- Service discovery (email) + client certificate
- URL (+ service discovery) + client certificate
- Service discovery (email) + password + client certificate
- URL (+ service discovery) + password + client certificate
- In the future: OAuth
- Maybe: no authentication at all (yes, this was also requested)
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
marki last edited by marki
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).