Hello *, in our use case, quite a few EJB methods (mostly of stateless session beans) need to communicate with many EJBs on different servers (some on the same server, but then mostly still as different user). Therefore, we want to stick the authentication info to the EJBs, making code like this possible: EjbOfPartner ejbOfPartner1 = EjbOfPartnerUtil.getHome(getInitCtxProps(partner1)).create(); | EjbOfPartner ejbOfPartner2 = EjbOfPartnerUtil.getHome(getInitCtxProps(partner2)).create(); | EjbOfPartner ejbOfPartner3 = EjbOfPartnerUtil.getHome(getInitCtxProps(partner3)).create(); | | ejbOfPartner1.doSomeBusiness(...); | Result result = ejbOfPartner2.doSomethingElse(...); | ejbOfPartner1.doSomethingWithResult(result); | ejbOfPartner3.doWhatever(...); | // ... and so on ... Without this feature, the user of our framework would need to track manually for which EJB handle he needs to be authenticated how; and then login, logout, login, etc. all the time. This makes things extremely error-prone and some code even impossible (e.g. where EJB handles are provided by a factory). Already a while ago, I tried to use org.jboss.security.jndi.LoginInitialContextFactory. But after analysing the source-code ('cause it didn't work), I saw that it doesn't really stick the user data to the EJB handle, but instead only performs a login. Hence, in my above example, the calls to ejbOfPartner1 and 2 fail (if the EJBs are on a remote server) or communicate with partner3 instead of 1/2 (if the EJBs are on the same server). This is, because the user required for partner3 is logged in globally (for all EJB handles) after the last EjbOfPartnerUtil.getHome(...).create(). Therefore, I hacked a workaround consisting of an InitialContextFactory, a Context and an Interceptor. This seemed to work fine for JBoss 3.2.x (not sure anymore, but I think it was 3.2.5). Unfortunately, I didn't work on the code requiring this feature for quite a while and didn't recognize that it broke some time ago. You can find details for my workaround here, btw.: * source * wiki page * issue tracking Now, I need to get it running again, and I was already extremely happy when I saw the new org.jboss.security.jndi.JndiLoginInitialContextFactory which seemed (according to the wiki page) to do exactly what I need. Unfortunately, however, it doesn't :-( and actually behaves in the same wrong way as my workaround does. I tried to set the flags jnp.restoreLoginIdentity and jnp.multi-threaded, but it didn't help. What am I doing wrong? Doesn't JndiLoginInitialContextFactory support what I need? Well, I thought I'll take a look at my workaround again and I saw that the org.jboss.invocation.InvocationContext which I use to pass my auth info, is somehow reused for different EJB handles pointing to different partners (maybe there's a new caching feature?). This leads to wrong authentications :-( Maybe I should add, that multiple partners can be hosted on the same machine and thus connections to different partners can sometimes go to the same server (even locally, i.e. loopback). Is there an easy way to do what I want? Maybe using JndiLoginInitialContextFactory correctly (in case I'm doing this wrong) or using another InitialContextFactory (which one?)... any ideas? If there's no such solution, can you give me hints on how I can pass the information from my own InitialContextFactory to an interceptor? Or is there a totally different and better way to achieve this? Maybe EJB3? Thanks a lot in advance! Best regards, Marco :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068930#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...