Re: EJB & Web App losing Subject
djencks wrote:
>
> Subject subject = getSpringAuthenticatedSubject();
> ContextManager.registerSubject(subject); //if the subject is cached in
> a session this should only happen once when the subject is first
> authenticated/constructed.
>
> //the following should happen on every request
> ContextManager.setCallers(subject, subject);
> try {
> //process request
> } finally {
>ContextManager.clearCallers();
> }
>
Our custom Spring authenticator contains calls to ContextManager.login and
setCallers. If we need to call setCallers for every request, then that
would explain this bug. We only call it once, and don't call clearCallers,
so the subject is staying around in the original thread but subsequent
threads never get initialized properly.
Sounds like the proper solution is just a simple filter that does the
setCallers and clearCallers. Thanks for all the help.
--
View this message in context:
http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24502831.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
rdContextValve.java: 191) at org .apache .geronimo .tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org .apache .geronimo .tomcat .valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java: 47) at org .apache .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org .apache .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org .apache .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 568) at org .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286) at org .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 845) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint $Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24502397.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
t.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.ui.SessionFixationProtectionFilter.doFilterHttp(SessionFixationProtectionFilter.java:67) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.ui.ExceptionTranslationFilter.doFilterHttp(ExceptionTranslationFilter.java:101) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter.doFilterHttp(SecurityContextHolderAwareRequestFilter.java:91) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.ui.AbstractProcessingFilter.doFilterHttp(AbstractProcessingFilter.java:277) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.ui.logout.LogoutFilter.doFilterHttp(LogoutFilter.java:89) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.context.HttpSessionContextIntegrationFilter.doFilterHttp(HttpSessionContextIntegrationFilter.java:235) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.securechannel.ChannelProcessingFilter.doFilterHttp(ChannelProcessingFilter.java:116) at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:390) at org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:175) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at ourcode.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:35) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24502397.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
On Jul 14, 2009, at 1:50 PM, Kory Markevich wrote: djencks wrote: What creates the new non-working thread? In geronimo we generally don't assume anything about the relationship between threads so if you want the new thread to get a particular security context you'll have to install it youself. Just to clarify, we aren't trying to create new threads. I just assumed that geronimo/tomcat was doing it to service multiple connections or something. Looking at the bottom of the stack dump for the exception, it looks like a tomcat worker thread: at org .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286) at org .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 845) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint $Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) The snipped part is all the valve, filter, controller and openejb stuff, pretty standard. Oh, and I forgot to mention in the original post that we're using 2.1.4. good choice :-) OK, this is weird, I've never seen a bug in this area. What kind of authentication does the web app use? Can you show the entire stack trace to the ejb security exception? thanks david jencks -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24487458.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
djencks wrote: > What creates the new non-working thread? In geronimo we generally > don't assume anything about the relationship between threads so if you > want the new thread to get a particular security context you'll have > to install it youself. Just to clarify, we aren't trying to create new threads. I just assumed that geronimo/tomcat was doing it to service multiple connections or something. Looking at the bottom of the stack dump for the exception, it looks like a tomcat worker thread: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) The snipped part is all the valve, filter, controller and openejb stuff, pretty standard. Oh, and I forgot to mention in the original post that we're using 2.1.4. -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24487458.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB & Web App losing Subject
On Jul 14, 2009, at 11:39 AM, Kory Markevich wrote:
A web app (built with Spring & GWT) we're building is currently
having issues
with security and EJBs. Some calls made by the app to EJBs are
throwing
"Unauthorized Access by Principal Denied" exceptions. Investigating
this it
seems that whenever a new thread in geronimo is started to service
the call
the auth credentials aren't being copied. For example,
ContextManager.login
is called in thread "http-0.0.0.0-8443-1", and subsequent EJB calls
work
correctly. Some time later a new thread "http-0.0.0.0-8443-2" is
created
and the EJB call takes place in it. Geronimo notices that there
isn't a
subject and installs the default subject (using
ContextManager.setCallers),
which of course doesn't have the required principals.
I'm assuming the thread spawning is normal though I don't know
that. We do
have another web app, using Spring but not GWT, that is working
correctly.
Both web apps use custom LoginModules, though not the same ones.
Could this
be caused by the web app? Where could I look to get more information?
What creates the new non-working thread? In geronimo we generally
don't assume anything about the relationship between threads so if you
want the new thread to get a particular security context you'll have
to install it youself.
Something like
final Subject threadSubject = ContextManager.getCurrentCaller();
Runable work = new Runable() {
public void run() {
ContextManager.setCallers(threadSubject, threadSubject);
...//do work
//thread expires
};
}
I probably have all the details wrong but this idea should work.
If you use a thread from a thread pool (which I'd recommend) you
should uninstall the security context when you are done with the thread.
hope this helps
david jencks
--
View this message in context:
http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24485373.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
EJB & Web App losing Subject
A web app (built with Spring & GWT) we're building is currently having issues with security and EJBs. Some calls made by the app to EJBs are throwing "Unauthorized Access by Principal Denied" exceptions. Investigating this it seems that whenever a new thread in geronimo is started to service the call the auth credentials aren't being copied. For example, ContextManager.login is called in thread "http-0.0.0.0-8443-1", and subsequent EJB calls work correctly. Some time later a new thread "http-0.0.0.0-8443-2" is created and the EJB call takes place in it. Geronimo notices that there isn't a subject and installs the default subject (using ContextManager.setCallers), which of course doesn't have the required principals. I'm assuming the thread spawning is normal though I don't know that. We do have another web app, using Spring but not GWT, that is working correctly. Both web apps use custom LoginModules, though not the same ones. Could this be caused by the web app? Where could I look to get more information? -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24485373.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
