[ 
https://issues.jenkins-ci.org/browse/JENKINS-12585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162402#comment-162402
 ] 

SCM/JIRA link daemon commented on JENKINS-12585:
------------------------------------------------

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
 changelog.html
 core/src/main/java/hudson/security/AuthenticationProcessingFilter2.java
 core/src/main/resources/lib/layout/layout.jelly
 war/src/main/webapp/WEB-INF/security/SecurityFilters.groovy
http://jenkins-ci.org/commit/jenkins/7a4858d65f2431396c2f4dadbc3d654712bc02a8
Log:
  [FIXED JENKINS-12585] restrict where sessions are created.

If a resource with 'Set-Cookie' header is cached (either by intermediary
like HTTP proxy and reverse proxy, or by the browser), it'll cause
identity swap / session mix-up as discussed in this ticket.

I suspect this was caused by HttpSessionContextIntegrationFilter2, which
is the only code path that attempts to create a session when a request
to a static resource is made.

So I'm disabling the creation of session in
HttpSessionContextIntegrationFilter2. This in turn requires that we
have sessions already created when the authentication was successful and
people need to login (or else the login will have no effect.)

We already do so in layout.jelly, so any request that renders a Jenkins
page would have a session, but I've also added it in
AuthenticationProcessingFilter2, which ensures that a successful login
does have a session.



                
> SECURITY: LDAP authenticated users switch accounts randomly
> -----------------------------------------------------------
>
>                 Key: JENKINS-12585
>                 URL: https://issues.jenkins-ci.org/browse/JENKINS-12585
>             Project: Jenkins
>          Issue Type: Bug
>          Components: security
>    Affects Versions: current
>         Environment: Mac OSX: 10.6.8 Desktop
> Java version: 1.6.0_29
> Access Control
> * Security Realm: LDAP
> * Authorization: Project-based Matrix Authorization Strategy
> Jenkins: 1.448
> Apache
> * Server version: Apache/2.2.17 (Unix)
> * Server built:   Dec  1 2010 09:58:15
>            Reporter: guillermo c
>            Assignee: Kohsuke Kawaguchi
>            Priority: Critical
>
> Running Jenkins behind Apache: mod_proxy with HTTPS
> https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache
> So our setup is
> Open Directory group
> jenkins-admin - Jenkins Admins all 
> dev-group-a - Developers can view kick off builds 
> Project-based Matrix Authorization Strategy
> Admin all checked
> dev-group-a checked: Overall:Read  Job:Read,Build Run:Update
> dev-group-b checked: Overall:Read  Job:Read
> issue is I'm an admin and random developer will login and see that there user 
> id is mine and can admin jenkins.
> there has been reported cases that developer A will login and actually be 
> reported by jenkins as Developer B
> were they can no longer trigger CI builds
> My biggest concern is when users login and are reporting as admins and have 
> full access to jenkins.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to