I am trying to set up Single Sign-On with an apache reverse proxy. The proxy sets REMOTE_USER header and I enabled Trusted Header Authentication in the Graylog Webinterface in the System Authentication settings. Unfortunately it doesn’t work. the first call to /graylog/api/ will be rejected by my apache with a 401. And I get stuck on the login screen saying “Loading, please wait…”
Apache access.log:
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog HTTP/1.1" 200 440
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/config.js HTTP/1.1" 200 177
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/polyfill.472622149827c1587209.js HTTP/1.1" 200 72152
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/vendor.7b2e72342f604d7babb9.js HTTP/1.1" 200 356045
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/builtins.472622149827c1587209.js HTTP/1.1" 200 280639
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/app.472622149827c1587209.js HTTP/1.1" 200 1371253
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/plugin/org.graylog.plugins.threatintel.ThreatIntelPlugin/plugin.org.graylog.plugins.threatintel.ThreatIntelPlugin.4d62b9d2b0bdce76aa29.js HTTP/1.1" 200 916732
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/plugin/org.graylog.aws.AWSPlugin/plugin.org.graylog.aws.AWSPlugin.47c1f4ee3665343bbc9f.js HTTP/1.1" 200 889513
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:33 +0000] "GET /graylog/assets/plugin/org.graylog.plugins.collector.CollectorPlugin/plugin.org.graylog.plugins.collector.CollectorPlugin.2c202c07057af33e6166.js HTTP/1.1" 200 932169
xxx.xxx.xxx.xxx - undefined [08/Nov/2022:17:38:34 +0000] "GET /graylog/api/system/sessions HTTP/1.1" 401 381
xxx.xxx.xxx.xxx - my_user [08/Nov/2022:17:38:35 +0000] "GET /graylog/api/ HTTP/1.1" 200 233
My apache config:
<Location /graylog>
ProxyPass "https://some_other_machine/graylog/"
ProxyPassReverse "https://some_other_machine/graylog/"
# my auth stuff
# ...
<RequireAll>
Require valid-user
</RequireAll>
RewriteEngine On
RewriteCond %{REMOTE_USER} (.*)
RewriteRule .* - [E=X_REMOTE_USER:%1]
RequestHeader set REMOTE_USER %{X_REMOTE_USER}e
RequestHeader unset Authorization
</Location>
I got trusted_proxy set
The user my_user exists and has { “external_user”: false } set
If I do: RequestHeader set REMOTE_USER my_user
the user is logged in
I read this:
opened 05:35AM - 20 Nov 19 UTC
feature
## Expected Behavior
It should be possible to use graylog behind a reverse prox… y that requires HTTP authentication.
## Current Behavior
Behind a reverse proxy that requires HTTP authentication, a user cannot get past graylog's login screen.
Refresher: HTTP authentication works by sending a `Authorization` header containing a base64-encoded string containing `user:password`; for instance, HTTP authentication for user `foo` and password `bar` means the browser sends `Authorization: basic Zm9vOmJhcg==` on _each_ request to graylog, not only on the login page.
graylog unfortunately uses the same header name for session management; `XmlHttpRequests` are sent to the API using a customized `Authorization` string, containing a session UUID; for instance, a javascript call could include a `Authorization: basic YmRlMzE2ZDMtNDJhYi00OGU3LWFkNTEtMzc2Y2RjMzEyMDFjOnNlc3Npb24=`.
So either the reverse proxy refuses the authentication because it was clobbered by graylog and does not match any user anymore, or graylog API denies access because it expects a session management UUID, not a `user:password` combo. In any case, the user cannot go past the login page.
## Possible Solutions
Each of those would work for me AFAICT:
* Graylog could use another header name (such as `X-Graylog-Authorization` instead of `Authorization`) for its session management. To allow backwards compatibility, the HTTP header name could be set via a configuration variable with its default set as `Authorization`.
* Graylog could drop usage of HTTP headers for session management and move that session token to a cookie.
* Graylog could manually pass session UUID as a GET/POST parameter on API requests.
* Assuming a single username cannot have more than one session, graylog could accept a `username:password` `Authorization` as a unique session identifier instead of enforcing a `UUID:session` string.
## Context
Because it is company policy (for security, auditing and other purposes) to enforce HTTP auth for internal services, I cannot currently deploy graylog for said company.
## Your Environment
Running the `graylog-3.1.3-1.ova` appliance.
opened 10:24PM - 19 Jan 21 UTC
documentation
triaged
Upgrading our Graylog server from 3.3.9 to 4.0.1 (and removing the old SSO plugi… n) caused SSO to stop working for existing users.
## Expected Behavior
SSO works using the trusted HTTP header authentication feature that is now built-in.
## Current Behavior
Users authenticated with our external auth provider are not authenticated in Graylog, and are unable to login.
Logs:
```
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.mgt.DefaultSecurityManager - Context already contains a SecurityManager instance. Returning.
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.mgt.DefaultSecurityManager - No identity (PrincipalCollection) found in the context. Looking for a remembered identity.
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.mgt.DefaultSecurityManager - No remembered identity found. Returning original context.
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.subject.support.DelegatingSubject - attempting to get session; create = false; session is null = true; session has id = false
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.mgt.DefaultSubjectDAO - Session storage of subject state for Subject [org.apache.shiro.subject.support.DelegatingSubject@1ac7cf73] has been disabled: identity and authentication state are expected to be initialized on every request or invocation.
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.subject.support.DelegatingSubject - attempting to get session; create = false; session is null = true; session has id = false
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.authc.AbstractAuthenticator - Authentication attempt received for token [org.graylog2.shared.security.HttpHeadersToken@7650930f]
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Iterating through 5 realms for PAM authentication
2021-01-19 21:10:27,911 DEBUG: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Realm [org.graylog2.security.realm.SessionAuthenticator@42f1785d] does not support token org.graylog2.shared.security.HttpHeadersToken@7650930f. Skipping realm.
2021-01-19 21:10:27,911 DEBUG: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Realm [org.graylog2.security.realm.AccessTokenAuthenticator@16c97452] does not support token org.graylog2.shared.security.HttpHeadersToken@7650930f. Skipping realm.
2021-01-19 21:10:27,911 TRACE: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Attempting to authenticate token [org.graylog2.shared.security.HttpHeadersToken@7650930f] using realm [org.graylog2.security.realm.HTTPHeaderAuthenticationRealm@74c53f7e]
2021-01-19 21:10:27,913 DEBUG: org.graylog2.security.realm.HTTPHeaderAuthenticationRealm - Attempting authentication for username <xyz@abc.com>
2021-01-19 21:10:27,914 DEBUG: org.graylog2.cluster.ClusterConfigServiceImpl - Couldn't find cluster config of type org.graylog.security.authservice.GlobalAuthServiceConfig.Data
2021-01-19 21:10:27,914 DEBUG: org.graylog.security.authservice.backend.MongoDBAuthServiceBackend - Trying to load user <xyz@abc.com> from database
2021-01-19 21:10:27,914 DEBUG: org.graylog2.users.UserServiceImpl - Loading user xyz@abc.com
2021-01-19 21:10:27,915 DEBUG: org.graylog2.users.UserServiceImpl - Loaded user xyz@abc.com/5e441ca046e2bc0001e6c459 from MongoDB
2021-01-19 21:10:27,915 TRACE: org.graylog.security.authservice.backend.MongoDBAuthServiceBackend - Skipping mongodb-based password check for external user xyz@abc.com
2021-01-19 21:10:27,915 WARN : org.graylog2.security.realm.HTTPHeaderAuthenticationRealm - Failed to authenticate username <xyz@abc.com> from trusted HTTP header <X-Auth-Request-Email> via proxy <10.43.70.102>
2021-01-19 21:10:27,915 DEBUG: org.apache.shiro.realm.AuthenticatingRealm - Looked up AuthenticationInfo [null] from doGetAuthenticationInfo
2021-01-19 21:10:27,915 DEBUG: org.apache.shiro.realm.AuthenticatingRealm - No AuthenticationInfo found for submitted AuthenticationToken [org.graylog2.shared.security.HttpHeadersToken@7650930f]. Returning null.
2021-01-19 21:10:27,916 DEBUG: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Realm [org.graylog2.security.realm.AuthServiceRealm@77fb684c] does not support token org.graylog2.shared.security.HttpHeadersToken@7650930f. Skipping realm.
2021-01-19 21:10:27,916 DEBUG: org.apache.shiro.authc.pam.ModularRealmAuthenticator - Realm [org.graylog2.security.realm.RootAccountRealm@3e81d57e] does not support token org.graylog2.shared.security.HttpHeadersToken@7650930f. Skipping realm.
2021-01-19 21:10:27,916 DEBUG: org.graylog2.shared.security.ShiroAuthenticationFilter - Unable to authenticate user.
```
## Possible Solution
The credentials passed to `authenticateAndProvision` are [already authenticated when they're created](https://github.com/Graylog2/graylog2-server/blob/4.0.1/graylog2-server/src/main/java/org/graylog2/security/realm/HTTPHeaderAuthenticationRealm.java#L115), so if the `user.isExternalUser()` check that is causing these problems were removed [the password check would still be skipped](https://github.com/Graylog2/graylog2-server/blob/4.0.1/graylog2-server/src/main/java/org/graylog/security/authservice/backend/MongoDBAuthServiceBackend.java#L81-L86) and users would be successfully authenticated.
Does it make sense to just remove that `user.isExternalUser()` check to get SSO working for these users again? Or is that required for some other use-case?
## Steps to Reproduce (for bugs)
1) Migrate from 3.3.x to 4.0.x with users that were [created automatically by the legacy SSO plugin](https://github.com/Graylog2/graylog-plugin-auth-sso/blob/3.3.0/src/main/java/org/graylog/plugins/auth/sso/SsoAuthRealm.java#L115-L121).
2) The `HTTPHeaderAuthenticationRealm` [creates an authenticated user object from the request data and calls `authenticate`](https://github.com/Graylog2/graylog2-server/blob/4.0.1/graylog2-server/src/main/java/org/graylog2/security/realm/HTTPHeaderAuthenticationRealm.java#L115-L116).
3) The `AuthServiceAuthenticator` [triggers a call to `authenticateAndProvision` for the configured backend](https://github.com/Graylog2/graylog2-server/blob/368c68e4a3810f34a0983be5cd68a40d1e444d54/graylog2-server/src/main/java/org/graylog/security/authservice/AuthServiceAuthenticator.java#L94).
4) The user is marked as `external`, so [an `Optional.empty` is returned instead of an authenticated user](https://github.com/Graylog2/graylog2-server/blob/368c68e4a3810f34a0983be5cd68a40d1e444d54/graylog2-server/src/main/java/org/graylog/security/authservice/backend/MongoDBAuthServiceBackend.java#L76-L80).
5) The `Optional.empty` response [causes the `authenticate` call to fail](https://github.com/Graylog2/graylog2-server/blob/368c68e4a3810f34a0983be5cd68a40d1e444d54/graylog2-server/src/main/java/org/graylog/security/authservice/AuthServiceAuthenticator.java#L97).
## Context
Existing SSO users can't login.
## Your Environment
* Graylog Version: 4.0.1-1 (Docker)
* Java Version: 1.8.0_275
* Elasticsearch Version: 6.8.9
* MongoDB Version: 4.2
* Operating System: Flatcar Container Linux by Kinvolk 2605.6.0 (Oklo)
* Browser version: Chrome 87.0.4280.141
Running on Kubernetes, SSO provided by oauth2-proxy/nginx-ingress-controller
and it seems to me that SSO should be possible by setting the REMOTE_USER header. I will need to create the users manually and I am ok with that.
OS Information: Centos 8
Package Version: Graylog 4.2.13
Is this approch viable at all?
Why is the request to graylog/api not authenticated?
How can I debug this?
Any Ideas are welcome, thanks!
gsmith
(GSmith)
November 9, 2022, 4:31am
2
Hello @Robert1
To be honest, I could not get it to work either. Only way I was able to get SSO to work was install the Enterprise/Operation version for testing. Maybe some one else here was able to achieve this.
Hello @gsmith ,
thanks for the reply.
It seems @marif made it work as stated here:
Yes this is true, for better clarity look here
EDIT:
Only the Trusted Header will work for Open source, but if you keep under 2Gb a day the Enterprise license is free.
It would be great if he could help.
1 Like
system
(system)
Closed
November 23, 2022, 8:29am
4
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.