Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEAT]: REALLYSIMPLE_SSO (authentication passthrough) #2934

Open
phosjlusky opened this issue Jan 3, 2025 · 2 comments
Open

[FEAT]: REALLYSIMPLE_SSO (authentication passthrough) #2934

phosjlusky opened this issue Jan 3, 2025 · 2 comments
Labels
enhancement New feature or request feature request

Comments

@phosjlusky
Copy link

What would you like to see?

SIMPLE_SSO is only simple for the use case mentioned in the documentation, "as a simple sub-service within a much larger system".

For the many of us using it as a standalone system, it's a lot of overhead to build something to handle AnythingLLM's SIMPLE_SSO under our enterprise SSO. While native OIDC or SAML support would be nice, I can see that would be a lot of work to migrate to a cookie-based authentication mechanism instead of the current bearer-token mechanism, or migrating to one of the common authentication frames that supports many authentication methods.

One strategy that is typically simple to implement is authentication passthrough via HTTP header. In this scenario, authentication is handled by an upstream proxy such as Vouch or mod_auth_mellon, and a username is passed from the proxy to the application in HTTP headers. No customization in the application is required for different proxies or authentication methods--the application specifies what what headers need to be sent by the proxy, and the proxy is responsible for making that happen. Some apps do allow customizing the names of of the headers, but it's not really needed since the that's configurable in the proxy to match the application.

Implementing this in AnythingLLM seems like it would be pretty simple:

  • If HeaderAuth is enabled, the user is not authenticated, and the passthrough auth username header is present and matches a user, issue a token a token to the user.

That's it for the most basic authentication use case. If AnythingLLM supported that, my standalone AnythingLLM instance could be doing SAML or OIDC with any identity provider with a few minutes of work to configure the proxy and identity provider.

For bonus points, some applications also accept other user data such as Name, Role, and/or Groups via http headers so that the application can automatically create new users that have successfully authenticated to the proxy.

@phosjlusky phosjlusky added enhancement New feature or request feature request labels Jan 3, 2025
@timothycarambat
Copy link
Member

Wouldn't this mean someone who knows a user's username and your instance address could just make a request with that header and be logged in? Since there is no login token to provision or validate serverside I could just go around the middleware?

Or are all requests to anythingllm forced to go through the auth proxy first?

@phosjlusky
Copy link
Author

phosjlusky commented Jan 4, 2025

When you implement an authentication proxy, you only allow the connections to the backend server from the proxy.

Some examples:
Microsoft Entra Application Proxy: https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-configure-single-sign-on-with-headers
Google Cloud Identity-Aware Proxy: https://cloud.google.com/python/docs/getting-started/authenticate-users
Vouch Proxy with Okta: https://developer.okta.com/blog/2018/08/28/nginx-auth-request

Those examples all assume there's an interactive user to authenticate. What about programmatic API access? If the programmatic API access is via unique endpoint not used by frontend users, I'll exclude those URLs from the authentication by the proxy and strip any headers that match the backend auth headers. If there's any overlap between the endpoint usage, I'll setup a different public URL for API access without proxy authentication but still stripping any headers that match the backend auth headers.

In all cases, you don't expose the application directly to users--you use docker networks, iptables rules, and/or binding the listening socket to localhost to prevent remote access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature request
Projects
None yet
Development

No branches or pull requests

2 participants