RE: Summing up on visibility(?)

> > In order to perform a security function, wouldn't it have to
> > "understand"
> > more than XML and SOAP syntax, though?  How would it arrive at that
> > (higher) level of understanding?
>
> Beats me, I'm not in the firewall business. Those who are in the firewall
> business seem to be frantically building products that claim to do useful
> things by parsing the XML, understanding the SOAP processing model, and
> letting the customer define security rules based on this stuff. If you're
> right, I guess they'll fail.  We shall see.
>
> But once again, I'm not clear on what you're asking the WSA WG to
> do.  Mark
> raises the "visibility" issue periodically as a principle that should
> somehow be respected, and it appears that most of us don't get the point.
> To the limited extent that I understand what you're getting at here, it
> seems to me that XML supports "visibility" because 3rd party tools,
> intermediaries, etc. can extract useful information for routing, cacheing,
> security, etc. without truly "understanding" what's going on.  That's the
> same kind of advance that HTTP offered over raw IP messages as
> far as these
> things were concerned.  Time marches on.

That's precisely how those firewalls worked.

Previously you just had to look at the first packet in order to determine
what operation is being performed (from the GET/POST URL). Now you have to
look at the entire message so you can extract the data from the SOAP
envelope. But there's only one SOAP envelope, so it's easy for the firewall
people to do that only once. Actually they already do that. So that part of
the visibility issue is solved.

A different question is how you deal with security?

With SOAP, given headers and body parts, you can sign/encrypt individual
parts of the document. So the firewall/cache/router
can look at the other headers and make decisions even if it can't look into
the actual data values. With HTTP you have to sign/encrypt the entire
document, or use a protocol that makes the message opaque (SSL) which
presents a problem for the firewall.

As a firewall/router/bandwidth-management vendor, I would be working extra
hours to support SOAP because I could add all these value services. It will
cost me some time, but that's not something I can do with HTTP since there's
no visibility into that extra information.

arkin

Received on Friday, 10 January 2003 00:05:28 UTC