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

Access Denied (Project-based Matrix Authorization Strategy)

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Fixed
    • _unsorted
    • None
    • Platform: All, OS: All

    Description

      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
      ========================

      Attachments

        Issue Links

          Activity

            added myself to the CC list

            iamsteveholmes iamsteveholmes added a comment - added myself to the CC list
            dty 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.

            dty 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.
            dty Dean Yu added a comment -

            Adding myself to cc

            dty 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 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.
            mindless 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.

            mindless 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.
            mindless Alan Harder added a comment -
                • Issue 2375 has been marked as a duplicate of this issue. ***
            mindless 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 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.
            mindless 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?

            mindless 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 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 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
            mindless 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..

            mindless 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 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 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 Krystian Nowak added a comment - I've attached also the patched version of LDAPBindSecurityRealm.groovy
            mindless 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.

            mindless 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.
            mindless 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.

            mindless 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 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
            mindless 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

            mindless 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 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

            People

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

              Dates

                Created:
                Updated:
                Resolved: