Harish Prabandham wrote:
> Hi,
>
> I do not understand the security implications of deserializing
> and serializing an java.ejb.Handle.
Well it seems that there is no agreed upon mechanism (lets say with RMI/IIOP)
to propagate the client's identity (except IIOP/SSL).
> The security information is typically sent along with the
> call. It is never associated with the remote object.
You are incorrect. For example, Sybase EAServer uses this technique to
implement authentication for CORBA 2.0 clients that don't implement any
of the standard CORBA security mechanisms (like IIOP/SSL).
> The security methods getCallerPrincipal() and isCallerInRole()
> are "call" specific - not object specific. Similarly role
> based authorization checks are done based on the who called
> the bean - not based who created the bean.
That's all fine and well, but if the only identity available is that
of the creator of the object reference, and the caller's identity is not
propagated over the wire, then you are left with two choices:
(1) Use the identity of the client who created the object reference.
(2) Use some anonymous identity.
I know which I would choose (#1). It of course means that clients should not
share object references, i.e. Handles should not be passed between clients
with different identities if you want this scheme to work.
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
