Mintplex-Labs
[FEAT]: REALLYSIMPLE_SSO (authentication passthrough)
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.
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?
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.
+1 for this. At home I'm using Authentik for SSO and it has the proxy provider which I'm using with caddy (other options are available as mentioned by @phosjlusky)
This is also something that open webui is doing. I've been using it with open webui for a while now. For this setup, the proxy is exposed, but webui runs only on the internal network (not accessible by the users), when a user tries to access it(through the proxy), the user is redirected to the login page, after the successful login, it gets redirected to the app, if the user doesn't exist it's created, if the user exists it's just logged in.
This is a simple way to offload user management to a third party app, and probably much simpler than the "SIMPLE_SSO" method.
+1. This feature would significantly improve security for self-hosted environments, such as Azure. Relying solely on the application for authentication is risky, it is generally more secure to leverage the built-in authentication proxy provided by platforms like Azure App Service or Container Apps.
These platforms use an authentication proxy that handles the login process and then passes user identity information to the application via request headers. For example, Azure Container Apps passes headers like X-MS-CLIENT-PRINCIPAL-NAME and X-MS-CLIENT-PRINCIPAL-ID.
The application could be configured to map these custom headers to user accounts, enabling auto-sign-in. This is a common approach to allow SSO. It is secure because the platform's proxy sanitises incoming requests. It does not allow external clients to spoof these headers, and direct access to the container without passing through the proxy is restricted.
Reference: https://learn.microsoft.com/en-us/azure/container-apps/authentication#access-user-claims-in-application-code
