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

Reverse proxy auth is not authenticating users

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After configuring the reverse-proxy-auth-plugin, users are not authenticated in Jenkins.

      it appears that ReverseProxySecurityRealm is correctly identifying the user from the following logs:

      PM FINE org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm
      USER LOGGED IN: tad@simple.com
      

      However, DefaultReverseProxyAuthenticator does not appear to receive the username:

      PM INFO org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
      DefaultReverseProxyAuthenticator::authenticate ==> null to [Lorg.acegisecurity.GrantedAuthority;@6d8c3052
      

      We are not using LDAP authentication.

      Here is the relevant section of config.xml:

        <securityRealm class="org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm" plugin="reverse-proxy-auth-plugin@1.6.2">
          <proxyTemplate/>
          <inhibitInferRootDN>false</inhibitInferRootDN>
          <userSearchBase></userSearchBase>
          <userSearch>uid={0}</userSearch>
          <updateInterval>15</updateInterval>
          <forwardedUser>X-Simple-Internal-User</forwardedUser>
          <retrievedUser>vanvlack@simple.com</retrievedUser>
          <headerGroups></headerGroups>
          <headerGroupsDelimiter>|</headerGroupsDelimiter>
          <disableLdapEmailResolver>true</disableLdapEmailResolver>
          <displayNameLdapAttribute></displayNameLdapAttribute>
          <emailAddressLdapAttribute></emailAddressLdapAttribute>
        </securityRealm>
      

      What's interesting is the persistence of "retrievedUser", which might mean a leak of transient state.

      Attached is a sanitized dump of /whoAmI.

        Attachments

          Activity

          tad Tad Fisher created issue -
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Tad Fisher AFAICT it's still a follow-up to the original fix in JENKINS-49236.
          the authenticator does not get the context correctly. Although we fixed NPEs in such case, a main objective would be to debug the plugin and to understand why it fails in such way. Would you be able to debug it on your instance?

          CC Wadeck Follonier

          Show
          oleg_nenashev Oleg Nenashev added a comment - Tad Fisher AFAICT it's still a follow-up to the original fix in JENKINS-49236 . the authenticator does not get the context correctly. Although we fixed NPEs in such case, a main objective would be to debug the plugin and to understand why it fails in such way. Would you be able to debug it on your instance? CC Wadeck Follonier
          tad Tad Fisher made changes -
          Field Original Value New Value
          Attachment whoami.html [ 41286 ]
          tad Tad Fisher made changes -
          Description After configuring the reverse-proxy-auth-plugin, users are not authenticated in Jenkins.

          it appears that ReverseProxySecurityRealm is correctly identifying the user from the following logs:
          {noformat}
          PM FINE org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm
          USER LOGGED IN: tad@simple.com
          {noformat}
          However, DefaultReverseProxyAuthenticator does not appear to receive the username:
          {noformat}
          PM INFO org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
          DefaultReverseProxyAuthenticator::authenticate ==> null to [Lorg.acegisecurity.GrantedAuthority;@6d8c3052
          {noformat}

          We are not using LDAP authentication.

          Here is the relevant section of config.xml:

          {noformat}
            <securityRealm class="org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm" plugin="reverse-proxy-auth-plugin@1.6.2">
              <proxyTemplate/>
              <inhibitInferRootDN>false</inhibitInferRootDN>
              <userSearchBase></userSearchBase>
              <userSearch>uid={0}</userSearch>
              <updateInterval>15</updateInterval>
              <forwardedUser>X-Simple-Internal-User</forwardedUser>
              <retrievedUser>vanvlack@simple.com</retrievedUser>
              <headerGroups></headerGroups>
              <headerGroupsDelimiter>|</headerGroupsDelimiter>
              <disableLdapEmailResolver>true</disableLdapEmailResolver>
              <displayNameLdapAttribute></displayNameLdapAttribute>
              <emailAddressLdapAttribute></emailAddressLdapAttribute>
            </securityRealm>
          {noformat}

          What's interesting is the persistence of "retrievedUser", which might mean a leak of transient state.
          After configuring the reverse-proxy-auth-plugin, users are not authenticated in Jenkins.

          it appears that ReverseProxySecurityRealm is correctly identifying the user from the following logs:
          {noformat}
          PM FINE org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm
          USER LOGGED IN: tad@simple.com
          {noformat}
          However, DefaultReverseProxyAuthenticator does not appear to receive the username:
          {noformat}
          PM INFO org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
          DefaultReverseProxyAuthenticator::authenticate ==> null to [Lorg.acegisecurity.GrantedAuthority;@6d8c3052
          {noformat}

          We are not using LDAP authentication.

          Here is the relevant section of config.xml:

          {noformat}
            <securityRealm class="org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm" plugin="reverse-proxy-auth-plugin@1.6.2">
              <proxyTemplate/>
              <inhibitInferRootDN>false</inhibitInferRootDN>
              <userSearchBase></userSearchBase>
              <userSearch>uid={0}</userSearch>
              <updateInterval>15</updateInterval>
              <forwardedUser>X-Simple-Internal-User</forwardedUser>
              <retrievedUser>vanvlack@simple.com</retrievedUser>
              <headerGroups></headerGroups>
              <headerGroupsDelimiter>|</headerGroupsDelimiter>
              <disableLdapEmailResolver>true</disableLdapEmailResolver>
              <displayNameLdapAttribute></displayNameLdapAttribute>
              <emailAddressLdapAttribute></emailAddressLdapAttribute>
            </securityRealm>
          {noformat}

          What's interesting is the persistence of "retrievedUser", which might mean a leak of transient state.

          Attached is a sanitized dump of /whoAmI.
          Hide
          tad Tad Fisher added a comment -

          Oleg Nenashev Yes, I'd be able to help. Are you available on IRC somewhere?

          Show
          tad Tad Fisher added a comment - Oleg Nenashev Yes, I'd be able to help. Are you available on IRC somewhere?
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Usually "yes". oleg_nenashev in standard Jenkins channels. Traveling today tho

          Show
          oleg_nenashev Oleg Nenashev added a comment - Usually "yes". oleg_nenashev in standard Jenkins channels. Traveling today tho
          Hide
          kjpopovbg Krasimir Popov added a comment -

          I am experiencing the same or similar issue, Jenkins ver. 2.105 and 

          Reverse Proxy Auth Plugin v1.6.2 

          When I go to https://myjenkinsurl/whoAmI/ I see that the header which is in my case ( X-Remote-User = my.username) is present but I am still authenticated as Anonimous.

          For some reason it does not respect the header anymore after I upgraded.

           

          Show
          kjpopovbg Krasimir Popov added a comment - I am experiencing the same or similar issue,  Jenkins ver. 2.105  and  Reverse Proxy Auth Plugin v1.6.2  When I go to https://myjenkinsurl/whoAmI/  I see that the header which is in my case ( X-Remote-User = my.username) is present but I am still authenticated as Anonimous. For some reason it does not respect the header anymore after I upgraded.  
          oleg_nenashev Oleg Nenashev made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          oleg_nenashev Oleg Nenashev made changes -
          Assignee Oleg Nenashev [ oleg_nenashev ] Tad Fisher [ tad ]
          oleg_nenashev Oleg Nenashev made changes -
          Status In Progress [ 3 ] In Review [ 10005 ]
          oleg_nenashev Oleg Nenashev made changes -
          Remote Link This issue links to "https://github.com/jenkinsci/reverse-proxy-auth-plugin/pull/36 (Web Link)" [ 20017 ]
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Krasimir Popov could you please take a Snapshot build from https://github.com/jenkinsci/reverse-proxy-auth-plugin/pull/36 and confirm whether it works for you?

          Show
          oleg_nenashev Oleg Nenashev added a comment - Krasimir Popov could you please take a Snapshot build from https://github.com/jenkinsci/reverse-proxy-auth-plugin/pull/36 and confirm whether it works for you?
          Hide
          kjpopovbg Krasimir Popov added a comment -

          How do I do this where can I download .jar or pull docker image or something?

          Show
          kjpopovbg Krasimir Popov added a comment - How do I do this where can I download .jar or pull docker image or something?
          Hide
          oleg_nenashev Oleg Nenashev added a comment -
          Show
          oleg_nenashev Oleg Nenashev added a comment - Krasimir Popov You can download plugin HPI from https://ci.jenkins.io/job/Plugins/job/reverse-proxy-auth-plugin/job/PR-36/1/artifact/target/reverse-proxy-auth-plugin.hpi and then install it in Plugin Manager
          Hide
          kjpopovbg Krasimir Popov added a comment -

          Worked as a charm, Looking forward for the stable version to roll in production.

          Thanks!

          Show
          kjpopovbg Krasimir Popov added a comment - Worked as a charm, Looking forward for the stable version to roll in production. Thanks!
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          Will release it tomorrow once I have a network which allows releasing

          Show
          oleg_nenashev Oleg Nenashev added a comment - Will release it tomorrow once I have a network which allows releasing
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Tad Fisher
          Path:
          src/main/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealm.java
          src/test/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealmTest.java
          http://jenkins-ci.org/commit/reverse-proxy-auth-plugin/85f1a6b0b6ebd2b24e6e6b5498b2ce3ee035798b
          Log:
          JENKINS-49274 Run reverse-proxy filter after default filter

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Tad Fisher Path: src/main/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealm.java src/test/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealmTest.java http://jenkins-ci.org/commit/reverse-proxy-auth-plugin/85f1a6b0b6ebd2b24e6e6b5498b2ce3ee035798b Log: JENKINS-49274 Run reverse-proxy filter after default filter
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          src/main/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealm.java
          src/test/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealmTest.java
          http://jenkins-ci.org/commit/reverse-proxy-auth-plugin/0f3dc2d8e13a2fc3de29f6e14bf6840ecaa8f032
          Log:
          Merge pull request #36 from tadfisher/jenkins-49274

          JENKINS-49274 Run reverse-proxy filter after default filter

          Compare: https://github.com/jenkinsci/reverse-proxy-auth-plugin/compare/cc9829233246...0f3dc2d8e13a

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: src/main/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealm.java src/test/java/org/jenkinsci/plugins/reverse_proxy_auth/ReverseProxySecurityRealmTest.java http://jenkins-ci.org/commit/reverse-proxy-auth-plugin/0f3dc2d8e13a2fc3de29f6e14bf6840ecaa8f032 Log: Merge pull request #36 from tadfisher/jenkins-49274 JENKINS-49274 Run reverse-proxy filter after default filter Compare: https://github.com/jenkinsci/reverse-proxy-auth-plugin/compare/cc9829233246...0f3dc2d8e13a
          Hide
          oleg_nenashev Oleg Nenashev added a comment -

          It has been released in 1.6.3

          Show
          oleg_nenashev Oleg Nenashev added a comment - It has been released in 1.6.3
          oleg_nenashev Oleg Nenashev made changes -
          Status In Review [ 10005 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          llg Laurent Le Grandois added a comment -

          Same problem with 1.6.3 :

          févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
          INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null
          févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
          INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null
          févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate
          INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null

           

          Need to revert to 1.5 

          Show
          llg Laurent Le Grandois added a comment - Same problem with 1.6.3 : févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null févr. 09, 2018 7:38:33 AM org.jenkinsci.plugins.reverse_proxy_auth.auth.DefaultReverseProxyAuthenticator authenticate INFOS: DefaultReverseProxyAuthenticator::authenticate ==> null to null   Need to revert to 1.5 
          Hide
          kjpopovbg Krasimir Popov added a comment -

          For me it works fine with the Snapshot build and with the official 1.6.3 release.
           Jenkins ver. 2.105  and Plugin v1.6.3 in production since this morning and no issues since then.

          Laurent Le Grandois  give more details about your entire setup so we can reproduce.

           

          Show
          kjpopovbg Krasimir Popov added a comment - For me it works fine with the Snapshot build and with the official 1.6.3 release.   Jenkins ver. 2.105   and Plugin v1.6.3 in production since this morning and no issues since then. Laurent Le Grandois   give more details about your entire setup so we can reproduce.  
          Hide
          llg Laurent Le Grandois added a comment - - edited

          Hi,

           here is the configuration :

          Centos 7 :

          • httpd-2.4.6-67.el7.centos.6.x86_64
          • jenkins-2.105-1.1.noarch

          Jenkins config :

          <securityRealm class="org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm" plugin="reverse-proxy-auth-plugin@1.5"> 
              <proxyTemplate/> 
              <authContext/> 
              <authorityUpdateCache/> 
              <inhibitInferRootDN>false</inhibitInferRootDN> 
              <userSearchBase></userSearchBase> 
              <userSearch>uid={0}</userSearch> 
              <updateInterval>15</updateInterval> 
              <forwardedUser>X-Alfresco-Remote-User</forwardedUser> 
              <headerGroups>X-Forwarded-Groups</headerGroups> 
              <headerGroupsDelimiter>|</headerGroupsDelimiter> 
              <disableLdapEmailResolver>false</disableLdapEmailResolver> 
              <displayNameLdapAttribute></displayNameLdapAttribute> 
              <emailAddressLdapAttribute></emailAddressLdapAttribute> 
            </securityRealm>

          Apache config :

           

          <Location />
           AuthBasicProvider file ldap
           AuthType Basic
           AuthName "Ldap Authentication"
           AuthUserFile "/etc/httpd/security/passwd"
           AuthLDAPURL ldaps:************************?uid
           AuthLDAPBindDN uid=***************************
           AuthLDAPBindPassword "***************"
           Require valid-user
           RewriteEngine On
           RewriteCond %{LA-U:REMOTE_USER} (.+)
           RewriteRule . - [E=RU:%1,NS]
           RequestHeader set X-Alfresco-Remote-User "%{RU}e"
           RewriteRule ^ - [E=X-Alfresco-Remote-User:${uc:%{LA-U:X-Alfresco-Remote-User}},NS,L]
           Options +Indexes
          </Location>
          
          RewriteCond %{REQUEST_URI} ^/computer/.*$ 
          RewriteRule ^/computer/(.*)$ /jenkins/computer/$1 [L,R] 
          
          ProxyPass /jenkins http://localhost:8080/jenkins 
          ProxyPassReverse /jenkins http://localhost:8080/jenkins
          
          
          

           

          Show
          llg Laurent Le Grandois added a comment - - edited Hi,  here is the configuration : Centos 7 : httpd-2.4.6-67.el7.centos.6.x86_64 jenkins-2.105-1.1.noarch Jenkins config : <securityRealm class= "org.jenkinsci.plugins.reverse_proxy_auth.ReverseProxySecurityRealm" plugin= "reverse-proxy-auth-plugin@1.5" >    <proxyTemplate/>    <authContext/>    <authorityUpdateCache/>    <inhibitInferRootDN> false </inhibitInferRootDN>    <userSearchBase></userSearchBase>    <userSearch>uid={0}</userSearch>    <updateInterval>15</updateInterval>    <forwardedUser>X-Alfresco-Remote-User</forwardedUser>    <headerGroups>X-Forwarded-Groups</headerGroups>    <headerGroupsDelimiter>|</headerGroupsDelimiter>    <disableLdapEmailResolver> false </disableLdapEmailResolver>    <displayNameLdapAttribute></displayNameLdapAttribute>    <emailAddressLdapAttribute></emailAddressLdapAttribute>  </securityRealm> Apache config :   <Location /> AuthBasicProvider file ldap AuthType Basic AuthName "Ldap Authentication" AuthUserFile "/etc/httpd/security/passwd" AuthLDAPURL ldaps:************************?uid AuthLDAPBindDN uid=*************************** AuthLDAPBindPassword "***************" Require valid-user RewriteEngine On RewriteCond %{LA-U:REMOTE_USER} (.+) RewriteRule . - [E=RU:%1,NS] RequestHeader set X-Alfresco-Remote-User "%{RU}e" RewriteRule ^ - [E=X-Alfresco-Remote-User:${uc:%{LA-U:X-Alfresco-Remote-User}},NS,L] Options +Indexes </Location> RewriteCond %{REQUEST_URI} ^/computer/.*$ RewriteRule ^/computer/(.*)$ /jenkins/computer/$1 [L,R] ProxyPass /jenkins http: //localhost:8080/jenkins ProxyPassReverse /jenkins http: //localhost:8080/jenkins  
          Hide
          kjpopovbg Krasimir Popov added a comment -

          When you visit https://yourjenkinsurl/whoAmI/ 
          do you have the 
          X-Alfresco-Remote-User
          present there?

           

          Show
          kjpopovbg Krasimir Popov added a comment - When you visit https://yourjenkinsurl/whoAmI/   do you have the  X-Alfresco-Remote-User present there?  
          Hide
          llg Laurent Le Grandois added a comment - - edited

          Authorization: Basic is correctly setted and other backends behind this reverse-proxy (Alfresco, Nexus, etc ..) got user id from Apache.

           

          PS : sorry, didn't see your html file : no, header doesn't appear

          Show
          llg Laurent Le Grandois added a comment - - edited Authorization: Basic is correctly setted and other backends behind this reverse-proxy (Alfresco, Nexus, etc ..) got user id from Apache.   PS : sorry, didn't see your html file : no, header doesn't appear
          Hide
          kjpopovbg Krasimir Popov added a comment -

          I was just digging into a problem with Jenkins swarm plugin that I had after the upgrade and I noticed then now they changed the order of authentication somehow and if Authorization: Basic is present it will take advantage over the custom header you are sending to the Reverse proxy auth plugin. The result of this is that you will get 401 HTTP error from the Jetty server.

          You need to configure your apache to remove the Authorization header.

          For nginx I did
          proxy_set_header    Authorization "";

          Not sure what is the equivalent for Apache.

          Show
          kjpopovbg Krasimir Popov added a comment - I was just digging into a problem with Jenkins swarm plugin that I had after the upgrade and I noticed then now they changed the order of authentication somehow and if Authorization: Basic is present it will take advantage over the custom header you are sending to the Reverse proxy auth plugin. The result of this is that you will get 401 HTTP error from the Jetty server. You need to configure your apache to remove the Authorization header. For nginx I did proxy_set_header    Authorization ""; Not sure what is the equivalent for Apache.
          Hide
          llg Laurent Le Grandois added a comment -

          Hi Krasimir, 

           it works !! 

          Config for Apache is :

            <Location /jenkins> 
                RequestHeader set Authorization "" 
             </Location>

          Thanks

          Show
          llg Laurent Le Grandois added a comment - Hi Krasimir,   it works !!  Config for Apache is :   <Location /jenkins>      RequestHeader set Authorization ""   </Location> Thanks
          Hide
          kjpopovbg Krasimir Popov added a comment -

          Glad to hear that.

          Cheers...

          Show
          kjpopovbg Krasimir Popov added a comment - Glad to hear that. Cheers...
          Hide
          chancez Chance Zibolski added a comment -

          I think I am also hitting this. I can auth as my user, but my swarm agents aren't able to get through. The proxy is authenticating them successfully, and should be forwarding the user via the X-Forwarded-For header which is how I've configured jenkins, but the agents just are stuck 401ing the whole time against the /plugin/swarm/slaveInfo url.

          Show
          chancez Chance Zibolski added a comment - I think I am also hitting this. I can auth as my user, but my swarm agents aren't able to get through. The proxy is authenticating them successfully, and should be forwarding the user via the X-Forwarded-For header which is how I've configured jenkins, but the agents just are stuck 401ing the whole time against the /plugin/swarm/slaveInfo url.
          Hide
          kjpopovbg Krasimir Popov added a comment -

          What kind of webserver you use to proxy the requests. You need to ensure that all other unnecessary authentication headers are removed (Not proxied to jenkins jetty server). In the case of swarm it is basic auth and the header that you have to remove is Authorization.

          For nginx
          proxy_set_header    Authorization "";
          For Apache
            <Location /jenkins>
               RequestHeader set Authorization ""
            </Location>
           

          I believe that this is more feature rather then a bug, jenkins security is improved and now there is better order of security layers. If Authorization header is present then jenkins follows to that and you will get 401. Your X-Forwarded-For header is ignored in that case.

          Show
          kjpopovbg Krasimir Popov added a comment - What kind of webserver you use to proxy the requests. You need to ensure that all other unnecessary authentication headers are removed (Not proxied to jenkins jetty server). In the case of swarm it is basic auth and the header that you have to remove is Authorization. For nginx proxy_set_header    Authorization ""; For Apache   <Location /jenkins>      RequestHeader set Authorization ""   </Location>   I believe that this is more feature rather then a bug, jenkins security is improved and now there is better order of security layers. If Authorization header is present then jenkins follows to that and you will get 401. Your X-Forwarded-For header is ignored in that case.
          Hide
          roadrunner2 roadrunner2 added a comment -

          For Apache I think the more proper setting is:

          <Location /jenkins>
              RequestHeader unset Authorization
          </Location>
          

          (verified this fixes the issues for me too)

           

          Show
          roadrunner2 roadrunner2 added a comment - For Apache I think the more proper setting is: <Location /jenkins> RequestHeader unset Authorization </Location> (verified this fixes the issues for me too)  

            People

            • Assignee:
              tad Tad Fisher
              Reporter:
              tad Tad Fisher
            • Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: