Bax, You seem to have a good grasp of the issues and have described how our interceptor architecture currently works. The issue is the management of the security context for authorization and auditing. I am merely stating that I do not think that the security context can be lumped together with the other contexts in a single thread local.
Regards, Alan > -----Original Message----- > From: hbaxmann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 26, 2004 1:59 AM > To: [EMAIL PROTECTED] > Subject: AW: Changes to OpenEJB interceptor stack > > 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 > >
