openobserve
openobserve copied to clipboard
openobserve
SSO implementation
Which ZincObserve functionalities are relevant/related to the feature request?
No response
Description
SSO for users so they can use existing organization credentials.
Proposed solution
Ideally we could use a solution like dex for implementing this functionality.
Alternatives considered
None.
I expect Dex is a complete red-herring. The simplest solution to integrate SSO is to look for a header (or cookie, but usually a header) set by a reverse proxy that manages the SSO that contains the authentication information (in this case, email address) - either a fixed header/value, or a JWT, and trust that. Then it doesn't matter what the authentication process is. So if a session isn't logged in, look for a header. If the header isn't there, 403.
Agree to a great extent with you. We have had discussions around JWT in the authorization header for a while. I think that will be the way we will go and then integrate something on top of that. We still need the UI and redirection mechanisms for end users and need to figure out a solution around that. This is a big area that requires too many things to be considered.
Suggestions are welcome on what would be the best way to go for it.
Not being a Rust or Vue programmer, I apologise for lack of patch... but I think you're going too far into making an external source a part of the entire process. It doesn't need to be a JWT (though a HS256 is dead simple - I added it to a reverse proxy a few days ago). Somewhere around web/src/components/login the auth token is created; instead of actually presenting the form (or just before it is), check for a configuration option "external SSO", and if it's set, just look in another configuration option "external SSO header", and use that HTTP header for the username, and trust that it's correct and it's the username. That's all. That's all that things like Gitea use, or Jenkins (with 'HTTP Header by reverse proxy') use. You still pull users from local storage, it's up to another process to manage them. It's up to the system administrator to ensure nobody can inject bogus headers (with firewall rules, localhost binding or whatever).
eg. Gitea configuration here is just
REVERSE_PROXY_AUTHENTICATION_USER = X-SSO-User ENABLE_REVERSE_PROXY_AUTHENTICATION = true
... the reverse proxy extracts authentication information and sets that header. The actual users in my case are sync'd from LDAP, but that's outside the scope of authentication - that's authorization.