|
I think that the current debate re: SOAP with firewalls is slightly hysterical, the spec allows for header interpretation so one may filter out certain services, regardless of port; just requires the firewall to be smart enough to do this. True the use of strict headers is up to the implementator, so 'commercial' services will do this.... if they want to be used.
The real problem is that firewalls are slowly moving from allowing/disallowing physical transport of tcp/ip packets ( from source to target and vice versa ) to application level enforcement of ACL's. Is this what a firewall is supposed to do ? probably no.
How does the firewall 'know' which bits to let through, if its not based on simple rules with ports being the finest grain. One could imagine the firewall being fed ACL information from the OS... in what format ? hmmmmmm
what performance impact will occur if firewalls start taking over sophisticated filtering of SOAP calls ( over any port, or through port 80 ). probably will slow things down....
in general, its not the SOAP spec, or any RPC spec that drills through a firewall to perform some task that causes a security problem; its the confusion of 'what' a firewall should do.
personally, i see a firewall as the point where physical security and auditing gets performed
in the perfect world;
a) all tcp/ip traffic would be encrypted ( SSL ),
b) firewall rules are applied as per usual, based upon allowing/non-allowing of source IP to target IP cross referenced by ports
c) all xml requests and their payload( in the case of SOAP or any other XML being POST/GET ) would be encrypted and signed.
d) there is probably a need for a generic web services daemon, using a standard port ( why not 81 ), but does this work for clients, definately not;
e) so the problem is that a collection of web services or a single web service needs to be 'packaged' up for consumption by a client and this is where the problem lies. this package needs to navigate through a firewall yet be authorised, validated, unencrypted and result to be encrypted etc.... will the firewall of the future perform this; hmmmm
the only way i see this being done is through reusing/replicating the existing SSL usage of certificates for valid web services; a client must 'trust' this certificate to allow it to perform local processing, for 'trust' to occur a valid 3rd party must verify the certificate.
and once again, the seed for encryption or signing 'within' the xml could come from this certificate.
with this, one could slightly augment a firewall to set rules for certificates; which means when it comes to automatic aggregation of web services, essentially when a service is used, independent of humans, the firewall can make decisions based upon certificate validity, etc...
just a thought, jim fuller
|
Previous Message
