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]
