topaLE
/
uptime-kuma
1
0
Fork 0
Code Issues 185 Pull Requests 26 Projects Releases 28 Wiki Activity
Labels Milestones

Add Header Authentication for SSO #474

Open
Mikhail5555 wants to merge 6 commits from Mikhail5555/feature/remote-header-auth into master
Conversation 10 Commits 6 Files Changed 2
Mikhail5555 commented 3 years ago (Migrated from github.com)
Owner

When the env variable REMOTE_USER_HEADER is set, it will use the username provided in will skip both websocket and basic auth authentication.

This allows for login through something like Authelia.

How to test:

  1. run server with REMOTE_USER_HEADER=Remote-User npm run start-server-dev or add REMOTE_USER_HEADER env variable to your docker container.
  2. Make sure the user set in your header exists in the database (Mikhail in this case).
  3. Open up a websocket connection with the following header included Remote-User:Mikhail.
  4. You should now be logged in as Mikhail through the same mechanics as autoLogin uses.
When the env variable `REMOTE_USER_HEADER` is set, it will use the username provided in will skip both websocket and basic auth authentication. This allows for login through something like Authelia. How to test: 1. run server with `REMOTE_USER_HEADER=Remote-User npm run start-server-dev` or add `REMOTE_USER_HEADER` env variable to your docker container. 2. Make sure the user set in your header exists in the database (`Mikhail` in this case). 3. Open up a websocket connection with the following header included `Remote-User:Mikhail`. 4. You should now be logged in as `Mikhail` through the same mechanics as autoLogin uses.
👍 2
louislam commented 3 years ago (Migrated from github.com)
Owner

I believe it is duplicate of no auth feature.

I believe it is duplicate of no auth feature.
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

I don't believe its the same, compleetly disabling authentication vs letting a reverse proxy handle the logged in user (and thus still allow different user accounts) is different.

I don't believe its the same, compleetly disabling authentication vs letting a reverse proxy handle the logged in user (and thus still allow different user accounts) is different.
Saibamen (Migrated from github.com) approved these changes 3 years ago
server/server.js
Saibamen (Migrated from github.com) commented 3 years ago
Owner 
                    debug(`Remote user ${remoteUser} doesn't exist`);
                }
            } else {
                debug("Remote user header set but not found in headers");
```suggestion debug(`Remote user ${remoteUser} doesn't exist`); } } else { debug("Remote user header set but not found in headers"); ```
Mikhail5555 (Migrated from github.com) reviewed 3 years ago
server/server.js
Mikhail5555 (Migrated from github.com) commented 3 years ago
Poster
Owner

Ah i though the debug logging was mostly lower level, but that seems to mostly be somewhat inconsistent.

Ah i though the debug logging was mostly lower level, but that seems to mostly be somewhat inconsistent.
louislam commented 3 years ago (Migrated from github.com)
Owner

Then security will be a big problem, because I believe strangers can login without password using http header.

I probably will implement access token for API features in the future.

I suggest this feature should use that access token at that time.

Then security will be a big problem, because I believe strangers can login without password using http header. I probably will implement `access token` for API features in the future. I suggest this feature should use that `access token` at that time.
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

Http headers should only be used with a correctly configured reverse proxy. (thus disallowing end-user to set the REMOTE_USER_HEADER themselves). If you want to know some more about this I would advice you to read something like https://www.authelia.com/docs/deployment/supported-proxies/

Http headers should only be used with a correctly configured reverse proxy. (thus disallowing end-user to set the REMOTE_USER_HEADER themselves). If you want to know some more about this I would advice you to read something like https://www.authelia.com/docs/deployment/supported-proxies/
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

If you want I can even demo it how I personally use it with SSO for multiple services (so you can see why I like it so much)

If you want I can even demo it how I personally use it with SSO for multiple services (so you can see why I like it so much)
louislam commented 3 years ago (Migrated from github.com)
Owner

If you want I can even demo it how I personally use it with SSO for multiple services (so you can see why I like it so much)

After read the authelia's doc, I now understand how it works.

But honestly I am personally not familiar with sso. I need more time to study the code changes and the workflow of sso. And make sure there is no vulnerabilities that ~hate~ hurt current users.

So it may take a longer time to get it merged. Thank you for the pr btw.

> If you want I can even demo it how I personally use it with SSO for multiple services (so you can see why I like it so much) After read the authelia's doc, I now understand how it works. But honestly I am personally not familiar with sso. I need more time to study the code changes and the workflow of sso. And make sure there is no vulnerabilities that ~hate~ hurt current users. So it may take a longer time to get it merged. Thank you for the pr btw.
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

No problems, if you have any questions feel free to ask.

No problems, if you have any questions feel free to ask.
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

Btw, just a general question, is there a reason why the authentication is done over web-socket and not through a normal post request? (and then session stored in cookie instead of local storage token?) (Sorry if this is the incorrect place to ask this)

Btw, just a general question, is there a reason why the authentication is done over web-socket and not through a normal post request? (and then session stored in cookie instead of local storage token?) (Sorry if this is the incorrect place to ask this)
louislam commented 3 years ago (Migrated from github.com)
Owner

Btw, just a general question, is there a reason why the authentication is done over web-socket and not through a normal post request? (and then session stored in cookie instead of local storage token?) (Sorry if this is the incorrect place to ask this)

Just because the whole application is based on websocket and it is using local storage token.

> Btw, just a general question, is there a reason why the authentication is done over web-socket and not through a normal post request? (and then session stored in cookie instead of local storage token?) (Sorry if this is the incorrect place to ask this) Just because the whole application is based on websocket and it is using local storage token.
Mikhail5555 commented 3 years ago (Migrated from github.com)
Poster
Owner

OK that's a clear design choice.
I personally prefer to open the websocket connection after authenticating (unless you also have some public information over the websocket).
It makes it slightly easier since you only need to verify the jwt token once on connection, and after that all you can assume for each message that the user is authenticated.
Something like this: https://nuvalence.io/blog/websocket-token-based-authentication

OK that's a clear design choice. I personally prefer to open the websocket connection after authenticating (unless you also have some public information over the websocket). It makes it slightly easier since you only need to verify the jwt token once on connection, and after that all you can assume for each message that the user is authenticated. Something like this: https://nuvalence.io/blog/websocket-token-based-authentication
👀 2

Reviewers

Saibamen
This pull request has changes conflicting with the target branch.
server/auth.js
server/server.js
Sign in to join this conversation.
Reviewers
Request review
No reviewers
Saibamen
Labels
Apply labels
Clear labels
bug
Something isn't working dependencies
Pull requests that update a dependency file discussion doc
Improvements or additions to documentation duplicate
This issue or pull request already exists feature-request
New feature or request good first issue
Good for newcomers hacktoberfest hacktoberfest-accepted help help wanted
Extra attention is needed High
High Priority impossible invalid
This doesn't seem right investigating k8s Low
Low Priority Medium
Medium Priority News prerelease bug question
Further information is requested resolved Unknown wontfix
This will not be worked on
No Label bug dependencies discussion doc duplicate feature-request good first issue hacktoberfest hacktoberfest-accepted help help wanted High impossible invalid investigating k8s Low Medium News prerelease bug question resolved Unknown wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Pending
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch 'Mikhail5555/feature/remote-header-auth'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes