Monday, December 09, 2002

What should a Web Services Security product look like We at Vordel are proud to announce VordelSecure 2.0, the result of a lot of hard work.  There is nothing like building a product, influenced by knowledgable and demanding early adopters, to focus the mind on what a Web Services security product should look like. I've pasted the announcement press release below. First, though, here are some of the guiding principles behind our product. "XML Firewalling" is important, but not enough. "XML Firewalling" is an attractive category name for XML security products, but it's only a subset of the functionality that is required. I've discussed what XML firewalling is in this "Vordel View" piece. An XML firewall should act like a conventional firewall, except at the XML/SOAP layer. That means that it should filter XML traffic based on the target of the data (i.e. the Web Service) and the appropriateness of the data for that target (format of the data, content of the data, integrity of the data). VordelSecure 2.0 implements XML Firewalling by allowing the administrator to assign content-filtering rules to individual Web Services. Web Services are identified using URI, SOAP-Action, and method name - analogous to how a conventional firewall differentiates services based on TCP port. For each Web Service, VordelSecure is configurable to filter based on format (conformance to an XML Schema), content (using XPath to look into the data), and integrity (enforcing XML Signature). That seems like a lot of security right there; so why is XML Firewalling not enough? The reason is that early adopters of cross-firewall Web Services are primarily deploying these services to talk to their partners, not to talk to the entire world. They primarily want a Web Services security product to limit access to the Web Service to only their partners. This is more like a VPN/firewall combination, not just a firewall. In the announcement below, we stress that we perform "XML firewalling and XML access control". How is this Access Control performed? On to the next bullet point... It is important to be flexible about security technology, without being flexible about security. Access Control for Web Services, just like Web Services themselves, cannot mandate any particular technology at the Web Service consumer. There are two general ways in VordelSecure to enforce access control for Web Services. Option one, if HTTP is used for the transport, is to use the client-side certificate presented as part of a mutual SSL session. Option two, if HTTP is not the transport, or if one-way SSL is used, is to perform access control based on security tokens in the incoming SOAP message. WS-Security explains how security tokens, such as X.509 digital certificates, may be packaged into a SOAP message. The WS-Security Profile for XML-based Tokens explains how a SAML assertion may be packaged into a SOAP message. VordelSecure 2.0 allows an administrator to create a security policy to which gives their partners flexibility in terms of security policy. Remember, some organizations are deploying Web Services to partners who are much bigger than them, and they cannot say "we have a product which requires SAML assertions, so you must only send us SOAP messages containing SAML assertions".  So - from theory into practice - this means that VordelSecure can be configured to allow access to a Web Service for some consumers using client-side SSL, some other consumers sending X.509 certificates bound to SOAP messages using WS-Security, and other consumers using the "push" SAML model. Customers do not want to set up yet another silo of identity data Look at any deployment diagram of VordelSecure and you will not see a "user database", or a requirement for VordelSecure at both sides of the transaction. Companies already have identity information in stores accessed by LDAP, and most likely already have identity-based policy information stored in authorization tools. It's important to interface with these stores, rather than to force the customer to re-create them. On a related point, one way to talk to identity services is using XML. However, it is important to use pre-XML technologies also, because that is what is deployed in organizations now. So, in VordelSecure 2.0's datasheet you'll see older technologies such as OCSP and Certificate Revocation Lists, as well as newer technologies such as XKMS. Performance is key As an Intel portfolio company, Vordel has worked for over a year with Intel to optimize VordelSecure for speed. We recognize that XML security cannot be a bottleneck. Deploying a partner-integration solution for Web Services would be counter-productive if the provision of security slowed the system down, making it unworkable. We've refactored, profiled, and continually tested, in order to squeeze as much performance out of the product as we can. Distributed, not monolithic, security Here's a simple but effective metaphor - if you're securing a border, you don't set up one border post and require all traffic to pass through that single border post. Similary, adopters of cross-firewall Web Services require the ability to enforce Web Services at multiple entry (and exit) points in the organization. VordelSecure 2.0 splits between security enforcement (VS Enforcer) and security policy (VS Server). This means that the core decision-making component of the VordelSecure suite is not required to be situated in the DMZ. Only the security enforcement (VS Enforcer) is in the DMZ, and multiple VS Enforcer modules may talk to multiple VS Server installations in an n*m deployment. The release announcement: December 9, 2002, Boston, MA - Vordel, the Web services security company, today announced VordelSecure 2.0, the first enterprise-grade XML security suite to respond to the security needs of organizations that are taking advantage of XML for software integration. VordelSecure 2.0 provides organizations with a high performance, scalable security management solution to secure their XML communications. It provides both XML firewalling and XML access control, and does not rely on a monolithic architecture deployed at a single point. Instead, it may be distributed across all Web Services exposed by an organization, at multiple entry and exit points. Companies deploying Web Services are using VordelSecure to deliver highly secure and highly scalable security. British American Tobacco (BAT) is one company that has adopted Web Services technology as a key building block of its internal business process integration strategy. Kevin Poulter, Head of the Application Technology Group at BAT said, "BAT chose Web Services technologies such as SOAP and WSDL to streamline integration of our business systems. Security is a key component of our integration architecture and requires the capabilities provided by a specialist XML security product. To ensure the integrity of our architecture it is important for us to maintain a distinction between the security application infrastructure and the enterprise business systems. "VordelSecure distinguishes itself as implementing a comprehensive range of XML security technologies," Poulter concluded. "As Web services expose business processes to customers and partners, they will also become targets for a variety of malformed data and denial-of-service attacks", said Phil Schacter, VP and Director of Directory and Security Services at analyst firm, The Burton Group. "The application servers that host Web services applications require a level of protection that the current generation of network firewalls is unable to provide. This is one of the emerging roles for the new generation of Web services security products, such as VordelSecure 2.0," commented Schachter. Derek O'Carroll, CEO of Vordel, explained that VordelSecure is the result of more than three years of development and detailed customer interaction. "We are offering companies greater flexibility and choice in the way they deploy security for their XML communications," he said. "VordelSecure 2.0 offers companies a highly scalable security solution, reduced deployment times, and the ability to leverage their existing security and integration investments," continued O'Carroll. About VordelSecure 2.0 VordelSecure secures Web Services by filtering XML traffic based on both XML content and the identity of the sender. Content filtering is performed based on target, XML format, XML content, and XML integrity; using SOAP routing, XML Schema validation, XPath evaluation, and XML Signature. Identity-based security is implemented using SAML, WS-Security, and X.509 v3 digital certificates. The core component products of VordelSecure include: VS Server VS Server is a security server for XML-based traffic. Security policies are based on (a) XML data integrity, content, and format, and (b) identity, role, and entitlements of the sender. Security policies are configured using a GUI, and may be stored in any JDBC-compatible database. Reporting is performed using a highly flexible Web-based reporting tool. VS Enforcer VS Enforcer intercepts XML traffic at a HTTP server such as Apache or IIS, and communicates with VS-Server. Multiple lightweight Enforcer agents may be deployed on multiple SOAP endpoints as part of a single VordelSecure installation. VS API VS API is an API used to write a non-HTTP lightweight Enforcer application (e.g. to read XML from an MQ queue and interface with the VordelSecure security server). VS SOAP Browser VS SOAP Browser is a SOAP Client GUI tool, which allows an administrator of the VordelSecure suite to insert digitally signed security tokens into SOAP messages, in order to view VordelSecure Server security rules as they are enforced. Further detailed information on VordelSecure 2.0.