You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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:
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.
The text was updated successfully, but these errors were encountered: