for me, sure, because my application has one user credentials per vm. But this is probably not the majority of usecases. Ideally, one initialContext should be stuck to one credential
Sami 2008/8/8 Dain Sundstrom <[EMAIL PROTECTED]> > Would a single login for the whole vm (global static variable) work for > you? > > -dain > > > On Aug 8, 2008, at 2:47 AM, Sami Jaber wrote: > > Maybe this discussion would be more appropriate to the dev list. >> btw I want to thank all the members of this small and smart community, I >> didn't know this appserver before and I'm very surprised by how it has >> been >> kept simple in term of design & source code. >> The problem of thread scoping and SecurityAssociation has been a complex >> design debate for a while. There is no elegant way to resolve this. If we >> take the JBoss way for example, they use (as Openejb) >> InheritableThreadLocal >> : >> >> http://www.cenqua.com/clover/eg/jboss/report/org/jboss/security/SecurityAssociation.html >> Their SecurityAssociation looks like very similar to yours and they face >> the >> same problem (randomly, I get a NPE with JBoss, it is worst). >> But in term of requirement, if you ask me what I need : >> - InitialContext should be bound to 1 Security credentials (multiple >> credendials should use different context) >> - InitialContext has not to be Thread Safe according to Sun specs ( >> http://java.sun.com/products/jndi/tutorial/beyond/misc/sync.html) >> - The lookup context should use exactly the same context that the one it >> has >> been initially created with (this is not the case if we loose the TL) >> Ideally, in remote mode, all work perfectly (compare to the intraVM way), >> if >> we can use the same stack, it would be fine. >> >> I have also to investigate on my own because if I can ensure that new >> InitialContext() is done on the root thread (the main thread), >> InheritableThreadLocal should do the job.... >> I'm certainly not very helpful with this response but I haven't >> sufficiently >> hacking up OpenEJB to be relevant (I use it since tree days), just a >> question of time... >> >> Sami >> >> >> 2008/8/8 David Blevins <[EMAIL PROTECTED]> >> >> We can certainly hack up something in this regard. >>> >>> Quick question, what kind of security tracking would be good for you? >>> I.e. >>> are we talking concurrent users or one user at a time? >>> >>> We've got some code in the openejb-client package that's pretty useful >>> for >>> switching to different modes of tracking the user and I was just thinking >>> just the other day that it wouldn't be a bad idea to port it to the >>> "server >>> side" as well for embedded scenarios. >>> >>> Also, I assume this is sort of wrapped up in the other two security >>> related >>> posts. If not, let me now if there's something more specific I should be >>> looking at there. >>> >>> -David >>> >>> >>> On Aug 7, 2008, at 10:24 AM, Sami Jaber wrote: >>> >>> Hello all (once more :-)), >>> >>>> >>>> After the deployments.ear property and the custom ObjectInputStream, I >>>> have >>>> found another issue which is IMHO more annoying, maybe a structural >>>> design >>>> problem that David will resolve for sure ;-). >>>> I have a pretty big Swing Application that relies on OpenEJB over a >>>> remote >>>> mode (integration platform) and local mode (dev platform). >>>> After digging into the openejb source code (I find them really well >>>> coded >>>> btw), it appear that over LocalInitialContextFactory, the user context >>>> (security, tx, ...) is hold on the ThreadLocal. Not sure but it seems to >>>> be >>>> done in the ClientSecurity.java class thru this code : >>>> >>>> public static void login(String username, String password, boolean >>>> threadScoped) throws FailedLoginException { >>>> Object clientIdentity = directAuthentication(username, password, >>>> server); >>>> if (threadScoped) { >>>> threadClientIdentity.set(clientIdentity); >>>> } else { >>>> staticClientIdentity = clientIdentity; >>>> } >>>> identityResolver = new SimpleIdentityResolver(); >>>> } >>>> >>>> The problem is that with Swing Application (or any multi-threaded >>>> front-end), you cannot assume that the thread that initiates the new >>>> InitialContext() is the one that will be used to lookup. In my case I >>>> have >>>> implemented (as every smart boy ;-)) a smart proxy pattern which consist >>>> in >>>> keeping the context in a singleton and reusing it between calls. The >>>> issue >>>> is that the lookup is made inside a Swing Action, the Event Thread >>>> Dispatcher raises a new Thread and all credential information are lost. >>>> That's why in my previous message, I told you that I get randomly >>>> "guest" >>>> as >>>> the getCallerPrincipal(). >>>> >>>> The fix would have been to instantiate a new InitialContext for every >>>> lookup, but not only it kills the performance but you get also an error >>>> message saying that you cannot assign twice the ThreadLocal. >>>> >>>> The last solution that works for me is to write that code for each >>>> lookup, >>>> this is ugly but it does the job : >>>> >>>> public static void setInitialContext() >>>> { >>>> try >>>> { >>>> context = new InitialContext(env); >>>> } >>>> catch (Exception e) >>>> { >>>> // if TLS exists Ignore the exception, otherwise, it will set a new >>>> one in the current thread >>>> } >>>> } >>>> >>>> David ? >>>> >>>> Sami >>>> >>>> >>> >>> >
