Perform SLSB invocation inside a jndi context [SPR-1507]

[spring-projects-issues]

Xavier Dury opened SPR-1507 and commented

Hi,

in my company, we're using remote SLSB's to provide common functionality for a lot of applications. The problem is that those SLSB's are secured and only some pairs of principal/credentials may use those services (they call them 'technical users', this practice is somewhat debatable).

Actually spring performs the home lookup inside a correctly set jndi context but the invocations aren't, resulting in a SecurityException being thrown.

This has been spotted in several posts:

http://forum.springframework.org/archive/index.php/t-16213.html
http://forum.springframework.org/archive/index.php/t-10955.html
http://forum.springframework.org/archive/index.php/t-14285.html

So I've found a workaround for this: performing the invocation inside a jndicallback (inside the same jndi environment that was used at lookup time). I'm proposing my ExtendedRemoteStatelessSessionProxyFactoryBean as an example on how to do this but maybe this functionaly should be placed somewhere else (earlier) in the class hierarchy (like SimpleRemoteSlsbInvokerInterceptor so it could be made available for more subclasses).

What do you think?

Regards,
Xavier

---

Attachments:

• ExtendedRemoteStatelessSessionProxyFactoryBean.java (4.01 kB)

Issue Links:

• DefaultMessageListenerContainer failover to work with Weblogic JMS and security credentials [SPR-4720] #9397 DefaultMessageListenerContainer failover to work with Weblogic JMS and security credentials

2 votes, 1 watchers

[spring-projects-issues]

Adrian Murray commented

I have just encountered the same problem - when attempting to authenticate 2 SLSBs against different weblogic servers, the prinicapal/credentials from SSLB1 get picked up on invocations from SSLB2. The workaround I implemented was to use JAAS authentication instead of JNDI authentication as recommended by BEA:

http://edocs.bea.com/wls/docs81/jndi/jndi.html#478033

I overrode the doInvoke() method to perform the invocation as a privileged action

object = Security.runAs(mySubject, new PrivilegedEJBAction(invocation));

[spring-projects-issues]

Andreas Senft commented

Recently I also stumbled upon this issue. Is there a chance of fixing this?
The proposed workarounds (see also http://forum.springframework.org/showthread.php?t=20481) shouldn't be hard to integrate.

[spring-projects-issues]

Dennis Kieselhorst commented

I spent one hour to find it :-(

Tried this workaround, works for me too:
http://forum.springframework.org/showthread.php?t=30148

[spring-projects-issues]

Dennis Kieselhorst commented

Verified the workaround with the modified JndiTemplate...it works for my Unittest but not in a clustered environment.

I appreciate that a fix is targeted for 2.5.5 now.

[spring-projects-issues]

Juergen Hoeller commented

Dennis, which workarounds exactly work for you and which don't? Would be great if you could list the exact patches that you applied and what the respective effects were for you.

I'm afraid I can't promise a fix for 2.5.5 but we're trying... also with respect to the related #9397 issue. Otherwise it might have to wait for 2.5.6.

WebLogic's thread-bound authentication through JNDI environment setup is really weird. FWIW, there's also nothing in the J2EE spec that requires JNDI reinitialization for every accessing thread...

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I assume what always works is to execute the SLSB create/invoke/remove sequence within a JndiCallback executed by the standard JndiTemplate.

What works in a unit test only is to keep the existing invocation code as-is but to make JndiTemplate use a shared InitialContext that it never closes? Right?

The shared InitialContext solution only associates the context with the thread that originally performed the first lookup. That would be the same thread in a unit test environment, but not in a production J2EE environment where other threads come in performing the actual SLSB invocations.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

As for the JndiCallback solution: It should actually be sufficient to override "doInvoke" only there, since that encompasses "create" and "remove" already (at least in Spring 2.x). So executing "doInvoke" within one all-encompassing JndiCallback should result in equivalent behavior. Is this assumption correct?

Juergen

[spring-projects-issues]

Dennis Kieselhorst commented

Juergen you perfectly explained it. I also agree with your assumption concerning the JndiCallback solution. Do you still need a patch? I can perform some test with Xavier's ExtendedRemoteStatelessSessionProxyFactoryBean.

[spring-projects-issues]

Juergen Hoeller commented

I've addressed this in Spring 2.5.5 now, introducing an "exposeAccessContext" bean property on AbstractSlsbInvokerInterceptor and a corresponding "expose-access-context" attribute on jee:local-slsb and jee:remote-slsb. This will expose the JNDI environment context (as used for the lookup) for each method invocation on the EJB proxy.

I've also introduced the same flag on JndiObjectFactoryBean and jee:jndi-lookup, for WebLogic resource factories that have authorization requirements on their connection retrieval methods (e.g. JDBC DataSource, JMS ConnectionFactory).

Juergen

[spring-projects-issues]

Dennis Kieselhorst commented

Added Spring 2.5.5 today, exposeAccessContext works great. Thanks.