Agree that a 2 tier architecture is best, where a server in the DMZ protects the internal webMethods servers. There’s advantages & disadvantages to using a webMethods server in the DMZ compared to an ordinary proxy server. Advantages include better processing of documents (since proxy servers don’t generally understand the XML documents being sent in), better resilience to buffer overrun attacks (since it’s all Java), and less familiarity to attackers (a “security through obscurity” defense). Disadvantages include less familiarity to the IT organizations that manage most DMZs.
So there’s not a right or wrong approach on this… like anything with security, it’s a matter of tradeoffs.
As for Reverse Invoke vs. webMethods acting as a Reverse Proxy, there are again pros & cons for each. For many organizations, it’s important not to have any inbound traffic through the internal firewall, and reverse invoke allows passing the data without initiating any inbound communications. Some organizations want to avoid having any authentication information stored in the DMZ, which is a perfect fit for Reverse Invoke, since it just passes the data to the internal server. Other organizations want to validate all user identities in the DMZ before allowing the traffic in, which can’t be done by Reverse Invoke.
I wouldn’t say there’s a universally recommended approach. It’s what’s better for your organization.
Jeremy Epstein
Director, Product Security
webMethods
#Integration-Server-and-ESB#webMethods-General#webMethods