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

[jenkins-infra-bot]

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

---

Originally reported by klattenhoff, imported from: Access Denied (Project-based Matrix Authorization Strategy)

• assignee: mindless
• status: Closed
• priority: Blocker
• component(s): _unsorted
• resolution: Fixed
• resolved: 2009-02-13T11:43:34+00:00
• votes: 0
• watchers: 3
• imported: 2025-12-08

Raw content of original issue

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

• environment: Platform: All, OS: All

1 attachment

• LDAPBindSecurityRealm.groovy

[jenkins-infra-bot]

iamsteveholmes:

• Original comment link
• Raw content of original comment:

  added myself to the CC list
  

added myself to the CC list

[jenkins-infra-bot]

dty:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

dty:

• Original comment link
• Raw content of original comment:

  Adding myself to cc
  

Adding myself to cc

[jenkins-infra-bot]

kohsuke:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original comment:

  
  	
  
  	
  
  		
  
  		
  
  			
  Issue 2375 has been marked as a duplicate of this issue. ***
  		
  		
  	
  	
  
  
  

• • • Issue 2375 has been marked as a duplicate of this issue. ***

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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?
  

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?

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original comment:

  adding myself as CC
  

adding myself as CC

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original 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
  

> 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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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..
  

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

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original 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) {
  

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.groovy2009-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) {

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

krystian_nowak:

• Original comment link
• Raw content of original comment:

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

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

[jenkins-infra-bot]

mindless:

• Original comment link
• Raw content of original 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.
  

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.