Harish Prabandham wrote:
>
> Hi,
>
> >
> > Well it seems that there is no agreed upon mechanism (lets say
> > with RMI/IIOP)
> > to propagate the client's identity (except IIOP/SSL).
> >
>
> Thats not true. There is no inter-operable way of propagating
> the client identity. But in IIOP, Service Context fields could
> be used to propagate the client identity in a container specific
> way. The Reference Implementation, uses this method to propagate
> the client identity from the client to the server.
Yes, I always wear an interoperability hat, so by "agreed upon" I did
mean "interoperable".
> > > 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).
> >
>
> I was not aware of that EAServer's behavior. But, I am sure that
> associating the "credentials" with the object is a not a good idea in
> the case of EJBs. Since the same object could be called by
> different clients. Moreover, EJB 1.1 spec. requires the caller
> principal information to be propagated.
It's very good if you want to allow CORBA 2.0 clients to access EJBs,
when no other mechanism is available. And note that EJB's design does
make this feasible, since session beans are intended for use by a single
client at a time, and for entity beans, multiple clients can be accessing
the same 'entity' through different object references.
Propagation of the 'principal' is insufficient, unless the principal is
accomodated by some sort of token generated by the server during
authentication. EJB 1.1 should not 'require' anything in this respect
until such time as there is an agreed-upon (interoperable) IIOP-based
authentication mechanism for EJB (other than IIOP/SSL).
> > 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.
>
> Since, there is a easy way of doing it in IIOP (see my other posting),
> you could use that instead of either of these options.
We prefer to provide an authentication mechanism that works with CORBA
2.0 clients that don't implement any of the CORBA security. So until
such time as there is a viable (standard) alternative that allows the
server to authenticate the client (instead of just 'trusting' that the
provided client principal is valid), it doesn't make sense to use the
GIOP Service Context.
________________________________________________________________________________
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".
