Graylog2 / Graylog2/graylog2-server

SSO Auth is broken on 4.0+ for "Automatically created users" from legacy plugin

Open
#9,938 3 comments 8 reactions 0 assignees View on GitHub
documentation triaged
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.