<<Security is among the top issues for many IT departments, but with SOA security takes on a whole new dimension. While the mixing and matching of services can open up a rich set of possibilities for business processes, it can also open up a Pandora's box if the underlying services do not enforce a stringent enough policy to deal with the many interactions they can possibly take part in.
On another front, with platform-independent access to data comes openness, but with openness also comes vulnerability. The same channel used by your business partners can easily be employed by rogue users if the necessary provisions are not made. Security can be tackled at various levels on the SOA stack, namely through WS-*/SOAP specifications, by provisions offered in XML standards or at the network level. If you have an existing application operating in the context of a SOA, tightening network-level security is perhaps the most straightforward and non-invasive manner to heighten security, since its does not require modification to the underlying application. Many of the SOA network security strategies are along the same lines as many Web-based applications, which can include creating a VPN (virtual private network) for exclusive communication between client and server, making use of digital certificates to establish SSL(secure socket layer) protection or HTTPS, or deploying firewall infrastructure in either hardware or software mode to detect suspicious requests coming into a SOA. Network security, or transport security as it is often called, can thwart many attacks, but it does not preclude someone sniffing or intercepting the data which forms part of an application. To this end, many specifications built around XML can be used to protect the actual payload used by applications. XML Encryption and XML Signature are two standards developed by the W3C, both of which can be used to bring added security to XML-based data. The former specification is used to transform raw XML data by means of a cipher in order for it to be transported in an obfuscated manner between requester and responder. Since the cipher is intended to be kept secret from any third parties, this guarantees that even if data interception occurs, the information will be extremely difficult to read since the cipher alters the original content. XML signature, on the other hand, can be used to incorporate tampering detection of XML documents. By using an XML signature, a service provider can offer any service consumer -- or vice versa -- an unequivocal means of checking if the XML payload has been altered in any way or form from its original state. You should be aware that both XML encryption and XML signature are applicable to any XML type document. This is important to realize because not only can they be used to lock down the payload exchanged between service requests, but they can also be used for such things as WSDL contracts, which are also XML-based and form an important part of an SOA.>> You can read this tutorial in full at: <http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1179721,00.html?track=NL-450&ad=548664> Gervas Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
