we are kind of abusing some features to enable SeafDAV access in our federated Shibboleth setup:
We manually (re-)set the password within Seafile for the user and therefore allow him to login with a WebDAV client.
Now I stumbled upon a minor problem: The password reset email gets send to the primary account email (which in our case is not a real email address but an EPPN) instead of the contact email of the profile.
Maybe you can fix that by using the contact email if available.
I’m interested to use Webdav with Shibboleth configuration too.
I’m not sure to understand, you set the user password (shibboleth one) in Seafile password databases manually ? What happen when the user change his Shibboleth password ? You didn’t automate anything ?
Is there another way to use WebDav and Shibboleth ? without copy password everywhere… I think it’s gonna be very “tedious” in long term and with a lot of user…
Maybe there’s other solutions, for example in GItHub, I think we can get a token by web interface and use it in command line, this solution can be an option ?
Exactly, we just offer this as a hacky solution on user’s request and explain to them carefully that they are setting an independent password. (This is done similarily by GitLab, when you use SSO authentication there, you still get prompted to set a local password for HTTPS push).
I don’t think there is a usable solution. Maybe using a token and sending it by header could work for people using curl or wget, but won’t be supported by any more fancy clients, e.g. smartphone apps.
WebDAV could of course accept tokens instead of password. It would be like app passwords in e.g. Gmail. It would be the best if there would be a special token only for WebDAV.
The access log of the professional edition could then also log which token was used (I’m not sure if WebDAV is logged at all so far).
