Forward authentication with Rauthy

[decentral1se]

I thought it might be best to continue #55 with a clean slate. We can focus on rauthy here and if it goes well, it can become a general solution for all OIDC providers which support forward authentication. If not, we can close them both and call it a day 😆

---

I've been chatting with @cblgh about this and I've come up with a test harness. It's sadly been a bit complicated but I believe I have a reproducible environment for testing it easily. Check it out: https://git.coopcloud.tech/decentral1se/cerca-rauthy-pmc-thunderdome

If I patch ./cerca/server/server.go with the following

➜ cerca main ✗ g s
## main...origin/main
 M server/server.go
➜ cerca main ✗ g d
diff --git server/server.go server/server.go
index fda9114..a02e038 100644
--- server/server.go
+++ server/server.go
@@ -392,6 +392,15 @@ func (h RequestHandler) ErrorRoute(res http.ResponseWriter, req *http.Request, s
 }

 func (h RequestHandler) IndexRoute(res http.ResponseWriter, req *http.Request) {
+       fmt.Println("--- CERCA x RAUTHY HEADERS DUMP ---")
+       fmt.Println("USER: ", req.Header.Get("X-Forwarded-User"))
+       fmt.Println("USER ROLES: ", req.Header.Get("X-Forwarded-User-Roles"))
+       fmt.Println("USER GROUPS: ", req.Header.Get("X-Forwarded-User-Groups"))
+       fmt.Println("USER EMAIL: ", req.Header.Get("X-Forwarded-User-Email"))
+       fmt.Println("USER FAMILY NAME: ", req.Header.Get("X-Forwarded-User-Family-Name"))
+       fmt.Println("USER GIVEN NAME: ", req.Header.Get("X-Forwarded-User-Given-Name"))
+       fmt.Println("--- END DUMP ---")
+
        ed := eout.Describe("IndexRoute")
        var err error
        // handle 404

I end up with something as follows:

cerca-1     | --- CERCA x RAUTHY HEADERS DUMP ---
cerca-1     | USER:  mRKDCDyHIEPMnyrwfRP0rhLX
cerca-1     | USER ROLES:  rauthy_admin,admin
cerca-1     | USER GROUPS:  admin
cerca-1     | USER EMAIL:  admin@localhost
cerca-1     | USER FAMILY NAME:  Admin
cerca-1     | USER GIVEN NAME:  Rauthy
cerca-1     | --- END DUMP ---

It would seem that getting the preferred_username out of rauthy is somewhat problematic but I have raised an issue: sebadob/rauthy#1534. We could simply choose to re-use the Given name as the username. The current user ID rauthy gives is just an opaque string 🤷‍♀️ Let's assume we have a username for now 😛

@cblgh do you wanna take a look at the setup / consider the incoming headers and we can start to look at the questions you raised the last time we chatted? We should hopefully be in a better position to answer them now that we have some running code 🧗‍♀️

[decentral1se]

Update: rauthy will support exposing preferred_username via a header flag: sebadob/rauthy#1534 (comment)

We are running into a bit of a time crunch with the current permacomputing.net trajectory, so I think I'm just going to take a stab at a patch that arranges this functionality. I can use our previous discussions / leading questions as a map of the implementation.

Still no stress if this is not a thing that won't be supported. Let's see what the diff is like.

[cblgh]

@decentral1se

We are running into a bit of a time crunch with the current permacomputing.net trajectory, so I think I'm just going to take a stab at a patch that arranges this functionality

understandable! i think it is easier to reason about this aggregation of complexity once there is something in place ^^'

some thoughts having stewed on it a bit

---

i think maybe the most straightforward thing to do is to add a table sso_rauthy which records the rauthy specific values and maps it to a cerca user. in particular i assume we need the opaque req.Header.Get("X-Forwarded-User") as it is an identifier for this user that will never be changed (this is an assumption on my part)

so the simplest thing to do, which i recommend starting with, is to map the rauthy opaque user id to a cerca user:

table sso_rauthy
ruser TEXT -- rauthy user
userid INTEGER -- cerca userid

blabla foreign key user table

if id doesn't exist in this table -> we can launch a flow to create a new user

with this table in place, we can basically query and change any of the existing things cerca has. in particular user.name and ensuring inclusion of cerca user id in table admins depending on USER ROLES being set.

some advice on where to be putting this code to increase chance of ongoing upstream support

package server/

create server/rauthy.go and do everything with rauthy headers in there.

as for all the logic that comes with logging in and so on i don't know what that looks like and i think you are in the best position to determine. in particular i don't know what it looks like to have both sso and password but maybe it's a non-issue! but as far as possible and feasible, i would really like all of that logic to reside in server/rauthy.go. if something is impossible to put there then ofc dumping in server/server.go is fine.

package database/

do the same for package database/ and create database/sso_rauthy.go. the only exception here is to add the sso_rauthy table creation statement to the existing list of tables inside database/database.go: https://github.com/cblgh/cerca/blob/main/database/database.go#L72

in terms of preferred_username not having landed yet and maybe being delayed, i think it is best to assume it does not exist right now. so we we should build this out in a way that does not rely on it existing. we can always patch it later on. in practice that would probably mean redirecting a "new sso user" to an interim page (or just account.html) to set their cerca username manually; maybe prefilling the page with whatever header values are passed atm

[decentral1se]

Thank you! I will be back with code 💟

preferred_username has arrived in the meantime: sebadob/rauthy#1566 | release

[decentral1se]

Heyyyya @cblgh, finally some code: decentral1se@b27a616 with a little demo over here (using my test config repo).

I kind of took some shortcuts with this rough draft. A quick tour of the most important points:

• /login / /logout goes via rauthy now. If there is no existing account, one is automatically created with a random password on the cerca side (will never be used). No additional database table is used, we just match via username.
• several routes/functionality are disabled: change password/username, reset password, register new user and manage invites. These are basically choices which suit our permacomputing.net needs atm and how we're going to onboard people
• there is new optional .toml config to support this feature.

As I found out, the changes started to touch more and more of how cerca deals with user account handling. It doesn't seem to fit so nicely in the end although it is not super intrusive. However, it does add another layer of consideration when dealing with accounts. I felt like I was working against your original design a bit. So, I'm not sure but see what you think.

No rush to review/make a decision, we can run a fork for the time being.

[cblgh]

@decentral1se this is super exciting to see! i left comments on the commit. some pure review comments, others were questions that need adressing (thinking specifically about security + what happens on user renames 'upstream in rauthy')

overall i'm quite positive to how relatively little this impacts cerca's existing codebase. i think the security & renaming impacts are important to address though before i accept it upstream. but my first impression is that i'd be ok to maintain something like this going forward if it is useful as part of an overall SSO strategy for groups like pmc :)

also in a future PR i'd really want full instructions in cerca's contrib/ on how to spin up rauthy and cerca-with-rauthy for people who want to start their sso journey!

maybe the best way to trial this change is that you go forward with the pmc-with-rauthy fork over summer, and we see what breaks/needs tweaking. then we work on getting a reality-tested version of it into upstream end of summer/start of autumn?

[decentral1se]

Wonderful news @cblgh! Thanks for the review. I will come back on the comments and bring this to a PR then so we can consider it again. I like your idea to let the PMC cerca install + Rauthy live a little over the few months and this can then inform decisions which come into the proposed changes. I can write docs too. I will look into the security/rename issues, good points!

[cblgh]

@decentral1se Glad the approach seems reasonable to you too! Aint nothing like trialing a change with real-world use 💪 Re security, if we can make sure installs@rauthy-enabled are not trivially pwnable but there still needs to be a bit of infra config for it to be safe, then we can copy out and point to rauthy's security tldr for forward auth