click to enlarge
terminal emulation
click to enlarge
print spooled files
axes secure architecture
axes is usually installed in a corporate enterprise or xSP environment. Levels of security in these environments can vary widely: from no firewalls installed to firewalls installed at every possible juncture.

The goal of axes is to be flexible enough to work in whatever security environment it is installed in, with little to no change to the existing infrastructure. In some cases, the client may reside at remote sites that are not managed by the organization that controls axes. Clients may be routed through firewalls and/or proxy servers when accessing servers over the Internet. Corporate security policies at the client site may only allow traffic to or from a specific port. The challenge is for users to be able to access their business applications over the Internet, without jeopardizing corporate security. Any software or hardware operating in an enterprise or xSP environment with Internet access must address this challenge. axes overcomes this challenge without affecting the end user, without compromising security policies, and without disrupting the existing infrastructure or requiring costly alternatives, such as a Virtual Private Network (VPN).

axes, firewalls and proxy servers

Firewalls are usually deployed to implement security, in an enterprise or xSP environment. If the client and the axes W3 web server are behind the same firewall, then the client may connect directly to the axes W3 web server. This may be the case if the client is on the same LAN as the axes W3 web server, or uses a dial-up method or an Internet access method (such as a VPN) that makes it look like a local connection.

Alternatively, the client may reside outside the axes W3 web server site's firewall. In this case, it either connects directly over the Internet through the firewall to the axes W3 server, or it is routed through a firewall at its own site before reaching the Internet to connect to the axes W3 web server.

The axes W3 web server provides any proxy server with explicit HTTP headers instructing an HTTP 1.1 proxy server not to cache axes TS terminal server transactions. Proxy servers will not cache axes TS terminal server transactions, as each transaction is a unique URL. Other axes W3 web server HTTP transactions will cache normally through a proxy server.

further information

For more firewall and proxy server information, please visit:

axes ports

axes W3 software uses a combination of HTTP or HTTPS protocols. Protocols can be encrypted or unencrypted, depending on the security settings for the user. Each of these connection types is serviced by a process listening on a port on the axes W3 web server.

The ports used by default are:

  • Port 80 HTTP
  • Port 443 HTTPS

Users typically access applications via axes W3 by typing the URL for the server in their browser, for example https://www.arterialsoftware.com/. The initial connection to the axes W3 web server is always made via either HTTP or HTTPS. The axes W3 web server, responds to the HTTP(S) request and presents a login screen to the user. Web traffic is then communicated as the user logs in and launches applications.

To run in a secure environment, it is desirable to encrypt web traffic. Therefore, it is likely that HTTPS would be used. If the secure axes W3 web server (HTTPS) listens on port 443, then this port must be accessible to incoming traffic. This would require that the port be accessible through the firewall at the axes W3 server site. If the client site also has a firewall or proxy server, traffic must be allowed through port 443.

If the client resides in a secure environment, the client side firewall and/or proxy server may allow outbound traffic only to port 443 of the destination server. In these situations, web traffic must communicate on port 443.

axes and Telnet

axes does not use Telnet, neither the Telnet protocol nor the AS/400 Telnet server need to be running when axes Server is running.

Most Telnet based solutions (thick or thin clients) open two ports (port 23 and port 992) however axes TS and axes W3 will listen on the default port for HTTP applications (port 80) or on a user specified port

A question often asked is, “Does using Telnet or Telnet based gateway solutions for serving iSeries application to the web open security breaches to the host?” This is especially relevant when some products open a combination of ports (detailed below) for providing session access, ODBC connectivity, Java client access and/or direct sockets access to host applications and data.

The answer is no, because even if a hacker or intruder could successfully connect to an open Telnet session (and be presented with a sign on screen), they would still need to know a user-login and password combination before accessing the host. Correct iSeries (AS/400) security procedures would then be activated to restrict number of unsuccessful sign on attempts and track the intrusion attempt.

Telnet-based approaches to host access do however allow a hacker to determine the type of host system if they can connect to a session. This is because the session will display a host sign-on screen.

A standard security approach is to minimize the amount of information available to a potential hacker. axes Server improves on the Telnet-based approach by:

  • Not using Telnet (in fact the host Telnet server can be disabled without affecting axes Server)
  • Never displaying a host sign-on screen
  • Always encrypting the user ID and password (even if SSL is not used)
  • Using the HTTP ports rather than the Telnet ports

Security is an integral part of axes Server. It was designed to protect your data and applications while making those applications available to remote users over the most easily accessible medium using the ubiquitous browser interface. As can be seen from the scenarios described previously, axes Server supports a number of physical implementations each intended to provide different levels of scalability and performance without compromising security.

Security Considerations

axes addresses a number of security concerns when serving applications from your iSeries (AS/400) to browser based users.

  • axes supports the existing iSeries (AS/400) security and authentication mechanisms up to and including Security Level 50.

  • axes supports log-in from specific IP address and/or device name.

  • axes supports shadowing of user sessions on the host.

  • axes Server supports both Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols which allow for secure authentication, encryption, non-repudiation and Virtual Private Network (VPN) technologies. Both SSL and VPNs prevent "eavesdroppers" from listening and easily intercepting traffic between browser and host.

  • Communications traffic between the browser and axes W3 is in a compressed format (GZIP) which gives two major benefits: traffic is harder to monitor with sniffer devices and, when using SSL or VPN technologies, the amount of data transmitted between host and browser is reduced before the SSL or VPN encryption or decryption processing takes place. This results in considerable savings in bandwidth and CPU cycles when using SSL or VPN technologies.

  • User ID and Passwords are encrypted before transmission and cannot be cached in the browser.

  • axes W3 secures web pages by requiring specific read (*R) and execute (*X) authority to the underlying files. It also secures access to directories by using Access Control Lists.