Graylog2 / Graylog2/graylog2-server
SSO Auth is broken on 4.0+ for "Automatically created users" from legacy plugin
- Dominant language
- Java
- Stars
- 8.1k
- Forks
- 1.1k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 217
Description
Upgrading our Graylog server from 3.3.9 to 4.0.1 (and removing the old SSO plugin) 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
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 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 from trusted HTTP header 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
Contributor guide
Assessment
This issue has not been assessed yet.