Hi Keith,
Actually, if you use my database security implementation (which
doesn't yet cache) you should see outrageous performance
degradation. Complain away. :-)
(A completely in-memory implementation should add very little
overhead.)
-Dan
On 9 Nov 00, at 18:34, Keith L. Musser wrote:
> Dan,
>
> I re-ran my timing comparisons - it seems the method call slows down by
> about 0.2 msec on my machine, which is only 10% of a call to a
> "do-nothing" method on a stateless session bean.
>
> So I can't complain about the overhead. I'm not sure why my initial
> timing measurements seemed to find a bigger overhead.
>
> - Keith
>
> -----Original Message-----
> From: Dan OConnor <[EMAIL PROTECTED]>
> To: jBoss <[EMAIL PROTECTED]>
> Date: Thursday, November 09, 2000 11:01 AM
> Subject: Re: [jBoss-User] problem with ctx.getCallerPrincipal()
>
>
> On 9 Nov 00, at 10:30, Keith L. Musser wrote:
>
> > >This on/off authentication (either you can get the reference, or you
> > >can't) would invalidate all EJB-specific security. You could neither
> > >use isCallerInRole nor getCallerPrincipal, nor could the container
> > >use the declarative access control in the deployment descriptor
> > >(because it would not know the identity of the caller).
> >
> > I'm saying that the Principal and Credentials are passed from the JNDI
> > lookup
> > into the Home interface. So it knows who's calling; and when the home
> > interface creates an EJBObject, it propagates the Principal /
> > Credentials.
>
> Hi Keith,
>
> I think I might see where we're missing each other. Our application
> server is stateless. In other words, it doesn't remember anything
> about the clients that are "out there." Even a stateful session bean
> is accessed by a "stateless" client that uses a private key. So any
> information you want to be associated with a call (such as principal
> and credential) needs to be propagated on the remote call.
>
> So in that sense, it doesn't matter whether you get the user
> information through JNDI or through a static or thread-local variable
> (our two methods). You still have all the same costs; it's just a
> matter of which API to use.
>
> >
> > So yes, the EJB security model still holds, but you can do the
> > authentication
> > only once and remember it.
> >
> >
> > From the client's perspective, they pass the Principal / Credentials
> to
> > the
> > JNDI system during the lookup. After that, they just keep track of
> the
> > references they receive.
> >
> > >Do you mean embed the user principal and credential in the
> > >serialized handle, and have the JNDI authentication happen
> > >automatically on deserialization? This could expose the principal
> > >and credential to discovery, and would limit the usefulness of the
> > >serialized handles.
> >
> > No - that's not what I had in mind. I was imagining something like
> > the thread-local Subject in JAAS. So when the deserialization occurs,
> > the principal / credentials should be accessible via JAAS, but
> > certainly not stored in the handle.
>
> We use a thread-local or static variable (your choice).
>
> -Dan
>
>
> >
> >
> >
> >
> >
> > --
> > --------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Problems?: [EMAIL PROTECTED]
> >
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
