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
