NAKAMURA, Hiroshi" <nahi / keynauts.com> wrote:
>
>Hi Ben,
>
> > From: Ben Tilly [mailto:ben_tilly / hotmail.com]
> > Sent: Sunday, December 10, 2000 1:02 AM
>
> > > > dRuby really has not much to do with SOAP.  dRuby is a
> > >
> > >Agreed.
> > >
> > >I who implemented SOAP4R and Seki-san who implemented DRb
> > >talked about co-working of SOAP and dRuby.  We thought below
> > >possibilities.
> > >
> > >- dRuby over SOAP
> > >- SOAP over dRuby
> > >- dRuby/SOAP bridge
> > ^^^^^^^^^^^^^^^^^^^^^
> >
> > >- SOAP as a RPC part of dRuby
> >
> > The bridge is the only one that could make sense to me.
>
>Hmm.  I have to consider it again.  Do you think a bridge
>like this?
>   Ruby - dRuby/SOAP - Perl, Java, C++, and so on
>In this case, do we support MBR(Marshaling By Reference)
>which dRuby supports but SOAP does not supports originally
>(we can extend using SOAP Header).  Reference of Ruby object
>passed from dRuby to other program which is written in other
>language like Perl, Java, C++, and so on won't work well...
>at least it won't be "quick and easy object-oriented
>programming".
>
>MBV(Marshaling By Value) should be supported by the bridge
>and could be useful I think.  When you write a Ruby
>application and want to export the method which is stateless
>as a service to the Internet, dRuby and dRuby/SOAP bridge
>would help you.

Well I don't like SOAP, so I suggest doing the least you
can while claiming you support it, then wait to find out
if people really want more. :-)

[...]
> > I think that Bruce Schneier is absolutely correct that by
> > building an internet prototol with no security model which
> > is hard to filter, SOAP will be responsible for a new host
> > of security holes.
> >
> >   http://www.counterpane.com/crypto-gram-0006.html#SOAP
>
>Agreed.  DCOM over HTTP is required but not adopted much.
>SOAP and XML-RPC is to be the next candidate but we do
>care security vulnerabilities as he said.  Transport
>seurity SSL might help for some purpose.  Messaging
>security XML-Signature might help for another purpose.

Security here means two different things.  One issue is
proper authentication, the other is privacy of data.  My
inclination is to worry about getting authentication right
and then letting people who care about encrypted data do
that with ssl, ssh, or some other tunnelling mechanism.

[...]
> > Basically it works like this.  Access is provided through
> > objects.  You can only name resources through objects.  If
> > you can name a resource then you must have had permission
> > to access that.  If you cannot name it, then you have no
> > business knowing that it exists.
> >
> > Contrast to the usual authentication based on (purported)
> > id.  On a Unix system if any program anywhere that runs as
> > root gets compromised, then the whole system is at the mercy
> > of the person who just broke in.  On a capability system
> > that program does not run "as" anyone, it just had the
> > necessary capabilities to do what it needed to do.  So the
> > compromise is limited in scope.
>
>Thank you for explanation.  dRuby now uses ACL which
>Capability system negates (IIRC; Seki-san?).  Capability
>system or its idea seems to be helpful for building
>Application server using dRuby.  Can dRuby itself support
>this idea?

I don't know the structure of dRuby, but probably.

It isn't hard to emulate the structure of an ACL system
with a capability system.  Have an initial login that is
mediated through an ACL.  Have it return an object
through which all further access is mediated.  That
object carries user information.  However it may then
return objects which themselves authenticate directly.

For instance you log into a database and get back a
database handle.  Then you send a query through the
handle, the database checks user permission, runs the
query and then returns another handle through which you
get results.  Then you ask the query handle many times
for results.

The system administrator sees an ACL system.  But the
majority of access is not authenticated that way.
Most of the traffic, if compromised, would give you
only limited access to transient parts of the system.

> > >// NaHi
> > >// Sorry for my poor English.
> >
> > Sorry for not speaking Japanese!  (There is no need when
> > doing us a favour in speaking our language to be apologetic
> > for not being perfect!)
>
>Doumo arigatou gozaimasu.  Many thanks.
>
:-)

Cheers,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com