IMHO this is not a security issue at first. If one divide the "security" into authenfication, authorization and auditing, then we have a iddentification issue here. The same problem will at least arise if one tries to establish something what is called today AOP: the 'turn-one-key-opens-all-doors' syndrome.
I would vote for establishing an identity interceptor as the first in the message flow. He is marking the call with the identity of the caller. So one is able, even in threadlocal, to identifying who is in. absolutely wrong?? bax > -----Ursprüngliche Nachricht----- > Von: Alan D. Cabrera [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 26. Mai 2004 02:55 > An: [EMAIL PROTECTED] > Betreff: RE: Changes to OpenEJB interceptor stack > > > Similar thing to what you're saying. I'm just giving a heads up. > > I guess we should share as much threadlocal as we can. I > think that the security interceptors will have to be left out. > > > Alan > > > -----Original Message----- > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, May 25, 2004 8:54 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Changes to OpenEJB interceptor stack > > > > On Tue, 25 May 2004 21:45:37 -0400, Alan D. Cabrera > <[EMAIL PROTECTED]> > > wrote: > > > > > > This may not work for my security interceptors since the > threadlocal > > > context may be set by something external to OpenEJB. > > > > If that is the case, then what do you propose we do instead. > > > > -dain >
