>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.
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.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
