Dan -
But I would be able to turn off database authentication and just use the
propagation of the Principal, right?
(And that should be as efficient as the way I'm using it now.)
If so, it meets my purpose. :)
- Keith
-----Original Message-----
From: Dan OConnor <[EMAIL PROTECTED]>
To: jBoss <[EMAIL PROTECTED]>
Date: Thursday, November 09, 2000 8:58 PM
Subject: Re: [jBoss-User] problem with ctx.getCallerPrincipal()
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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
