This tip is an excerpt of the article "Web security primer for iSeries environments, Part II" published in the...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
March/April 2005 edition (volume 8, number 2) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.
Java 2 Enterprise Edition (J2EE) defines a distributed, enterprise application model under which applications run in four different types of J2EE containers: application, applet, Web, and Enterprise JavaBean (EJB). Web application servers such as Tomcat and WebSphere Express provide only a Web container to run Java Web applications. If you need EJB support, you need to purchase the full WebSphere server, JBOSS, or another Web application server that implements the full J2EE specification.
WebSphere Express security is based on the J2EE security model. The J2EE specification covers the security aspects on an application from development through deployment and runtime. While some J2EE security concepts are similar to iSeries security concepts (users and groups are granted permissions to application resources), there are also differences. Here is the cycle for implementing WebSphere Express security:
- Developers define logical roles for how an application is used. In order processing, roles may be order clerk, shipper, manager, and so on, with a coinciding set of permissions for each.
- The system maps the roles to users (or principals) and groups during deployment.
- The J2EE runtime environment enforces the security policies defined. When the role that a user has been authorized to is found, the assigned permissions for that role and for the given resource are retrieved, and it is determined whether or not the user can access the resource.
J2EE security policies can be defined declaratively (through configuration files called deployment descriptors) or programmatically. With declarative security, access controls and security constraints are defined in the deployment descriptor files. With programmatic security, a Web application can run the method getUserPrincipal to identify a user and run the method isUserInRole to see if the user is authorized to a specific role.
For a WebSphere Express application, you can specify one of several user authentication mechanisms:
- Basic authentication. The realm name is sent from the server to the browser and the user name and password are sent by the browser as part of the HTTP request.
- Client certficate authentication. Each client has a valid digital certificate. Credentials are sent from the digital certificate over a secure sockets layer (SSL) encryption connection to the server. Although the mechanism is very secure, it can be cumbersome to set up for many types of clients.
- Form authentication. The user supplies values for user ID and password. These are transmitted in clear text as part of the HTTP request. SSL connections are required to ensure that this information is secure.
The WebSphere console, Web-Sphere Application Assembly Tool, and WebSphere Studio all provide easy-to-use interfaces to specify the security constraints and provide validation checks on the constraints specified. You can also use the XML source shown in Figure 1. This is a security constraint in the deployment descriptor for the DefaultApplication shipped with WebSphere. It restricts access to the Snoop servlet to all authenticated users. If you try to access the servlet with global security enabled, you are prompted to log on. If your logon attempt fails, you can't access the servlet. Everyone and All Authenticated are two predefined roles that can also be configured for any application.
<security-constraint id="SecurityConstraint_1" > <web-resource-collection id="WebResourceCollection_1" > <web-resource-name> Snoop Servlet</web-resource-name> <description> Protection area for Snoop Servlet. </description> <url-pattern> /snoop/*</url-pattern> <http-method> GET</http-method> <http-method> POST</http-method> </web-resource-collection> <auth-constraint id="AuthConstraint_1" > <description> Snoop Servlet Security:+:All Authenticated users for Snoop Servlet. </description> <role-name> All Role</role-name> </auth-constraint> <user-data-constraint id="UserDataConstraint_1" > <transport-guarantee> NONE</transport-guarantee> </user-data-constraint> </security-constraint> <security-role id="SecurityRole_1" > <description> All Authenticated Users Role. </description> <role-name> All Role</role-name> </security-role>
Figure 1: Deployment descriptor security constraint
The J2EE security model works in a single-server environment but can scale across an enterprise as well. It also offers a flexible set of authentication and authorization options. With J2EE, you define a group of servers in a protection realm. A protection realm is a security domain in which a group of servers shares a common security management system. In WebSphere terms, a cell (a group of servers centrally administered) across multiple nodes (systems) could be defined as a single realm. In this case, the security management system needs to provide distributed support for authentication. Lightweight Third-Party Authentication (LTPA) protocol provides a standard way to access a central security repository stored in a Lightweight Directory Access Protocol (LDAP) directory server within a realm. The nice part about the LDAP standard is that all applications in an enterprise (even Microsoft) can use the common directory services.
Normally, a secure WebSphere Express application environment combines transport security (encryption with SSL), WebSphere application security (authentication and authorization), and operating system security for server resources (authentication and object and data authorizations). In addition to securing WebSphere Express applications, you'll want to ensure that the server and its configuration are secure. On the iSeries, that means, at a minimum, removing default public access from the integrated file system (IFS) folders where the WebSphere Express server is stored.
By and large, WebSphere Express is accessed via a plug-in from the Apache HTTP server. It's possible to use the Apache HTTP server security directives to control access to WebSphere Express applications and resources. If you're already familiar with Apache directives, this may be a simple, high-level way to control access to your Web application's resources. Because of the administrative effort involved, the HTTP directives are not normally used for fine-grained access control. With the Alias directive, you can map a uniform resource identifier (URI) path name to a different physical path name on the server while hiding the actual directory (/static/images) from a Web user:
Alias /images/ /static/images/
Apache Location directives can limit access to a directory to a user or group easily. But you may prefer using WebSphere Express security instead because it offers more options and, in some cases, easier maintenance.
Your network environment should also be secured with a model that fits your specific business needs. IBM recommends running SSL connections between all servers in your enterprise. While this is appropriate in a large organization that may have many internal security risks, a small shop with a single iSeries production server and a development box normally would not need that level of complexity. A more common method is to set up a firewall to the Internet that protects your Web servers and authentication servers from direct Internet access.
Firewalls have expanded to include many security functions: locking down ports, monitoring and filtering traffic by port and IP address, forwarding traffic for specific ports to other addresses, using Network Address Translation (NAT), proxy serving, and more. Also, it's fairly common to set up a second firewall between the Web servers and the host application and database servers in your network, creating a security demilitarized zone (DMZ). If security on the first firewall is breached, the only exposure is the Web servers. An intruder would have to breach the second firewall as well to access your company data.
---------------------------------------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 email@example.com.
This tip is an excerpt of the article "Web security primer for iSeries environments, Part II" published in the March/April 2005 edition (volume 8, number 2) of the iSeries 400 Experts Journal. Provided courtesy of iSeries 400 Experts.