https://bz.apache.org/bugzilla/show_bug.cgi?id=60824
Bug ID: 60824 Summary: Subject incorrectly removed from user session Product: Tomcat 7 Version: 7.0.47 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: smurf...@gmail.com Target Milestone: --- In our setup we have global security enabled, and we're using Spring Security with a pre-authenticated scenario in the web application. We're seeing a (very likely platform-indepedent) issue with unexpected javax.security.auth.Subject instances and unexpected java.security.Principal instances contained in those Subject instances. We see each request exposes a new Subject instance, and under load (same user session, concurrent requests) a Principal created by Spring is present in the set of principals of the Subject instance, whilst the Tomcat-managed one is not present. The problem has been observed on Linux and Windows. We're using the following Java versions: - Linux: Java(TM) SE Runtime Environment (build 1.8.0_60-b27) - Windows: Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Tomcat Connector Linux: <Connector URIEncoding="UTF-8" scheme="http" protocol="HTTP/1.1" connectionTimeout="20000" port="..."/> Windows: Embedded Tomcat 7.0.47 via Maven Tomcat plugin Tomcat is not used behind Apache HTTPD or any other web server. We have debugged the issue and believe the cause lies in org.apache.catalina.connector.Request.setUserPrincipal(Principal) The code in this method tries to cache the Subject in the user session, but (accidentally?) removes it from the session at the beginning of every request. This is because the variable "subject" is always "null" when "session.setAttribute(Globals.SUBJECT_ATTR, subject);" is called, unless the session did not carry a subject yet. Further code in Tomcat uses the session to obtain and cache the Subject in the session, e.g. org.apache.catalina.security.SecurityUtil.execute(Method, Object, Object[], Principal). In there, if no Subject is found in the session, a new instance is created with the Principal of the current request, stored in the session and used as the current JAAS subject. Concurrent requests from the same user session may cause race conditions, as the Subject is removed from the session but also cached by these parts of the code. We have created a simple reproduceable test, see below, which verifies that the Tomcat-managed principal is found in the Principal set of the current Subject. In error cases, only a Spring-managed Principal is found. In our actual real-life case, our code relies on Principal objects created by a custom login module, which are sometimes not found, thus causing the real application to fail. Overview If global security is enabled and a session exists, the Subject is removed from the session at the beginning of each request. Reproducer Find details and how to run at https://github.com/smurf667/test-tomcat-broken-subject The test setup uses an integration test with an embedded Tomcat to send a number of concurrent requests for a single user session. A Spring filter in the application makes sure that a Tomcat-managed Principal created is present in the subject. If not, the application fails. Expected: The Subject present for each request of the same user session contains a Tomcat-managed Principal. Actual: Sometimes the Subject only contains a Spring-managed Principal. We're suggesting a potential fix for the issue in the README.md of the repository. As we're no experts, we leave it to the person handling our bug report to judge if the fix is appropriate or not (we believe so). Please ask if you have any further questions, thanks! Kind regards, Sebastian Hähnel (sebastian.haeh...@gmail.com) and Jan Engehausen (smurf...@gmail.com) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org