search

Graylog2 / graylog2-server

Free and open log management
https://www.graylog.org
Other
7.37k stars 1.06k forks source link

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

Open Capitrium opened 3 years ago

Capitrium commented 3 years ago

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 <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, so if the user.isExternalUser() check that is causing these problems were removed the password check would still be skipped 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. 2) The HTTPHeaderAuthenticationRealm creates an authenticated user object from the request data and calls authenticate. 3) The AuthServiceAuthenticator triggers a call to authenticateAndProvision for the configured backend. 4) The user is marked as external, so an Optional.empty is returned instead of an authenticated user. 5) The Optional.empty response causes the authenticate call to fail.

Context

Existing SSO users can't login.

Your Environment

Running on Kubernetes, SSO provided by oauth2-proxy/nginx-ingress-controller

Capitrium commented 3 years ago

We were able to get SSO working by manually re-creating all our users within Graylog.

It seems like the Automatically create users and Role synchronization features that were present in the old SSO plugin were replaced with the new Teams features in 4.x, which appear to be more tightly-coupled to the AD/LDAP integrations. If that's the case then this can be closed, but a note should probably be added to the upgrade docs regarding the (lack of a) migration path for users created by the old SSO plugin.

cameronattard commented 3 years ago

We also experienced this. Not ideal.

jpdstan commented 3 years ago

Also experienced this. We were able to fix this for our users without recreating accounts by toggling the external_user flag in the users table in mongo:

use graylog
db.users.update({ "external_user": true }, { $set: { "external_user": false }})

update: I'm not sure if this actually works... it doesn't seem to be handling multiple concurrent sessions correctly. I've gotten reports of 401 error messages and constant page refreshes from our users today.

2021-03-01T18:49:33.969-05:00 WARN  [ProxiedResource] Unable to call http://<redacted>:9000/api/system/metrics/multiple on node <00f996f9-e6d0-4a32-bef1-e310cf85fe2a>, result: Unauthorized
2021-03-01T18:49:32.735-05:00 WARN  [SessionAuthenticator] Terminating session where user <user_a@email.com> does not match trusted HTTP header <user_b@email.com>.

though this might be a separate issue. ~i'm also unable to use username/password authentication...~ turns out I needed to update Java