External pre-authentication (instead of oauth/oidc)

[netchild]

Hi,

I've read that oauth (or oidc) doesn't seem to be on the plate as an alternative to the existing http auth. What about an optional external pre-authentication method?

What I have in mind is a way to specify for the server to not ask for the http auth (--auth-mode=pre --enable-auth) and to specify which http header is providing the username (--http-user-header=ABC), and the calibre server would blindly use the username from this header without any password. This way a tool in front of calibre (be it apache/nginx/whatever, or an oauth2-proxy) could then authenticate the user and provide access to various libraries via --manage-users (the password part is then useless/ignored in this mode).

To illustrate it a bit more:
- user goes to https://my.calibre.site/
- the webserver/reverse-proxy at my.calibre.site does the TLS handshake, sees the user is not authenticated, and provides a login page to the user without doing any request to the calibre server
- once the webserver/reverse-proxy has authenticated the user, it sets "X-My-Private-HTTP-Header: the-user-name" and makes a request to the calibre server
- the calibre server was configured to not send an http auth required but to use the username from the X-My-Private-HTTP-Header to check the access permissions versus the userdb (without validating/requesting any password itself) and provide only access to those libraries which the user is allowed to see

As an example, the oauth2-proxy on github has the option (https://oauth2-proxy.github.io/oauth...tion/overview/) "pass-user-headers" which then sets the http headers X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email and X-Forwarded-Preferred-Username to upstream after authentication. Calibre server could then be configured to use one of those to match against the calibre-internal userdb.

As side notes:
1) Calibre could gain free group management this way (free = no group-management code needed inside calibre), by entering group names inside calibre in the place of user names. By providing a group name by the preauthentication solution in the header field instead of the username the user would be still be authenticated based upon his private password/token, but calibre would only the see group name, match that group name against the username in the userdb, and give access to some of the libraries based upon the --manage-users settings for this username.
2) Depending on what is used to preauthenticate against, there is even free self-service password management/recovery. For some family members this is quite handy sometimes...

Thanks for considering this feature request.

[kovidgoyal]

Just add the http basic auth header in your frontend.

[netchild]

oauth2-proxy has an option to pass a http basic auth header. It also allows to set a generic pw for this header, but it does not use the "preferred username" for the user part. It uses the userid of the authentication provider, and this is an UUID and not an username.

While it is technically possible to add this UUID as an username inside calibre (it works), this is very ugly. Having some readable username instead of a string of random numbers (e.g. 38737660a-df157-2c82-a93c-0c223d6389dc) is much more convenient when configuring access to libraries.

[kovidgoyal]

I have no clue what oauth-proxy is but surely it has some way to control what goes into the auth header or its basically useless. Maybe find a better proxy.

[netchild]

Originally Posted by kovidgoyal

I have no clue what oauth-proxy is but surely it has some way to control what goes into the auth header or its basically useless. Maybe find a better proxy.

oauth2-proxy is a tool in the middle of a webserver and a backend (like calibre) to authenticate users. oauth2 / oidc are authentication protocols which require an authentication service as a backend. oauth2-proxy is one of the few open-source solutions in this regard, and of all the OSS solutions I've seen, it is the most capable one.

It is not a normal proxy, it is an authenticator-solution with a pass-through to the real application after successful auth:
user -> webserver -> oauth2-proxy -> sees no auth -> contacts the auth-backend (could be google, github, in my case my own oidc provider which provides multi-factor authentication like google does -> back to oauth2-proxy after successful auth -> pass-through to the backend application (calibre).

oauth2-proxy is mainly for applications which do not have an authentication or user management. And the OIDC / oauth2 single-sign-on possibility is something which is used in a lot of open source solutions. OSS webmail systems (roundcube / nextcloud), photo galleries (piwigo), personal document management systems (paperless-ngx), wordpress, wiki software and much more support oidc / oauth2 either natively or via plugins additionally to their in-build user/auth parts. Some don't, and there oauth2-proxy comes into play.

What oauth2-proxy puts into the username field makes sense, it is the uniq ID of the authentication backend which can not change. The "preferred username" or the email address which the backend provides too can be changed by the user, the ID can't. From an identity and authentication management perspective this is the right thing to do (my day to day job is in IT security, so I have a glue about this topic).

This may seem overkill to you, but it is not overkill to me (my family recipes, family photos, family documents are all protected by the single-sing-on solution). This solution regarding authentication is similar to what calibre is in the ebook world, a powerful and expert solution.

Do I understand you correctly, that you do not consider your powerfull, expert and outstanding ebook management software to be worth to be integrated into an existing, powerfull and expert authentication solution?

[Quoth]

OAuth isn't as good as you think. It's about big corporations tracking and controlling you.

I only use it for desktop email client accessing gmail accounts and only because Google/Alphabet forces this. It's adding nothing except annoyance.

[kovidgoyal]

Again, if your oauth proxy software cannot maintain a mapping between whatever uuid it gets from the authentication backend to real usernames and use those real usernames in an auth header, then you need to find a better proxy.

Or write a simple proxy yourself to do that. One that sits in between oauth2-proxy and calibre and rewrites the authentication header.

[netchild]

Originally Posted by Quoth

OAuth isn't as good as you think. It's about big corporations tracking and controlling you.

How are they tracking and controlling me if I use oauth internally?
Internally = an OSS auth backend (keycloak) which I host on my own hardware which is accessed by OSS frontend software I host on my own hardware, and which can not talk at all with the outside (firewall).

How are they tracking and controlling a corporation which uses commercial oauth software (Okta, OneIdentity, ...) internally for frontends which are hosted internally, which are running on local hardware and firewalled to the outside?

Answer to all above: they don't.

Again, you are mixing up an identity provider implementation (Google, Azure, ...) with the oauth protocol. If you don't use it to get tracked by google, don't use it with anyone except google. Most sites which allow to login with your google account, or facebook account, or whatver identity provider they support, also offer a local login possibility. To my experience this works well (when I can login locally, I do that, so I have experience in this regard).

[netchild]

Originally Posted by kovidgoyal

Again, if your oauth proxy software cannot maintain a mapping between whatever uuid it gets from the authentication backend to real usernames and use those real usernames in an auth header, then you need to find a better proxy.

Or write a simple proxy yourself to do that. One that sits in between oauth2-proxy and calibre and rewrites the authentication header.

Most software has a pre-auth mode where they accept a particular http header or a configurable one as username. That's the reason why I asked here for this kind of feature.

Alright, I understand that you don't want to consider this as a possible feature for calibre and that I need to find a more complicated way.

Thanks for the time you spend answering.

[Quoth]

Originally Posted by netchild

How are they tracking and controlling me if I use oauth internally?

They don't. But the only reason to use OAuth is because someone else is forcing it on you. It's pointless if you are in charge. There are loads of less complex solutions, some may even be better security.

[netchild]

Originally Posted by Quoth

They don't.

You are contradicting yourself.

Originally Posted by Quoth

But the only reason to use OAuth is because someone else is forcing it on you. It's pointless if you are in charge. There are loads of less complex solutions, some may even be better security.

I'm open for those less complex OSS solutions which offer SSO, multi-factor, and provide better security, and at the same time have support in wordpress, django, webmail solutions, IMAP, picture galleries, wiki software and so on. Please provide some examples, so far most of the OSS solutions I've found fail either on the multi-factor part (more detailed: on webauthn), or on the integration part.