Configure Gateway as FTP Server
This topic describes how the gateway works with FTP requests and how to configure it as a FTP Server.
This topic describes how the
Layer7 API Gatewayworks with FTP requests and how to configure it as a FTP Server.
Working with FTP Requests
Layer7 API Gatewaycan be configured as an FTP(S) server. This allows it to communicate with legacy applications where EDI-like bulk XML data transactions are required.
When configured as an FTP server, the
Layer7 API Gatewaywill support the following:
- FTP requests into theLayer7 API Gateway, FTP out from theLayer7 API Gatewayto a back-end FTP server (“FTP in/FTP out”)
- FTP requests into theLayer7 API Gateway, HTTP out from theLayer7 API Gatewayto a back-end SOAP web service or XML application (“FTP in/HTTP(S) out”)
- FTP requests into theLayer7 API Gateway, JMS Routing from theLayer7 API Gatewayvia a JMS queue (“FTP in/JMS out”)
- HTTP(S) requests into theLayer7 API Gateway, FTP out from theLayer7 API Gatewayto a back-end FTP server (“HTTP(S) in/FTP out”)
- JMS requests into theLayer7 API Gateway, FTP out from theLayer7 API Gatewayto a back-end FTP server (“JMS in/FTP out”)
For each of the above, requests can be anonymous, authenticated, or authenticated over SSL.
- The “API Gateway - Enterprise” edition of theLayer7 API Gatewayis used (FTP endpoints not supported in the otherLayer7 API Gatewayversions).
- TheLayer7 API Gatewayis deployed with a load balancer that supports session affinity for FTP(S) data transfers. For more information, see Configure the Load Balancer.
- A SOAP web service or an XML application has been published. For more information, see Publish Web API.
The remote path in the FTP client must be set to the service’s resolution path. If a web service is published without a resolution path, the FTP client should use /ssg/soap as the remote path. For more information, see "About the Resolution Path" in Published Service Properties.
Layer7 API Gatewaysupports the following protocols when configured as an FTP(S) server:
- RFCS 959 - File Transfer Protocol
- RFC 2389 - Feature Negotiation Mechanism for the File Transfer Protocol
- RFC 2640 - Internationalization of the File Transfer Protocol
- RFC 3659 - Extensions to FTP
Set Up the FTP Server
You should have the following information before setting up an FTP server:
- IP address for the FTP service to monitor
- Port number to listen on for control connections
- Starting port number to listen on for passive data connections
- Number of ports for use with passive connections
To set up an FTP server on the:
Layer7 API Gateway
- Run the Manage Listen Ports task and configure a listener using the FTP protocol. For more information, see Manage Listen Ports.
Configure a Policy for FTP
Once the FTP server has been set up, configuring a policy to accept FTP requests is similar to one that uses conventional HTTP requests.
There are two assertions specifically designed for FTP:
- Require FTP Credentials: Used to authenticate FTP requests. The user name and password are retrieved from the FTP session for later authentication and authorization using the Authenticate User or Group assertion. Not used for anonymous FTP requests. This is the FTP equivalent of the Require HTTP Basic Credentials assertion.
- Route via FTP(S): Used to route requests to a back-end FTP server, using passive mode FTP. This is the FTP equivalent to the Route via HTTP(S) assertion.
Other assertions not specific to FTP that are also useful in a policy involving FTP include:
- Require SSL or TLS Transport: Used enforce FTP requests over a secure connection. If this assertion is used, ensure that the Require Client Certificate Authentication check box is not selected.
- Authenticate User or Group: Used to authorize users or groups when FTP requests are authenticated.
- Require HTTP Basic Credentials: Used to authenticate HTTP requests for the “HTTP(S) in/FTP out” scenarios.
- Route via HTTP(S): Used to route requests to an HTTP endpoint for the “FTP in/HTTP(S) out” scenarios.
- Route via JMS: Used to route requests to a JMS endpoint for the “FTP in/JMS out” scenario.
FTP authentication is deferred since the identity provider to be verified against is unknown until a policy is resolved. This means that any login/password is accepted initially, but access will be denied if the credentials do not match the policy.
Context Variables Used by the FTP Service
The FTP service references the following context variables:
Limitations and Considerations
Note the following when using the
Layer7 API Gatewayas an FTP server:
- Gateway does not support TLS resumption.
- Only streaming and implicit FTP(S) and passive FTP are supported
- Multipart/MIME files are not supported
- The FTP(S) server will validate using the existing SSL keystore; client certificates not used
- Response messages will not be returned to the FTP client, but they will be audited; to view them, use the Gateway Audit Events windows
- For every FTP request, the Content-Type is assumed to be “text/xml”, while the SOAPAction header is assumed to be empty (this information is not extracted from the HTTP transport)
- When connected to the back-end FTP server, you can use the “cd” command to change directories to upload a file. However, it is not possible to “list” these virtual directories.