Feature request: support for external authentication providers

[mpfl]

I would like to work with my siblings to put together a family tree, and Grampsweb looks like the best of the platforms available on the awesome-selfhosted list. Multi user support as well as a modern interface.

Since I self-host other software, I run my own LDAP and authentication system, using Authelia. This lets my family access my various self-hosted services and need to maintain only one user account for all of them.

Authelia can handle authentication in two ways:

1. Reverse proxy header authentication: if someone tries to access Grampsweb without logging in, the reverse proxy provides an Authelia login page instead. After authentication through Authelia, the reverse proxy passes an HTTP header (in my case, Remote-User) that provides the username of the currently logged in user. Grampsweb would need to keep an eye on that header to determine who is logged in. This method requires Grampsweb to be served via reverse proxy because it needs to blindly trust the Remote-User header. I use Traefik, but this method also works with nginx and Caddy.
2. OIDC: since this is more common, I'm not sure a description is required. I think it might also be a little more complicate to implement.

[DavidMStraub]

Hi @mpfl, good to know that Gramps Web is on this list 🙂

I will transfer your issue to the backend repo, as that's what handles authentication.

Would you be willing to work on this feature?

[DavidMStraub]

(... and from you description I understand this is different from #355, right?)

[mpfl]

Argh I checked the wrong repo for existing issues, sorry.

The issues overlap. OIDC is an identity layer built on top of OAuth2 (or so the Internet tells me). Reverse proxy header authentication has nothing to do with either of them.

I feel like reverse proxy would be easier to implement as all you're doing is checking for the value of an HTTP header. No passing secret tokens around.

I can give implementing it a red hot go, but I would need to dramatically skill up on the frameworks you're using here.

[DavidMStraub]

The tokens will still be needed for authorization, so the new method (OAuth2 or reverse proxy) would only be an alternative means of authenticating the request for a token (currently, by sending a JSON with username & password to /api/login).

[mpfl]

Okay, I'll have to see how this is handled in other apps that have a similar architecture. Reverse proxy header authentication won't be able to pass a password across. The authentication system lets someone log in and then just asserts that someone is logged - the app is expected to trust it.

On the other hand, the app will also never receive an unauthenticated request because all communications go through the reverse proxy. Perhaps a configuration flag needs to turn the API's authentication method completely off.

[DavidMStraub]

Perhaps a configuration flag needs to turn the API's authentication method completely off.

No, that doesn't make sense. There used to be an option for disabling authorization completely meant for development, but it lead to a lot of error-prone workarounds and was removed 1 year ago - see the discussion in #309. But it was anyway not suited for production.

Again, I think we need to distinguish between authorization and authentication. Authorization and the JSON web tokens are an integral part of the Web API and its communicated with the frontend and there is no point in disabling it.

Authentication is something that can be handled by an external provider.

To understand what is needed to allow alternative authentication methods, it is useful to look at how authentication works right now. The most important endpoints are:

• POST to /api/token: currently requires username and password. Returns tokens.
• POST to /api/user/<username>/register: currently requires email and password. Triggers a signup email.

The first step to enable proxy authentication, e.g. using Authelia, is to implement an alternative to /api/token that issues the tokens not on receiving username & password, but on receiving the proxy headers. From the moment the tokens are returned in exchange for the proxy headers, everything else (JWTs, authorization, etc.), continues to work like now.

[gabemcg]

I'm here looking for this feature as well. I'd like to host Gramps on my own domain behind Authentik and not require users to log in twice.

[chandz05]

Hello, new user of Grampsweb here, and would also love either reverse proxy forward auth or OIDC support.

[twsl]

bumping for visibility

[DavidMStraub]

Don't.