>>That's good, but not good enough. To have any code that close to my
>>enterprise data (we are talking EJB, no?) and able (by definition of being
a
>>stub) to communicate with the outside world makes me cringe. There are
>>plenty of no-so-fun things rogue code could do that aren't (or can't) be
>>handled by the Java Security API while still posing as a working stub.
>>There's got to be much much more security than currently possible before I
>>allow someone else's code on my enterprise machine.
Great discussion now the mud slingers have quitened down.
How about that code being signed by a Certified Authority? How much more
SECURE and AUTHENTIC do you want? And besides you allow someone elses code
to run on your enterprise server all the time!! Wouldn't you trust BEA's CA
certificate? Or Inprise's? If it allowed you to run a protocol x times
faster than IIOP!!
Anyways, so if downloadable stub security is not an issue (and in my opinion
it's solved good enough already. No scaremongering!) then I think two well
thought out options have been discussed, and someone has already raised this
point. What is wrong with having IIOP as the mother of all protocols that
everyone must support, if they don't like downloadable stubs. Then all EJB's
talk to each other. Great. But you allow an EJB server to ask another server
if it trusts it's downloadable stub after the initial IIOP handshake. If it
does, then hey great. You can download my stub, and use my optimised
protocol, and you'll run faster with me. If not, oh well. I'll send you IIOP
instead.
Any thoughts?
-----Original Message-----
From: Jeff Martin [mailto:[EMAIL PROTECTED]]
Sent: 23 March 2000 21:49
To: [EMAIL PROTECTED]
Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
Rickard �berg wrote:
> Arkin wrote:
> > Your argument supports, in my opinion, why IIOP should
> > not be the only protocol. However, your argument assumes
> > an environment that is very favorable to RMI, not very
> > favorable to IIOP: who gets to publish the smart stubs
> > in a distributed system? why would company A allow
> > stubs coming from company B's server?
>
> Why should it not? It could easily use the Java Security
> API if you want to constrain what the stubs can perform
> (if it's security you're worried about).
That's good, but not good enough. To have any code that close to my
enterprise data (we are talking EJB, no?) and able (by definition of being a
stub) to communicate with the outside world makes me cringe. There are
plenty of no-so-fun things rogue code could do that aren't (or can't) be
handled by the Java Security API while still posing as a working stub.
There's got to be much much more security than currently possible before I
allow someone else's code on my enterprise machine.
Jeff
===========================================================================
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".
***
This e-mail is intended only for the addressee. This e-mail and any files transmitted
with it may contain confidential or privileged information. If you are not the named
addressee or the person responsible for delivering the message to the named addressee,
please contact [EMAIL PROTECTED]
This e-mail has been scanned by MIMEsweeper.
Visit the Prebon Yamane web site at http://www.prebon.com
***
===========================================================================
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".
