Problem solve Get help with specific problems with your technologies, process and projects.

Security services for each Web environment layer

What are your options for Web security? Security is based on the control layers in the Web application environment, and you have many security options at each layer.

This tip is an excerpt of the article "Web security primer for iSeries environments, Part I" published in the January/February 2005 edition (volume 8, number 1) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.

Jim Mason

What are your options for Web security? Security is based on the control layers in the Web application environment, and you have a number of security options at each layer that you can implement. Logically, the control layers in a Web environment are client layer, network layer, TCP server layer, Web application server layer, and iSeries host server layer, as shown in the below figure.

Figure: Security services by Web environment service layer

While an IBM "best practices" model emphasizes the WebSphere tools, security tools in other service layers can address the same security threats. The IBM Redbook AS/400 Internet Security Scenarios: A Practical Approach (SG245954) points out some of the other security tools and scenarios. In some cases, the AS/400 networking roles presented in this Redbook are no longer practical, but the scenarios and the iSeries' role as a host server are still useful.

Depending on the type of client, different security features are available. For a Web client, the choices include digital certificate support, SSL support in the browser environment, Java applets, and applications running SSL URL connections to the server.

The network layer allows control over which clients are able to access which servers. Often a demilitarized zone (DMZ) is set up to disconnect the Internet from direct access with the internal network. This typically involves a firewall, a router, proxy servers, mail relay servers, a domain name server (DNS), and a Dynamic Host Configuration Protocol (DHCP) server. Collectively, these tools can deliver a variety of security services:

  • Packet filtering to control clients through IP address

  • Network address translation (NAT) to hide internal IP addresses

  • A firewall to limit IP port access

  • DNS user names to hide internal IP addresses

  • DHCP to dynamically assign IP addresses

  • Proxy servers to prevent direct connections between the Internet and internal systems

  • IPSec protocol to run VPN connections for encrypted traffic on a point-to-point basis between remote systems

  • Relay of mail from outside servers to internal mailboxes

  • SSL protocol to provide data encryption between external clients and the internal network

That's a lot of security capability.

At the TCP server layer, many TCP applications have a variety of security features available. Most TCP applications (HTTP, FTP, Telnet, SMTP) now support SSL encryption. For Web serving, the standard Apache HTTP server supports many security features, including SSL, resource aliases, virtual host mappings, URL rewriting, URL redirects, client IP address filters, user authentication, resource authorizations, load balancers, server certificates, Kerberos authentication, user exit APIs, and reverse proxy support (hiding internal applications, servers and data addresses from external clients). Most of the time, we set up a free Apache HTTP server on a low-cost Intel box to run SSL as a reverse proxy server. This means that all traffic from the Apache server to the client over the Internet is encrypted, but the traffic from the Apache Server to the Web application server isn't (thus improving performance on the Web application server).

A Web application server is a Java application designed to meet the J2EE specifications for a server. To support Web application server security, one sets deployment descriptor configuration files. WebSphere, WebSphere Express, Apache Tomcat, and other third-party Web application servers support security configuration for user authentication, user-to-role mappings, role-based authorizations to application resources, Kerberos authentication, and Servlet filters.

A Web application server application can also implement programmatic security by using the Java security frameworks (JGSS, JAAS, JSSE, JCP, and JNDI) in a Web context. Your Java Web application will often access other applications and data on the iSeries host server. There are many different frameworks that can be used to access the iSeries, and most of them offer security features. Perhaps the most common is the iSeries Java Toolkit, which has a number of important security features, including Kerberos support with JGSS for user authentication, JSSE for data encryption and SSL support, proxy server support, and digital certificates. Remember, your Web application server can be running on an iSeries server, an IBM Open Power server, or an Intel box.

Finally, the iSeries host server has many security features that iSeries professionals are familiar with, such as user authentication, object management authorities, object data authorities, server certificates, Kerberos authentication, user-group mappings, object authorization lists, database journaling, user exit APIs, and security monitoring tools. These give you another security control layer to work with.

Another security option is single sign-on (SSO) support using Kerberos authentication. Whether you buy IBM's Enterprise Identity Management (EIM) product, another vendor's identity management tools, or an open-source solution, it will provide a similar service: managing a Kerberos authentication framework using digital certificates to automatically grant a user access to the server using a specific identity (in effect, logging on correctly without prompting the user for a user ID and password). To do this, an SSO environment needs a directory server to integrate all of the different security information for a given user on all platforms in one central place. For instance, I might have three user IDs in your network, one each for the iSeries, Linux, and Windows servers. The central directory server maps each of those to one common ID and password that I use to log on to the network. When I access any application on any of the servers, I'm automatically logged on to that server.


About the author: Jim Mason works at ebt-now, an iSeries Web integration company, providing QuickWebServices for iSeries customers: Web planning, WebSphere, WebFacing, Web development, Web networking, Web support, Web security and training services. Jim is creating a self-study course for RPG programmers that teaches "hands-on" rapid visual development with WDSC for all types of iSeries and e-business applications without the need to become a Java expert. Rochester Initiative will publish the course. You can reach Jim at

This tip is an excerpt of the article "Web security primer for iSeries environments, Part I" published in the January/February 2005 edition (volume 8, number 1) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.

Dig Deeper on Web Security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.