Large Enterprises face a constant challenge in balancing technology costs with new business goals. Many enterprises have existing business processes bound up in applications that communicate using ‘legacy’ protocols such as FTP and MQ, which were really designed for behind the firewall operation in a trusted network. Given these constraints what’s the best way for a large Enterprise to extend these applications to external customers and partners without relying on an expensive re-engineering effort or concentrating risk in a single vendor? One option is to use a security gateway such as the Intel® Expressway Service Gateway to centralize security policy deployment, increase performance, reduce development costs, and simplify the architecture. In this post, I will describe a recent customer use case for a service gateway that highlights the value of this class of products. Secure Multi-Protocol Handling Recently, a large auto manufacturer chose Intel® Expressway as a key component of their extended enterprise, which included features and capabilities beyond the standard “trust” and “threat” capabilities around XML/SOAP, web services and SOA. This case really shows the value of a service gateway beyond a traditional SOAP proxy; Expressway was used to create a secure façade or veneer for external and internal applications using a mix of protocols, while at the same time providing a centralized point of control across the architecture. In this particular case, secure FTP (SFTP and FTPS), secure SOAP (WS-Security) and secure REST (HTTP/SSL) services were offered externally and Expressway was used to broker these invocations to various systems across network segments and firewalls over FTP, HTTP, HTTPS, and IBM Websphere MQ. In addition, the gateway performed X.509 authentication against the Enterprise’s LDAP directory for inbound SSL connections. Moreover, the service gateway was acting in a bi-directional manner, as a traditional reverse proxy as well as an internal to external proxy for internal service calls initiating outbound connections across FTP, MQ, (S)FTP(S), HTTP(S) and SOAP. In the external proxy case, the service gateway was really acting more like a traditional web proxy, but extended to protocols beyond web or HTTP traffic. To get an idea of the scope of this particular deployment, see the following Figure. In the previous figure, the problem is clear, we need a way to build a secure proxy assuming both client and server roles for both incoming and outgoing requests. That is, in addition to enforcing security policies for inbound requests, the same must be done in the outbound direction as well. This bidirectional deployment also allowed this customer to take advantage of the PKI and certificate management capabilities in the gateway for initiating outbound SSL connections as well as hide the internal IP addresses of public networks, which was another key consideration. To make this case concrete and show off some of the capabilities of the Intel® Expressway service gateway lets define three separate usage models: outbound proxy, inbound FTP server, and inbound proxy. Secure Outbound Proxy Outbound proxy consists of protocols that originate from within the datacenter and target a partner application over the Internet/Extranet. In this case, it was also important that persistent web single login cookies (WSL) were preserved in the HTTP layer. Expressway was deployed to handle the following: • Internal FTP to SFTP gets and puts • Internal SOAP calls to SFTP or FTPS gets and puts • Internal MQ to external SFTP or FTPS gets and puts • Internal SFTP based on a Timer to MQ or SOAP • Internal SOAP calls over HTTP to external SOAP using HTTP(S) and WS-Security Secure Inbound FTP Server A secure inbound FTP server mediates between FTP over SSH services exposed to the Internet or Extranet and mediates these to internal MQ, SOAP or plain FTP invocations. In this case, the Expressway service gateway is representing itself as an FTP server accessible over both SFTP and FTPS. Expressway was deployed to handle the following: • External SFTP put to internal MQ • External SFTP put to internal SOAP • Inbound FTP proxy that exposes an SFTP interface to an internal FTP server Secure Inbound Proxy (Reverse Proxy) The inbound proxy model is a more traditional orientation for a security gateway that protects services and enforces authentication for inbound requests. This model is also referred to as a reverse proxy model, where the service gateway is providing a virtual service endpoint to the caller. Expressway was deployed to handle the following: • Inbound Web Service client over HTTP/HTTPS and WS-Security to internal SOAP services, include pass-through of WSL (Web Single Login) cookies • SSL/TLS mutual authentication based on X.509 certificate trust processing • Extended X.509 authentication of additional fields using LDAP directories Further Thoughts: Considering Alternatives Given the scope of this particular customer project, a number of different alternatives were also considered, including custom hardware appliances as well as ESB solutions. In both of these cases, the alternatives didn’t end up meeting the specific customer requirements. This customer needed the following: 1. Linear Scalability – The end solution was required to scale without relying on custom hardware appliances. Scalability had to be achieved using standard, off the shelf Intel® Multi-Core servers. Further scalability had to be possible without a forklift upgrade of the large number servers spread throughout the Enterprise. 2. Protocol Flexibility – The solution was required to support secure file transfer protocols, including FTPS and SFTP in combination with HTTP, SOAP, WS-Security and IBM Websphere MQ. The middleware solution considered didn’t have this flexibility (Microsoft BizTalk) 3. TCO / Reduced Development Costs – Anything can be done given enough time and developers. What was needed in this case was a way lower the project costs, speed the time to market, and lower the overall total cost of ownership over the long run. The service gateway proved itself to be easier to use with a lower cost. What would you do? Here is a question to throw out for the comments – if you had a problem like this in your Enterprise, would you consider solving with a service gateway, ESB, custom hardware appliance, open source or some other solution? How would you keep the costs down and manage scalability and security over time?