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: [email protected]
Reporter: [email protected]
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 ([email protected]) and Jan Engehausen
([email protected])
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
