Hiya, So runPrivilegedActionAsSubject maintains the same thread. Using the thread EIP used new threads, and there was a warning on the Camel documentation page that new threads would cause issues for Spring transactions, so I avoided this route (although not thoroughly researched).
So for Inbound JMS, I don't believe the security context can get dirtied (from the perspective of listening to a JMS destination) because the same subject is used each time as soon as the thread gets started, and applies for the lifetime of the thread but I think I see where you're coming from in terms of thread re-use and sending to another foreign destination, and this could very well be a problem. The BEA/Oracle documentation recommended to wrap a privilegedAction around the code in the main method, so maybe not. I avoided wrapping the MessageConsumer#receive method because it seemed to go against the grain of what the security architecture was trying to achieve. The Outbound JMS is a bit uncouth... the privilegedAction gets set around *every* processor which is inefficient and will break if you're going to be sending to foreign destinations. In that case you might well copy/paste the interceptSendToEndpoint code and ensure that you wrap the process call in the runPrivilegedActionAsSubject (this is probably the ideal solution). I'm not really an expert in this, and the use-case you have involving multiple security realms introduces some issues... there's certainly an aspect of over-architecture here with respect to the security model. Cheers, David -- View this message in context: http://camel.465427.n5.nabble.com/Weblogic-JMS-Security-Issues-A-possible-resolution-tp5735108p5735179.html Sent from the Camel - Users mailing list archive at Nabble.com.
