search

Graylog2 / graylog-plugin-auth-sso

SSO support for Graylog through trusted HTTP headers set by load balancers or authentication proxies
Other
50 stars 13 forks source link

Once a graylog session exists, the user name is not checked on subsequent requests if SSO user name has changed #35

Closed ahus1 closed 3 years ago

ahus1 commented 6 years ago

Problem description

Steps to reproduce

Experienced Behavior

  1. Log in to Graylog using SSO
  2. Log out of SSO provider and log in with a different user
  3. Open Graylog URL -> the session of the old user is still active
  4. Manual Logout of the old user -> a new session for the new user is created.

Expected Behavior

  1. Log in to Graylog using SSO
  2. Log out of SSO provider and log in with a different user
  3. Open Graylog URL -> the previous session should be terminated automatically as new user name in http header doesn't match the sessions old user name.
  4. A new session should be created automatically for the new user.

Environment

ahus1 commented 6 years ago

In addition to checking the user name it would be nice to also check the user roles (see PR #25) if possible. A change in roles should issue a logout of the current session.

kroepke commented 5 years ago

This is currently not easily possible in the current implementation, because authenticators cannot interact with each other (and in fact do not even know each other).

The default is to check existing sessions first, and as long as a user request has a valid session that will be used to allow the request to proceed. The SSO plugin is essentially just checking the trusted HTTP header and creates a session for the user it is told to trust, afterwards it is not checked again.

A possible workaround is to use shorter session times, which would cause the SSO HTTP header to be checked more often.

While I agree that the current behavior is surprising and less than ideal, I cannot offer you an easy fix for it, save redesigning the entire authentication mechanism. At the very least this would require a server change, because it needs changing the authentication strategy, and this would also change semantics as that would cause e.g. one LDAP request for each request against Graylog's APIs, something that I'm sure many people would not want either.

ahus1 commented 5 years ago

@kroepke - Thanks for looking in to this. I suggest the following mechanism that might be easier to implement:

Whenever the information in the header don't match the information stored in the session, trigger a logout. I assume that comparing the information in the header with the information in the session doesn't require an LDAP request.

The next request will then trigger a an authentication with the new user information.

ahus1 commented 5 years ago

I've given it a try on checking the SSO headers on subsequent requests. There is now PR #40 that should close this issue. Feedback is welcome, please comment in the PR.