soap security

[Artemis]

Hello,

We are re-writing an application and are going to use soap as the communication protocol. Our product is installed on one or more machines in a network and communication is cross-process and/or cross machine. we are looking at iis or a lighter weight host such as cassini.

I have been tasked with securing the communication. I have read alot about how to secure soap and I believe the most secure paradigm is to have an xml/soap firewall and use ws-security extensions to support authentication, integrity, ect. If you disagree that this is the best way or is needed at all please post your comments.

My question is has anyone ever written an xml firewall. All I can find is 3rd party vendors which we can not use because of licensing.

A few questions would be:

I assume the firewall is a dll that is loaded by the web server? Is this correct?

Are there any info/samples on how to set this up in iis or other web servers?

Are there any docs/samples on the interfaces or methods the firewall application needs to support or how it would be coded?

[jwenting]

bleh. First define what you mean by "security" and go from there.

You seem to just be grasping at a lot of words and acronyms you don't really understand and expect a complete system to materialise out of thin air if you just use them all.

What's a "SOAP firewall" anyway? Are you going to block requests to the SOAP servers? If you do why have them at all?

Good authentication/authorisation in combination with SSL is normally more than enough.

[Artemis]

Actually I am well versed in security. I have been programming for over 20 years. what I am not sure about is how to secure a soap/web server.

What you are saying is you believe ssl (which would handle the encyption) along with authentication headers should be enough. I do not know enough yet to disagree but have a couple of questions...

what about denial of service attacks?
do you think a digest (hash key) would be needed for integrity?

what I meant by a soap firewall is basically a process (or dll loaded by the web server...not sure) that accepts all soap/xml requests and does the validation. if it passes the security measures then it lets it go to the server. otherwise it rejects it.

any thoughts/comments from anyone is truly appreciated.

[kuom]

I have implemented some SOAP/XML solutions at my last job, and we used a combination of layer 3+4 ilter (iptables), SSL, and authentication (login).

I am not sure what you mean by SOAP firewall and validation... do you mean something that resides on server side that will validate the XML, and perhaps check the WSDL to make sure the SOAP request is valid? If that's the case, can't you just do that in your SOAP server code? Or perhaps speed is of concern (hence you menteiond DLL), so you want this to be an extension of your web server? If that's the case, the only thing out there I know of is apache's mod_security that might provide similar functionality:

http://www.modsecurity.org/

In my project, we have dedicated web servers that were providing SOAP service and nothing else, and we know which are the clients that make the calls. So we built the list of IP addresses into the firewall rules (again, iptables) on the SOAP servers, so HTTPS is only exposed to these clients. Then, with the login/auth, we can have finer control over which user/process can call which SOAP services. Again, these were implemented in apache's configuration, some were done with the more complicated apache mod_rewrite for URL matching, and some were just a simple password protected path (say, /wsdl/ is protected with LDAP login).

I know this is very apache-centric, but that's what I worked with in the past. I hope this helps.

[jwenting]

his idea of a soap firewall doesn't exist.
A SOAP service can have one or more steps in which SOAP headers are processed though, and these can be used to do security checks.

DOS attacks won't be stopped by something running on your system as is. That will require a lot more work in the form of load balancers and generic firewalls that can detect such things.
Nothing to do with SOAP.

You might have 2 decades as a programmer, but you don't seem well versed in distributed application and network architecture.

We have a similar system to what kuom employs, with dedicated clustered SOAP servers talking to dedicated clustered application servers running EJBs.
The traffic volume is massive (realtime stock market data to thousands of customers in trading rooms all over the place).
Everything is protected by username/password login. You can't access any content on the SOAP servers without supplying valid credentials, and after that the application servers will again check those credentials to determine if you are allowed to call a particular service (and if so which constraints there are on the data you're allowed to get returned).

That's secure and stable enough for most purposes. If you want more security run the entire SOAP stack over HTTPS, providing additional 128 bit encryption for the (potentially already encrypted) SOAP messages.
For increased performance you can put gzip compression of the http stream on top of that (but beware that not all clients like that).

Prevention of DDOS attacks takes place well outside the scope of that SOAP stack or application server cluster. It's NOT the responsibility of the people building the SOAP stack, if the attack gets to them the battle has already been lost due to incompetence on the hands of your network engineers.

[Artemis]

i wish i could take credit for a web service firewall but it was not my idea and they do exist...a couple of commercial ones...

http://www.prismtechnologies.com/section-item.asp?sid6=&sid5=&sid4=106&sid3=135&sid2=14&sid=29&id=507

http://www.windowsitpro.com/Windows/Articles/ArticleID/39755/pg/2/2.html

Theres more by cisco now, roboo, ect...

My question about dos attacks was to talk to competent engineers who have dealt with this. I did not imply it was up to soap for the solution. Your implication that as a programmer you can not reduce or prevent dos attacks is just wrong. For example, RPC has built in methods to its proxies to prevent certain packets from getting through and bogging down the server. Not to say it is an end all soultion.

Here are some good articles on xml firewalls and security...although written a few years ago the concepts are still valid...

http://www.xml.com/pub/a/ws/2003/03/04/security.html
http://www.xml.com/pub/a/ws/2003/04/01/security.html
http://www.xml.com/pub/a/ws/2003/05/13/security.html?page=last
http://www.xml.com/pub/a/ws/2003/07/22/security.html

I think some developers are so confined in their own world they can't think outside of it. I'm surprised someone with your expertise in all aspects of development has not heard of xml\soap firewalls.

I have built numerous two-tier\three-tier networking applications. But then again I have the experience to listen when needed.

[Artemis]

by the way i do appreciate the info you have posted. I will build a soap server using https and use the security extensions for authentication. I will also add a hash key for integrity. I will test this under scalability requirements. Thanks.

[kuom]

Thanks for the links Artemis.

I did not know that there were XML firewalls out there myself, although I dealt with SOAP quite a bit in my last project. I guess just not too many people have the needs to use a dedicated hardware XML firewall, and with prices like these, I can see why.

I would imagine that what the XML firewall would be doing is a lot of pattern matching (just like most layer 7 firewalls), thus I would think it's quite resource intensive (depending on the algorithm). This probably has a place in large enterprise, and perhaps inter-enterprise SOAP communication. Unfortunately, I have not had experience in that area.

I, however, have implemented something close to that... it was more of a SOAP service "proxy". Basically, we have a machine that has access to all the other SOAP servers (which can be scattered around the network, or hiding behind some firewall or VPN), and every client out there makes connection to this machine, this machine (let's call it SOAP proxy) then turns around and decides which server to forward the SOAP request to. And this is where I have implmented some very basic authentication, quickly look at the requestor and the call it's trying to make, and check to make sure this requestor is allowed to make such call. This is far from the XML firewall you are talking about, but it worked well for my project, and I would imagine most people out there who don't have the budget for a hardware XML firewall.

Finally, if you were to start a project writing XML firewall, I'd be very interested and would glad to participate.

Thanks again for your links.

[brutus9448]

We decided to take a look at a product called JaxView from Managed Methods for our XML Security and Runtime governance needs. Its about 1/10 of other commercial XML firewalls and has all the features that you need. Its software based and you can download it from their web site.