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]
