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

Access Denied (Project-based Matrix Authorization Strategy)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • _unsorted
    • None
    • Platform: All, OS: All

      Hi @ll,

      I've set up hudson (user administration of hudson itself) with Project-based
      Matrix Authorization Strategy. I've added my name and gave myself all privileges
      (including Read...). If I now close hudson (without doing something else) and
      restart it by commandline, I get the following message and have no more access
      to the configuration or anything else...

      ========================
      Access Denied

      org.acegisecurity.providers.UsernamePasswordAuthenticationToken@923d1bfd:
      Username: hudson.security.HudsonPrivateSecurityRealm$Details@1d8417c; Password:
      [PROTECTED]; Authenticated: true; Details:
      org.acegisecurity.ui.WebAuthenticationDetails@255f8: RemoteIpAddress:
      XXX.XXX.XXX.XXX; SessionId: 8013c98834de5a46ef9f6277930606ce; Granted
      Authorities: authenticated is missing Read
      ========================

          [JENKINS-2329] Access Denied (Project-based Matrix Authorization Strategy)

          added myself to the CC list

          iamsteveholmes added a comment - added myself to the CC list

          Dean Yu added a comment -

          What version of Hudson did you have this problem in? There was a bug between
          1.255 and 1.260 that caused the authorization strategy to revert after Hudson is
          restarted. 1.261 has a partial fix which will prevent this reversion, but
          exposed another problem where the security setting on individual projects was
          not remembered. This is fixed in 1.262.

          Dean Yu added a comment - What version of Hudson did you have this problem in? There was a bug between 1.255 and 1.260 that caused the authorization strategy to revert after Hudson is restarted. 1.261 has a partial fix which will prevent this reversion, but exposed another problem where the security setting on individual projects was not remembered. This is fixed in 1.262.

          Dean Yu added a comment -

          Adding myself to cc

          Dean Yu added a comment - Adding myself to cc

          For those who are seeing this problem, please report more details about your set
          up. What security realm do you use, what container do you run Hudson in, where
          did you set your permissions (is that in a project or in the system config?) Did
          you get any stack trace with the error message? etc.

          Kohsuke Kawaguchi added a comment - For those who are seeing this problem, please report more details about your set up. What security realm do you use, what container do you run Hudson in, where did you set your permissions (is that in a project or in the system config?) Did you get any stack trace with the error message? etc.

          Alan Harder added a comment -

          closing this one.. please reopen if anyone still sees this and provide more
          detail as kohsuke requested. There have been several fixes in project-specific
          permissions in the last couple months, so hopefully this one is resolved. Also
          see issue 2324 regarding read permission at project level.

          Alan Harder added a comment - closing this one.. please reopen if anyone still sees this and provide more detail as kohsuke requested. There have been several fixes in project-specific permissions in the last couple months, so hopefully this one is resolved. Also see issue 2324 regarding read permission at project level.

          Alan Harder added a comment -
              • Issue 2375 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2375 has been marked as a duplicate of this issue. ***

          The message when opening Hudson's URL in a browser for the first time since the
          browser is started:

          Access Denied

          org.acegisecurity.providers.rememberme.RememberMeAuthenticationToken@70307871:
          Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@7030cb29;
          Password: [PROTECTED]; Authenticated: true; Details:
          org.acegisecurity.ui.WebAuthenticationDetails@ffff4c9c: RemoteIpAddress:
          MY_IP_ADDRESS; SessionId: null; Granted Authorities: is missing Read

          When logging out and re-logging in it works as long as the window with Hudson's
          UI is open and autorefresh is enabled or Hudson's plugin installed in FF.

          LDAP binding is defined in Hudson's config:

          Security Realm: LDAP
          root DN: dc=myorg,dc=org
          User search base: ou=Users
          User search filter: cn=

          {0}
          Group search base: ou=Groups
          Manager DN: cn=hudson,dc=myorg,dc=org

          Authorization: Matrix-based security

          Additionally, the following patch was necessary:

          "If Hudson is set up to use LDAP for authentication, then you'll find yourself
          being locked out. This is because Hudson checks only member={0}

          , and not
          uniqueMember=

          {0} within LDAP groups. You'll have to modify the
          authoritiesPopulator function within
          WEB-INF/security/LDAPBindSecurityRealm.groovy as follows:

          authoritiesPopulator(DeferredCreationLdapAuthoritiesPopulator,initialDirContextFactory,"ou=groups")
          {
          // groupRoleAttribute = "ou";
          groupSearchFilter = "(|(member={0}

          ) (uniqueMember=

          {0}

          ))"
          }
          "

          This patch works up to ver. 1.279. It also seemed to work with 1.280, but
          finally we were locked with auth errors and unable to log in at all, which was
          even more weird than the original issue.

          The servlet container running Hudson is Apache Tomcat 6.0.16 with (more or less)
          default configuration.

          Krystian Nowak added a comment - The message when opening Hudson's URL in a browser for the first time since the browser is started: Access Denied org.acegisecurity.providers.rememberme.RememberMeAuthenticationToken@70307871: Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@7030cb29; Password: [PROTECTED] ; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@ffff4c9c: RemoteIpAddress: MY_IP_ADDRESS; SessionId: null; Granted Authorities: is missing Read When logging out and re-logging in it works as long as the window with Hudson's UI is open and autorefresh is enabled or Hudson's plugin installed in FF. LDAP binding is defined in Hudson's config: Security Realm: LDAP root DN: dc=myorg,dc=org User search base: ou=Users User search filter: cn= {0} Group search base: ou=Groups Manager DN: cn=hudson,dc=myorg,dc=org Authorization: Matrix-based security Additionally, the following patch was necessary: "If Hudson is set up to use LDAP for authentication, then you'll find yourself being locked out. This is because Hudson checks only member={0} , and not uniqueMember= {0} within LDAP groups. You'll have to modify the authoritiesPopulator function within WEB-INF/security/LDAPBindSecurityRealm.groovy as follows: authoritiesPopulator(DeferredCreationLdapAuthoritiesPopulator,initialDirContextFactory,"ou=groups") { // groupRoleAttribute = "ou"; groupSearchFilter = "(|(member={0} ) (uniqueMember= {0} ))" } " This patch works up to ver. 1.279. It also seemed to work with 1.280, but finally we were locked with auth errors and unable to log in at all, which was even more weird than the original issue. The servlet container running Hudson is Apache Tomcat 6.0.16 with (more or less) default configuration.

          Alan Harder added a comment -

          questions:
          1) what permissions are granted to Anonymous, and are other permissions granted
          directly to particular users or are you using groups?
          2) does the problem only occur when you clicked "remember me" when logging in?
          if you remove all hudson cookies and then visit the site, any errors?

          Alan Harder added a comment - questions: 1) what permissions are granted to Anonymous, and are other permissions granted directly to particular users or are you using groups? 2) does the problem only occur when you clicked "remember me" when logging in? if you remove all hudson cookies and then visit the site, any errors?

          adding myself as CC

          Krystian Nowak added a comment - adding myself as CC

          > 1) what permissions are granted to Anonymous,
          Anonymous - no permissions at all

          > and are other permissions granted directly to particular users or are you
          using groups?
          mostly groups, but there are certain users too, although the user on which I am
          testing this issue is not listed there directly, it just belongs to some of the
          groups

          > 2) does the problem only occur when you clicked "remember me" when logging in?
          yes

          > if you remove all hudson cookies and then visit the site, any errors?
          no errors, just asks for login and password - seems that when this cookie is
          present - ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE - the the problem can be seen

          Krystian Nowak added a comment - > 1) what permissions are granted to Anonymous, Anonymous - no permissions at all > and are other permissions granted directly to particular users or are you using groups? mostly groups, but there are certain users too, although the user on which I am testing this issue is not listed there directly, it just belongs to some of the groups > 2) does the problem only occur when you clicked "remember me" when logging in? yes > if you remove all hudson cookies and then visit the site, any errors? no errors, just asks for login and password - seems that when this cookie is present - ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE - the the problem can be seen

          Alan Harder added a comment -

          confirmed.. I did some tests and found that the group lookup is not done when
          you get logged in via the remember-me cookie. So you're logged in, but Hudson
          doesn't know what groups you are in. In your case where there is no public read
          access, you are then locked out. researching fix/workaround..

          Alan Harder added a comment - confirmed.. I did some tests and found that the group lookup is not done when you get logged in via the remember-me cookie. So you're logged in, but Hudson doesn't know what groups you are in. In your case where there is no public read access, you are then locked out. researching fix/workaround..

          We've been just checking with the newest available (1.282) version and the issue
          still happening.
          Of course I needed to apply our LDAP-compatibility patch into
          "LDAPBindSecurityRealm.groovy" file.
          For current (1.282) Hudson version the patch looks a little bit different than
          given in the previous comments (for 1.279), due to change in
          "authoritiesPopulator" method signature:

              • LDAPBindSecurityRealm.groovy 2009-02-08 22:09:52.000000000 +0000
              • ../patched/LDAPBindSecurityRealm.groovy 2009-02-13 07:39:49.000000000 +0000
                ***************
              • 62,67 ****
              • 62,68 ----
                authoritiesPopulator(DefaultLdapAuthoritiesPopulator,
                initialDirContextFactory, Util.fixNull(instance.groupSearchBase))
                Unknown macro: { // see DefaultLdapAuthoritiesPopulator for other possible configurations searchSubtree = true;+ groupSearchFilter = "(|(member={0}) (uniqueMember={0}))"; }

          authenticationManager(ProviderManager) {

          Krystian Nowak added a comment - We've been just checking with the newest available (1.282) version and the issue still happening. Of course I needed to apply our LDAP-compatibility patch into "LDAPBindSecurityRealm.groovy" file. For current (1.282) Hudson version the patch looks a little bit different than given in the previous comments (for 1.279), due to change in "authoritiesPopulator" method signature: LDAPBindSecurityRealm.groovy 2009-02-08 22:09:52.000000000 +0000 ../patched/LDAPBindSecurityRealm.groovy 2009-02-13 07:39:49.000000000 +0000 *************** 62,67 **** 62,68 ---- authoritiesPopulator(DefaultLdapAuthoritiesPopulator, initialDirContextFactory, Util.fixNull(instance.groupSearchBase)) Unknown macro: { // see DefaultLdapAuthoritiesPopulator for other possible configurations searchSubtree = true;+ groupSearchFilter = "(|(member={0}) (uniqueMember={0}))"; } authenticationManager(ProviderManager) {

          Created an attachment (id=558)
          LDAPBindSecurityRealm.groovy - patched to work with our LDAP

          Krystian Nowak added a comment - Created an attachment (id=558) LDAPBindSecurityRealm.groovy - patched to work with our LDAP

          I've attached also the patched version of LDAPBindSecurityRealm.groovy

          Krystian Nowak added a comment - I've attached also the patched version of LDAPBindSecurityRealm.groovy

          Alan Harder added a comment -

          I found that the remember-me service uses the UserDetailsService created in
          Hudson's LDAPSecurityRealm.createSecurityComponents() to do the user lookup, and
          the LdapUserSearch used in there does not do a group lookup. I can add this,
          doing just what acegi's LdapAuthenticationProvider.createUserDetails() does to
          lookup and add granted authorities before returning the final UserDetails.

          Alan Harder added a comment - I found that the remember-me service uses the UserDetailsService created in Hudson's LDAPSecurityRealm.createSecurityComponents() to do the user lookup, and the LdapUserSearch used in there does not do a group lookup. I can add this, doing just what acegi's LdapAuthenticationProvider.createUserDetails() does to lookup and add granted authorities before returning the final UserDetails.

          Alan Harder added a comment -

          r15290 | mindless | 2009-02-13 09:49:36 -0700 (Fri, 13 Feb 2009) | 2 lines
          Changed paths:
          M /trunk/hudson/main/core/src/main/java/hudson/security/LDAPSecurityRealm.java
          M /trunk/www/changelog.html

          [FIXED JENKINS-2329] LDAP group permissions were not applied when logged in via
          remember-me cookie.

          Alan Harder added a comment - r15290 | mindless | 2009-02-13 09:49:36 -0700 (Fri, 13 Feb 2009) | 2 lines Changed paths: M /trunk/hudson/main/core/src/main/java/hudson/security/LDAPSecurityRealm.java M /trunk/www/changelog.html [FIXED JENKINS-2329] LDAP group permissions were not applied when logged in via remember-me cookie.

          For me the issue with remember-me cookie now works (tested on Hudson ver. 1.288).
          Although I still need to apply the patch to LDAPBindSecurityRealm.groovy to
          tweak it to my LDAP structure, but that seems to be a different issue.
          Thanks for resolving it!

          Kind regards,
          Krystian Nowak

          Krystian Nowak added a comment - For me the issue with remember-me cookie now works (tested on Hudson ver. 1.288). Although I still need to apply the patch to LDAPBindSecurityRealm.groovy to tweak it to my LDAP structure, but that seems to be a different issue. Thanks for resolving it! Kind regards, Krystian Nowak

          Alan Harder added a comment -

          great, thanks.. FYI, soon you shouldn't need the groovy patch.. it seems in some
          restructuring in 1.280 that setting was lost, but we'll get it added back. see
          issue #2256

          Alan Harder added a comment - great, thanks.. FYI, soon you shouldn't need the groovy patch.. it seems in some restructuring in 1.280 that setting was lost, but we'll get it added back. see issue #2256

          Thanks for info on #2256! So, I'll just wait for Hudson 1.289 and we'll see

          Regards,
          Krystian Nowak

          Krystian Nowak added a comment - Thanks for info on #2256! So, I'll just wait for Hudson 1.289 and we'll see Regards, Krystian Nowak

            mindless Alan Harder
            klattenhoff klattenhoff
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: