Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59107

User logged out after successful configuration of "Run as Specific User" (as of Jenkins 2.150.2)

    • Jenkins 2.210

      Actual behaviour

      As user "A" when configuring authorization
      using the "Run as Specific User" strategy to run a job as user "B"
      after successful authentication with the password of user "B"
      user "A" is logged out.

      Expected behaviour

      User "A" is still logged in.

      Root Cause Analysis

      This issue is present starting with Jenkins 2.150.2 which implemented new security measures for user sessions (see changelog https://jenkins.io/changelog-stable/#v2.150.2). It seems that the below call from here invalidates the current user session:

      Jenkins.getActiveInstance().getSecurityRealm().getSecurityComponents().manager.authenticate(
          new UsernamePasswordAuthenticationToken(userId, password)
      );
      

          [JENKINS-59107] User logged out after successful configuration of "Run as Specific User" (as of Jenkins 2.150.2)

          René Scheibe added a comment -

          ikedam / stephenconnolly do you have a suggestion?

          René Scheibe added a comment - ikedam / stephenconnolly do you have a suggestion?

          ikedam added a comment -

          Actually, I don't have any idea for this.

          This might be a bug of Jenkins core as setting session seed of user B to user A doesn't look appropriate behavior.
          On the other hand, Jenkins core doesn't expect "authenticate" is used by other users.

          ikedam added a comment - Actually, I don't have any idea for this. The change causing this issue is SECURITY-901 https://jenkins.io/security/advisory/2019-01-16/#SECURITY-901 https://github.com/jenkinsci/jenkins/commit/8c490d14c4ffe6162f6e97d25a66612330fe2ace When authenticated as user B, the session seed for user B is set by UserSeedSecurityListener. This invalidates session for user A. Users can disable this behavior with "-Djenkins.security.seed.UserSeedProperty.disableUserSeed=true" This might be a bug of Jenkins core as setting session seed of user B to user A doesn't look appropriate behavior. On the other hand, Jenkins core doesn't expect "authenticate" is used by other users.

          ikedam added a comment -

          wfollonier Would you have a look on this issue?
          (I mention you as you look the author of the fix for SECURITY-901)

          I want your comment about this:
          > This might be a bug of Jenkins core as setting session seed of user B to user A doesn't look appropriate behavior.

          ikedam added a comment - wfollonier Would you have a look on this issue? (I mention you as you look the author of the fix for SECURITY-901) I want your comment about this: > This might be a bug of Jenkins core as setting session seed of user B to user A doesn't look appropriate behavior.

          ikedam I put that in my todo list, not ETA unfortunately

          Wadeck Follonier added a comment - ikedam I put that in my todo list, not ETA unfortunately

          Matt Sicker added a comment -

          I've isolated this problem to the code in UserSeedSecurityListener.authenticated() which will overwrite the current session's user seed with the authorized user's seed instead. This seed is not restored after the build completes (or ever), so essentially, you end up with the authorize user's session which doesn't work.

          Matt Sicker added a comment - I've isolated this problem to the code in UserSeedSecurityListener.authenticated() which will overwrite the current session's user seed with the authorized user's seed instead. This seed is not restored after the build completes (or ever), so essentially, you end up with the authorize user's session which doesn't work.

          Matt Sicker added a comment -

          PR to fix this open for review: https://github.com/jenkinsci/jenkins/pull/4394

          Matt Sicker added a comment - PR to fix this open for review: https://github.com/jenkinsci/jenkins/pull/4394

          Important point to mention in the description, to trigger the "password" field to appear, you need to lack admin permission as the user A. I installed matrix-auth to achieve that easily.

          Wadeck Follonier added a comment - Important point to mention in the description, to trigger the "password" field to appear, you need to lack admin permission as the user A. I installed matrix-auth to achieve that easily.

          Matt Sicker added a comment -

          Ah, that explains some test failures I came across at one point when testing out different combinations of versions.

          Matt Sicker added a comment - Ah, that explains some test failures I came across at one point when testing out different combinations of versions.

          Oleg Nenashev added a comment -

          Released in Jenkins 2.210, will mark as LTS candidate

          Oleg Nenashev added a comment - Released in Jenkins 2.210, will mark as LTS candidate

            jvz Matt Sicker
            renescheibe René Scheibe
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: