aXes Architecture

aXes is usually installed in a corporate enterprise or service provider (SP) environment. Levels of security in these environments can vary widely, from no firewalls to firewalls installed between and around every possible layer in the infrastructure.

The goal of aXes is to be flexible enough to operate in whatever security environment in which it is installed, with little to no change to the existing infrastructure. In some cases, the client devices will reside at remote sites that are not managed by the organization that controls aXes. Client devices 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 for users is to be able to access their business applications over the Internet, without jeopardizing corporate security. Any software or hardware operating in an enterprise or SP 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 includes an integrated Application Server with its own fast, secure HTTP Server for the IBM iSeries (AS/400) with integrated Website acceleration technology. By using the aXes Application Server, loads can be reduced, Web responsiveness can be improved, and site quality of service can be more easily predicted and managed.

Firewalls, caching and proxy servers

Firewalls are deployed in an enterprise or SP environment as a security measure to control access to servers on a network. If the client device and the aXes Application Server are behind the same firewall, the client may connect directly to the aXes Application Server. This will be the case if the client is on the same Intranet as the aXes Application Server, uses an Internet access method (such as a VPN) or uses dial-up to communicate – these methods look like a local connection. Alternatively, the client device may reside outside the aXes Application Server site's firewall. In this case, the client device connects directly over the Internet through the firewall to the aXes Application Server or is routed through a firewall at its own site before reaching the Internet to connect to the aXes Application Server.

The aXes Application Server provides explicit HTTP headers instructing an HTTP 1.1 proxy server not to cache aXes transactions. Proxy servers will not cache aXes transactions, as each transaction is a unique URL. Other aXes Application Server HTTP transactions will cache normally through a proxy server.

For more firewall and proxy server information, please visit:

aXes ports

aXes Application Server uses HTTP or HTTPS protocols. Each of these connection types is serviced by a process listening on a port on the aXes Application Server. The ports used by default are:

  • Port 80 HTTP
  • Port 443 HTTPS

Protocols can be encrypted or not encrypted, depending on the security settings for the user.

Users typically access applications via aXes Application Server by typing the URL for the server in their browser, for example https://www.axeslive.com/. The initial connection to the aXes Application Server is always made via either HTTP or HTTPS. The aXes Application Server responds to the HTTP or HTTPS request and presents a login screen to the user. Internet traffic is generated as the user logs in, launches applications and responds to the applications.

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

If the client device 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 IBM i Telnet server need to be running when aXes is running.

Most Telnet based solutions (rich or thin clients) open two ports (port 23 and port 992) however the aXes Application Server 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 IBM i applications to the Web open security breaches to the server?" This is especially relevant when some products open a combination of ports to provide session access, ODBC connectivity, Java client access and/or direct sockets access to server 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 being able to access the server. Correct IBM i security procedures should be in place to restrict the number of unsuccessful sign on attempts and track the intrusion attempt.

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

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

  • Not using Telnet (in fact the Telnet server can be disabled without affecting aXes)
  • Never displaying a server 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 measures aXes provides

Security is an integral part of the aXes Suite and was designed to protect your data and applications while making those applications available to remote users over the Internet using a browser. aXes supports a number of physical implementations each intended to provide different levels of scalability and performance and without compromising security. Some of the security concerns aXes addresses are the following.

  • aXes supports the IBM i security and authentication mechanisms up to and including the highest security level (level 50).
  • User identification and passwords are encrypted before transmission and cannot be cached in the browser.
  • aXes supports log-in from specific IP addresses.
  • aXes supports log-in from specific device names.
  • aXes provides shadowing of user sessions on the server - a service used by administrators to examine the activity of people using aXes in real time.
  • aXes Application Server supports both Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols which allow for secure authentication, encryption, non-repudiation and VPN technologies. Both SSL and VPNs prevent eavesdroppers from listening and intercepting traffic between browser and the server.

Communications traffic between the browser and aXes Application Server is compressed (GZIP) which offers two major benefits:

  • Traffic is harder to monitor with sniffer devices, and
  • When using SSL or VPN technologies, the amount of data transmitted between server and browser is reduced before the SSL or VPN encryption or decryption processing takes place

Compressing the traffic results in considerable savings in bandwidth and CPU cycles when using SSL or VPN technologies.

aXes Application Server secures Web pages by requiring specific read (*R) and execute (*X) authority to the underlying server files. It secures access to server directories by using Access Control Lists.

Back to Top