Feature: Authenticate via "Remote User" header

[aroberts]

In the case that access to taskcafe is through a reverse proxy, it would be great to support "Remote-User" login - the reverse proxy performs its own authentication, and adds a header with the user that the request belongs to. Taskcafe should consume this header and treat it as a successful login, if the user exists.

This is related to #20, but a much simpler implementation, and still very broadly applicable.

[JordanKnott]

For those interested in working on this issue:

This behavior should be allowed only if the config option server.remote_user_header is set to true.

Taskcafe uses Viper to handle configuration.

Relevant files

• internal/commands/web.go
• internal/route/middleware.go

Please take a look at the contributing guide as well as the developers guide for an idea on how the project is structured.

[MistaTwista]

Looks like I can take it

[MistaTwista]

@JordanKnott few questions, just to make sure I'm understand well what do I need to do in this case.

As I see, in auth middleware you check Authorization header with JWT, and there are authorizations, user data and so on. So if I right we need to make changes not in a middleware that check JWT token, but in login procedure that gives us this token.

What do you think if my changes will be at internal/route/auth.go:160 (func (h *TaskcafeHandler) LoginHandler(w http.ResponseWriter, r *http.Request)) somewhere here. I've planned something like:

1. If server.remote_user_header is set to true
2. Take username from Remote-User header
3. Get user from repo
4. If user exists - skip password checking and make a token

It's simple, but we still need to understand how to do user registration. Taskcafe somehow needs to create user in it's DB.

What do you think?

[aroberts]

the "create user" step could certainly be broken out into its own system. Third party auth generally implies third party user store (e.g. LDAP, AD), and that means different things based on app capabilities and so on. The trouble with auto-creating users is everything beyond the username you're getting from the header: Do these new users belong to a team? which team? What are the permissions of the created user? The list goes on.

I would say that all the answers to the above are in the purview of either a user sync module or a pluggable user backend, and needn't be addressed here. If there is no user found in step 3, I would silently ignore the header.

[MistaTwista]

I don't mean user auto creation, for sure :) i thought about some API for third party service, that can creates a user at a Taskcafe. Better way is completely extract user and his authentications and making something like pluggable system, but it need more changes and refactoring.

@aroberts do you plan to add users in DB with some of your services?

[aroberts]

It’s not an immediate need, but it would be nice to have. I add users rarely, and I am centralized around ldap.

[JordanKnott]

Hmm - I think I underestimated the complexity of this feature.

I'm not really sure how user creation would work, as I imagine it would really depend on what software is being used @aroberts Is there a particular software / setup that you're wanting to use so that I have a good reference on how it would work for a user?

[aroberts]

@JordanKnott It's my intention to leave user creation out of scope for this ticket for exactly that reason - there are tons of questions surrounding it without great answers. Additionally, adding a user is a rarity for me compared to login through my SSO. What I was getting at above is, it's no trouble to manually create users in order to make SSO login work.

[JordanKnott]

@MistaTwista Instead of using the /auth/login endpoint, we create a different /auth/sso endpoint
that accepts the Remote-User header and returns the refresh + access tokens.

Then we could add a new button to the login for SSO login that just calls the endpoint.

Thoughts?

[aroberts]

I'm not sure how that would work.. I've never implemented this in a SPA, but I feel like it's something that's occurring when index.html loads, not part of the javascript.

The flow that's implied (to me) is:
-> user hits my taskcafe subdomain
-> reverse proxy fields the request, challenges for auth (sso)
-> auth success, reverse proxy forwards request to underlying taskcafe backend, adding a header with the auth'd username
-> taskcafe receives header, and logs requested user in before delivering index.html and starting whatever javascript

There shouldn't need to be a button (because what protocol would /auth/sso use?) or anything like that - other than acting on the header, there should be very little code needed on the backend, and zero on the frontend I think.

[JordanKnott]

Maybe the Remote-User check can just be added to the refresh token handler?

That might be the best way since it would work kinda like how you described without requiring much changes.

[aroberts]

That seems like it might work - I'll try to take a read tomorrow and see if I see any issues with that spot.

[aroberts]

hello, a year later. I'm still very interested in this feature, and I'll note that among kanban-style task managers, this feature would set TaskCafe apart - it is not widely implemented, but as it gets easier and easier to host a domain behind a reverse proxy, demand for this style of SSO support grows.

FileBrowser (feature doc | github link) is a similarly architected application (go backend, SPA frontend) that has implemented this - I am hoping it's useful as a model.

[MistaTwista]

hey, @aroberts i'll try to look what can I do here, just need to update in memory :)

[MistaTwista]

Added PR #135, just to start with something. @JordanKnott what do you think?
It's just backend change. @aroberts will it work for you without frontend changes?

[max-tet]

Hi! I am also very interested in this feature. Is it still being developed?

I would also love to define the name of the header myself. And auto-user creation would also be nice to have.

The perfect proxy auth feature for me would work like this:

1. Start the app with additional environment variables:

• containing the name of the initial admin user (e.g. admin=admin_user)
• enabling proxy auth (e.g. proxy_auth=true)
• setting the key of the http header that contains the username (e.g. auth_header=X-Authenticated-User)

2. Configure the reverse proxy to authenticate incoming requests in any way you like.
3. Let the reverse proxy set X-Authenticated-User to the authenticated username on every request.
4. The app treats the requests as if they belong to the appropriate user session.
5. Bonus: if the app does not know the username, it creates a new user with that name.

Additional context:
I am using the app for this product. Since this is a single-user platform, users really should see no login screen at all, not even for SSO.