Stupid question

Post #44,495 by ben_tilly 7/4/02 9:20:16 PM Reply	Stupid question What are they doing about the kind of common problems that resulted in businesses deciding that they needed firewalls in the first place? Ignore the issue now, then buy third-party products later that claim to make them safe? Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #44,515 by dmarker2 7/5/02 3:52:07 AM Reply	Re: A sincere question is rarely stupid. An answer can be Re the Q - yup security is a major component of XML and various forms of security either have been or are being proposed for SOAP messages. An <element></element> in XML can have its contents encrypted and the key can be pointed to or embedded in the XML. Digital signatures are supported in XML for non-repudiation. An entire XML message including element tags, can be encrypted but there are obvious reasons why that can defeat much of the value of XML and its tags. a) If the tags are common knowledge then encrypting them assist crackers in decrypting the element data, b) one of the great benefits of XML is being able to search tags for sepcific content. Once they get encrypted such searching gets killed. Encrypting element data is perfectly adequate - the mechanism has been defined in XML standards. As for virus issues. They shouldn't be part of XML & Web Services unless XML were to contain features that allow for in-line execution of portions of an XML document & thank god that bit of insanity (a la VB script) is not part of XML or Web Services. Cheers Doug
Post #44,526 by ben_tilly 7/5/02 7:13:28 AM Reply	This area seems to have a major confusion... between encryption (making sure that others cannot snoop on my communication) and security (making sure that my system is not readily abusible). The two are not particularly closely related, and definitely are not substitutes for each other. In this brave new world I think we will see a lot of having 2 parties open up a key exchange, and then proceed to communicate back and forth with no other thought to security. Sample mistakes will be that an undue amount of your internals will be available for perusal by the person you are perusing with, and the old web cart mistake of entering a negotiation and then trusting the prices that the client gives you. Cheers, Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #44,591 by dmarker2 7/6/02 4:26:54 AM Reply	Re: Web Services Servers might introduce challenges ... Web Services communicate between servers that listen on specific ports for SOAP messages. Web Servers are peripheral to Web Services. The servers can reside on the same type of box but a web servers servers web pages while a SOAP server recieves & forwards SOAP messages only. The SOAP listener sits on a nominated port (which is published in the WSDL definintion for the service being requested) on a tcp/ip connected server. The SOAP listener examines the request type in the SOAP message to determine which internal task (which will itself be listening on another port) and dipatches the request to the task on that other port. Web Services don't actually need web servers. They tend to though because web servers will typically provide the *.wsdl documents that provide the IDL info for accessing the service. A UDDI server is kind of a cross between a web server and a web services server. They will normally respond to both HTTP & SOAP requests. So the security issues you talk about relate to how to screw a web services server & this is a bit different from stuffing up a web server. Cheers Doug

Welcome to IWETHEY!