Enable SSO for calibre server

jgoguen · 01-03-2025, 01:45 PM

I have almost everything I host at home set up behind SSO. Calibre, for valid reasons I don't want to interfere with, doesn't work well with this because it needs HTTP Basic/Digest auth. That needs the Authorization header, but there isn't a safe way to get the password (or any user-specific secret) to generate the Authorization header in the SSO auth flow. What I've done so far to let me keep SSO auth is disable calibre auth and allow unauthenticated local writes. Which I don't really like, but I am confident in my ability to adequately protect the running calibre instance, but if I can let the SSO auth flow tell calibre what the authenticated user is I could start thinking about allowing other SSO users access to calibre with reduced permissions.

Would it be acceptable to you to add a server flag to trust REMOTE_USER? Maybe with some additional check like you have to configure the front-end proxy to also send some kind of a 'X-Calibre-I-Know-What-I-Am-Doing: dogscholar' header with a static or configurable or generated value. The flow I see happening would be something like:

- A default-disabled checkbox in content server settings (corresponding to maybe --trust-http-remote-user for CLI use) has to be turned on, with a warning that misconfigured proxies could allow bypassing calibre auth
- When calibre processes a request, if REMOTE_USER (and the check header if wanted) is set it proceeds as if auth for that user was successful
- If the user isn't in the user DB, or if we want a check header and it's missing or wrong, calibre server should fatal with HTTP 403
- If REMOTE_USER is not set, request HTTP Basic/Digest auth as it does today

I don't want to interfere with the existing login process since I know calibre server needs to also work with non-browser clients. I think this lets us have both, the existing login process is available without interference and anyone who wants to set up auth using the front-end proxy's auth mechanism can also do so without blocking non-browser clients from also connecting. It's just a bit of extra work to have both proxy and non-browser auth since you'd have to manage credentials in both the proxy back-end and calibre user DB, but I feel like that's an acceptable trade-off. I also don't see this being used by a whole lot of people so I understand if you're OK with the idea but don't want to prioritize it. It won't be soon, but if something like this is acceptable to you I don't mind working on a PR to add it in once I sort out some nasty conversion bugs in my KePub plugins.

kovidgoyal · 01-03-2025, 09:27 PM

HTTP Auth is already header based, if you have the ability to generate headers in your frontend, why not jsut generate the HTTP Auth header itself, in basic form its pretty trivial to do and you dont need digest if your server is not directly exposed to the internet.

jgoguen · 01-03-2025, 10:36 PM

That needs the Authorization header, but there isn't a safe way to get the password (or any user-specific secret) to generate the Authorization header in the SSO auth flow. Or, at least, the part of the flow I can actually access and set headers in, in the front-end Caddy server acting as the reverse proxy.

Authelia devs have been pretty clear that they have no intention to add a way to send an Authorization header generated from the user's actual credentials, but they might be open to considering an implementation where Authelia generates the password to set in the back-end service. But I wouldn't hold my breath waiting for that to happen. Caddy can set any header, including Authorization, but to generate one based on user-specific details not present in the HTTP request itself (or to take "user:static_password" and Base64-encode it) isn't available in Caddy configs.

kovidgoyal · 01-04-2025, 12:30 AM

A default off option to read user from specified header is fine for me, PR welcome, though if I were you I would just put a simple reverse proxy in 50 odd lines of python between the calibre server and your frontend that adds the authorization header based on REMOTE_USER and then forwards to calibre.

But as I said I am ok with such an option provided I dont have to do the work to implement it. You choose whichever path is less work for you.

01-03-2025, 01:45 PM	#1
jgoguen Generally Awesome Person Posts: 1,100 Karma: 2191133 Join Date: Jan 2013 Location: /dev/kmem Device: Kobo Clara HD, Kindle Oasis	Enable SSO for calibre server I have almost everything I host at home set up behind SSO. Calibre, for valid reasons I don't want to interfere with, doesn't work well with this because it needs HTTP Basic/Digest auth. That needs the Authorization header, but there isn't a safe way to get the password (or any user-specific secret) to generate the Authorization header in the SSO auth flow. What I've done so far to let me keep SSO auth is disable calibre auth and allow unauthenticated local writes. Which I don't really like, but I am confident in my ability to adequately protect the running calibre instance, but if I can let the SSO auth flow tell calibre what the authenticated user is I could start thinking about allowing other SSO users access to calibre with reduced permissions. Would it be acceptable to you to add a server flag to trust REMOTE_USER? Maybe with some additional check like you have to configure the front-end proxy to also send some kind of a 'X-Calibre-I-Know-What-I-Am-Doing: dogscholar' header with a static or configurable or generated value. The flow I see happening would be something like: - A default-disabled checkbox in content server settings (corresponding to maybe --trust-http-remote-user for CLI use) has to be turned on, with a warning that misconfigured proxies could allow bypassing calibre auth - When calibre processes a request, if REMOTE_USER (and the check header if wanted) is set it proceeds as if auth for that user was successful - If the user isn't in the user DB, or if we want a check header and it's missing or wrong, calibre server should fatal with HTTP 403 - If REMOTE_USER is not set, request HTTP Basic/Digest auth as it does today I don't want to interfere with the existing login process since I know calibre server needs to also work with non-browser clients. I think this lets us have both, the existing login process is available without interference and anyone who wants to set up auth using the front-end proxy's auth mechanism can also do so without blocking non-browser clients from also connecting. It's just a bit of extra work to have both proxy and non-browser auth since you'd have to manage credentials in both the proxy back-end and calibre user DB, but I feel like that's an acceptable trade-off. I also don't see this being used by a whole lot of people so I understand if you're OK with the idea but don't want to prioritize it. It won't be soon, but if something like this is acceptable to you I don't mind working on a PR to add it in once I sort out some nasty conversion bugs in my KePub plugins.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
How do you enable HTTPS on the content server?	Inukami	Server	17	03-27-2020 08:15 PM
Server Upload error (404) w/ enable-local-write	ejwright	Server	6	11-23-2019 10:15 AM
calibredb does not work with content server running (content server is using --enable	Irvin	Server	3	01-08-2019 02:47 AM
How to enable HTTPS in Ubuntu server?	yourrable	Server	8	12-23-2018 03:58 PM
Headless Calibre-Server enable "Wireless device connection"	mohataj	Devices	11	10-11-2012 05:39 AM

01-03-2025, 09:27 PM	#2
kovidgoyal creator of calibre Posts: 45,345 Karma: 27182818 Join Date: Oct 2006 Location: Mumbai, India Device: Various	HTTP Auth is already header based, if you have the ability to generate headers in your frontend, why not jsut generate the HTTP Auth header itself, in basic form its pretty trivial to do and you dont need digest if your server is not directly exposed to the internet.

01-03-2025, 10:36 PM	#3
jgoguen Generally Awesome Person Posts: 1,100 Karma: 2191133 Join Date: Jan 2013 Location: /dev/kmem Device: Kobo Clara HD, Kindle Oasis	That needs the Authorization header, but there isn't a safe way to get the password (or any user-specific secret) to generate the Authorization header in the SSO auth flow. Or, at least, the part of the flow I can actually access and set headers in, in the front-end Caddy server acting as the reverse proxy. Authelia devs have been pretty clear that they have no intention to add a way to send an Authorization header generated from the user's actual credentials, but they might be open to considering an implementation where Authelia generates the password to set in the back-end service. But I wouldn't hold my breath waiting for that to happen. Caddy can set any header, including Authorization, but to generate one based on user-specific details not present in the HTTP request itself (or to take "user:static_password" and Base64-encode it) isn't available in Caddy configs.

01-04-2025, 12:30 AM	#4
kovidgoyal creator of calibre Posts: 45,345 Karma: 27182818 Join Date: Oct 2006 Location: Mumbai, India Device: Various	A default off option to read user from specified header is fine for me, PR welcome, though if I were you I would just put a simple reverse proxy in 50 odd lines of python between the calibre server and your frontend that adds the authorization header based on REMOTE_USER and then forwards to calibre. But as I said I am ok with such an option provided I dont have to do the work to implement it. You choose whichever path is less work for you.

Advert