Slashdot Mirror
XML Web Services & Security
Handy writes "Web Services (SOAP, .net, WSDL ? , UDDI ? ) create an even greater need for robust security. Exposed interfaces and fragmented administration coupled with a need for app-level security points to a greater need for a centralized managed security services model."
This was an interesting read and I'm sure it is good info for tech managers- maybe if we keep hammering at them they will get it, but if you write code and you realize that we are connecting systems deeper and deeper - security becomes more and more of an issue. That seems to be a bit of a no brainer.
And all this talk of the computer is the network, and the future of tech and all this stuff - security is the linch pin to making it viable.
I think stability runs a very close second- especially as more critical systems become a part of this big electronic gestalt everyone dreams of- but if it is insecure, I know I wouldn't touch it w/a 10 ft. pole.
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Good luck for anyone actually trying to implement a secure soap based app, what with the moving targets of XML Encryption, different ways to use XML Signatures, the need to incorporate WS Routing (and possibly WS-Security). I know these specs are likely to change soon.
The drive to get business advantage from XML Web Services will cause turbulent times for IT managers. To successfully navigate these new issues, managers must change their mind set from "fragmented security systems focused on using network perimeter to shield closed business systems" to "consistent managed security systems focused on managing application level security for inherently distributed business systems".
Hmm... I know of a manager (very higher up), when asked about security implications of some assumptions in the design of a product (for web services), very confidently responsed, "They [customers] can always configure their firewall". *That* was the solution!
S
I really don't know (flame gently if I'm being ignorant), but I'm hoping someone can explain this simply.
If https is secure... and xml/soap is http-based... what's the giant technical leap preventing https transmission of soap/xml packets?
Also, if you're doing business with say, a vendor of yours, what's stopping the both of you from encrypting the body of the soap messages on both sides by means of a PGP key or something?
I'm just curious as to why the issue seems to be reasonably solved with http web traffic, but isn't with SOAP...
The point of doing web services in XML across HTTP is that it is easy and can use established technologies. If you don't want anyone intercepting the message (channel-based security), that is what SSL is for and works trivially with any web server and client, and is built into Java.
Once you have a secure pipe, it doesn't take a genius to solve the additional security needs of 95% of the applications. Add a password here. Add a signature or message digest there. Do a calling card pattern. Most of what certain vendors are screaming for is huge overkill to highlight their own products that they would like to have people using instead of what is here today and works well.
These are the same people that kept RSA under restrictive patent for so many years. Just say no.
The article by Rich DeMillo (CNet news.com May 15, 2002) is much better. He gets to the underlying issue that we are patching up problems as they arise rather than paying any attention to understanding what we are really trying to achieve. In particular he says "The headlong rush to Web services is going to make things worse."
DeMillo has been around long enough to know what he is talking about, but I expect his wisdom to fall on deaf ears in today's instant gratification culture.