Planning to secure your environment


There are several communication links from a browser on the Internet, through web servers and product servers, to the enterprise data at the back end. This section examines some typical configuration and common security practices. WAS security is built on a layered security architecture as showed below. This section also examines the security protection offered by each security layer and common security practice for good quality of protection in end-to-end security.

Operating System Security The security infrastructure of the underlying OS provides certain security services to the WebSphere Security Application. This includes the file system security support to secure sensitive files in WebSphere product installation. The WebSphere system administrator can configure the product to obtain authentication information directly from the OS user registry... the Windows system Security Access Manager.
Network Security The Network Security layers provide transport level authentication and message integrity and encryption. Communication between separate WASs can be configured to use SSL and HTTPS. Additionally IP Security and Virtual Private Networks might be used for added message protection.
JVM 1.3.1 The JVM security model provides a layer of security above the OS layer.
Java 2 Security The Java 2 Security model offers fine grained access control to system resources including file system, system property, socket connection, threading, class loading, and so on. Application code must explicitly grant the required permission to access a protected resource.
J2EE Security The security collaborator enforces J2EE based security policies and supports J2EE security APIs.
WebSphere Security WebSphere security enforces security policies and services in a unified manner on access to Web resources, enterprise beans, and JMX administrative resources. It consists of WebSphere security technologies and features to support the needs of a secure enterprise environment.
CORBA Security Any calls made among secure ORBs are invoked over the CSIv2 security protocol that sets up the security context and the necessary quality of protection. After the session is established, the call is passed up to the enterprise bean layer. WAS continues to support the Secure Authentication Service (SAS) security protocol which was used in prior releases of WAS and other IBM products for backward compatibility.

Each product appserver consists of a web container and an EJB container shown in the yellow shaded area and the administrative subsystem shown in red shaded area. The WAS Deployment Manager contains only WebSphere administrative code and the administrative console application. The administrative console is a special J2EE Web Application that provides the GUI interface for performing administrative functions. WAS configuration data is stored in XML descriptor files. Those XML configuration files should be protected by OS security. Passwords and other sensitive configuration data can be modified using the administrative console. Hence, the administrative console web application (.war) has a setup data constraint that requires the administrative console servlets and JSP files to be accessed only through an SSL connection when global security is enabled.

After installation, the administrative console HTTPS port is configured to use DumservernameKeyFile.jks and DumservernameTrustFile.jks with the default self signed certificate. Using the Dummy key and trust file certificate is not safe and generate your own certificate to replace dummy ones immediately. It is more secure if you first enable global security and complete other configuration tasks after global security is enforced.

WAS servers interact with each other through CSIv2 and SAS security protocols as well and HTTP and or HTTPS protocols. Those protocols can be configured to use SSL when WAS global security is enabled. The WAS administrative subsystem in every server uses SOAP JMX connectors and or RMI/IIOP JMX connectors to pass administrative commands and configuration data. When global security is disabled, the SOAP JMX connector uses HTTP protocol and the RMI/IIOP connector uses TCP/IP protocol. When global security is enabled, the SOAP JMX connector always uses HTTPS protocol. When global security is enabled, the RMI/IIOP JMX connector may be configured to either use SSL or to use TCP/IP. Again it is recommended to enable global security and enable SSL to protect the sensitive configuration data.

Note that Global security and administrative security configuration is at the cell level.

While global security is enabled, application security at each individual appserver may be disabled by disabling the per server level security enable flag. Disabling application server security does not affect the administrative subsystem in that application server which is controlled only by the global security configuration. Both administrative subsystem and application code in an application server share the optional per server security protocol configuration. article.

Security for J2EE resources is provided by Web container and EJB container. Each container provides two kind of security: declarative security and programmatic security.

In declarative security, an application security structure includes data integrity and confidentiality, authentication requirements, security roles, and access control. Access control is expressed in a form external to the application. In particular the deployment descriptor is the primary vehicle for declarative security in the J2EE platform. The WAS maintains J2EE security policy including information derived from the deployment descriptor and specified by deployers and administrators in a set of XML descriptor files. At run time, the container uses the security policy defined in the XML descriptor files to enforce data constraints and access control.

When declarative security alone is not sufficient to express the security model of an application, programmatic security may be used by application code to make access decisions. When global security is enabled and application server security is not disabled at the server level, J2EE applications security will be enforced. When the security policy is specified for a web resource, the web container performs access control when the resource is requested by a web client. The web container would challenge the web client for authentication data if none is present according to the specified authentication method, ensure the data constraints are met, and determine whether the authenticated user has the required security role. The web security collaborator enforces role-based access control by using an access manager implementation. An access manager makes authorization decision based on security policy derived from the deployment descriptor. An authenticated user principal is allowed to access the requested Servlet or JSP file if it has one of the required security roles. Servlets and JSP pages may use the HttpServletRequest methods isUserInRole and getUserPrincipal. When global security is enabled and appserver security is not disabled, EJB container will enforce access control on EJB method invocation. The authentication would take place regardless of whether method permission was defined for the specific EJB method. The EJB security collaborator enforces role-based access control by using an access manager implementation. An access manager makes authorization decisions based on security policy derived from the deployment descriptor. An authenticated user principal is allowed to access the requested EJB method if it has one of the required security roles. EJB code may use the EJBContext methods isCallerInRole and getCallerPrincipal. The J2EE role based access control should be used to protect valuable business data from being accessed by unauthorized users from both the Internet and the Intranet. .

WAS extends the security, role-based access control to administrative resources including the JMX system management subsystem, user registries, and JNDI name space. WebSphere administrative subsystem defines four administrative security roles...

A user with the configurator role can perform most administrative work including installing new applications and appservers. There are certain configuration tasks a configurator does not have sufficient authority to do when global security is enabled, including modifying WAS server identity and password, LTPA password and keys, and assigning users to administrative security roles. Those sensitive configuration tasks require the administrative role because the server id is mapped to the administrator role.

WebSphere Application Server administrative security is enforced when global security is enabled. It is recommended that WAS global security be enabled to protect administrative subsystem integrity. Application server security can be selectively disabled if there is no sensitive information to protect. For securing administrative security, refer to Assigning Users to Admin Roles Task and Assigning Users to Naming Roles WAS uses Java 2 Security Model to create a secure environment to run application code. Java 2 Security provides a fine, grained and policy based access control to protect system resources such as files, system properties, opening socket connections, loading libraries, and so on. J2EE 1.3 Specification defines typical set of Java 2 Security permissions that Web and EJB components should expect to have, which is shown in the table below.

J2EE Security Permissions set for Web components

Security Permission Target Action
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob * connect * read, write
java.util.PropertyPermission * read

J2EE Security Permissions set for EJB components

Security Permission Target Action
java.lang.RuntimePermission queuePrintJob * connect
java.util.PropertyPermission * read

WAS Java 2 Security implementation was based on J2EE 1.3 Specification. The Specification granted Web components read and write file access permission to any file in the file system, which may be too broad. WAS default policy gives Web components read and write permission to the sub directory and the sub tree where the Web module was installed. The default Java 2 Security policy for all Java virtual machines and WAS server processes are contained in the following policy files...


To simplify policy management, WAS policy is based on resource type rather than code base (location). Default policy for WAS subsystem that considered as an extension of WAS run time, which is referred to as SPI, for library shared by multiple applications, and for J2EE applications, are...

  1. ${was.install.root}/config/cells/<cellname>/nodes/<nodename>/spi.policy

    Used for embedded resources defined in the resources.xml file, such as the JMS, JavaMail and JDBC drivers.

  2. ${was.install.root}/config/cells/<cellname>/nodes/<nodename>/library.policy

    Used by the shared library defined by WAS administrative console.

  3. ${was.install.root}/config/cells/<cellname>/nodes/<nodename>/app.policy

    Used as the default policy for J2EE applications.

In general applications should not require more permissions to run than those recommended by the J2EE Specification in order to be portable among various appservers. But some applications may require more permissions. WAS allows a per application policy file, was.policy, to be packaged together with each application from granting extra permissions to that application. Note that granting extra permissions to an application should be handled with great care because of the potential of compromising system integrity.

WAS uses a permission filtering policy file to alert users when an application requires permissions that are on the filter list during application installation and cause the offended application installation to fail. For example, the java.lang.RuntimePermission exitVM permission should not be given to an application so that no application code is allowed to terminate the WAS appserver. The filtering policy is defined by the filterMask in...


Moreover, WAS also performs run time permission filtering based on the run time filtering policy to ensure no application code has been granted any permission that is considered harmful to system integrity. Applying Java 2 Security model to appserver is new.

WAS V4 supported Java 2 Security but only enforce three permission checking against exitVM, create and set the Security Manager. Other permission checking are disabled by default. Hence many applications developed for prior releases of WAS may not be Java 2 Security ready. To migrate those applications to WAS V5 quickly, you may temporarily give those applications in the was.policy file. It is recommended to test or make those applications Java 2 Security ready, i.e., identity what extra permissions, if any, are required and to just grant those permissions to a particular application. Not granting applications AllPermission can certainly reduce the risk of compromising system integrity.

WAS run time uses Java 2 Security to protect sensitive run-time functions and hence it is always a good idea to enforce Java 2 Security. Applications that are granted with AllPermission not only have access to sensitive system resources but also WAS run-time resources and can potential cause damage to both. In cases where an application can be trusted to be safe, WAS allows Java 2 Security to be disabled on a per appserver basis. In other words, you can enforce Java 2 Security by default in security center and disable the per application server Java 2 Security flag to disable it at the particular application server.

The global security enable flag and Java 2 Security enable flag along with other sensitive configuration data are stored in a set of XML configuration files. Both role based access control and Java 2 Security permission based access control are employed to protect the integrity of the configuration data. We will use configuration data protection as an example to illustrate how system integrity is maintained.

Other WebSphere Application Server run time resources are protected by similar mechanism as described above. Hence it is very important to enable WAS global security and to enforce Java 2 Security. J2EE Specification defines four authentication method for Web components. WAS supports HTTP Basic Authentication, Form Based Authentication, and HTTPS Client Certificate Authentication. When using client certificate login, it is more convenient for the browser client if the web resources have integral or confidential data constraint. If a browser uses HTTP to access the web resource, the web container will automatically redirect it to the HTTPS port. The CSIv2 security protocol also supports client certificate authentication. SSL client authentication can also be used to setup secure communication among selected set of servers based on trust relationship.

Starting from the WebSphere Application Server plug-in at web server, SSL mutual authentication can be configured between it and the WAS HTTPS server. When using a self- signed certificate, one can restrict the WAS plug-in to communicate with only the selected two WAS servers as shown in the picture. Suppose you want to restrict the HTTPS server in WAS A and in WAS B to accept secure socket connection only from WAS plug-in W. You can generate three self-signed certificate using the IKEYMAN tool and certificate management utility. For example, use certificate W and trust certificate A and B. The HTTPS server of WAS A is configured to use certificate A and to trust certificate W. The HTTPS server of WAS B is configured to use certificate B and to trust certificate W.

The trust relationship is shown in the following table.

Server Key Trust
WAS -plug-in W A, B
WAS Server A A W
WAS Server B B W

In a Network Deployment installation, the WAS Deployment Manager is a central point of administration. System management commands are sent from the Deployment Manager to each individual appserver. When global security is enabled, all WAS servers can be configured to require SSL and mutual authentication. Suppose you want to further restrict that WAS server application A so that it can only communicate with WAS application server C and WebSphere Application Server application server B can only communicate with WebSphere Application Server application server D. Note, as mentioned previously, all WAS appservers must be able to communicate with WAS Deployment Manager E. Hence, when using self-signed certificates, You might configure the CSIv2 and SOAP/HTTPS Key and trust relationship as shown in the following table.

Server Key Trust
WAS Server A A C, E
WAS Server B B D, E
WAS Server C C A, E
WAS Server D D B, E
WAS Deployment Manager E E A, B, C, D

When WAS is configured to use an LDAP user registry, SSL with mutual authentication also can be configured between every appserver and the LDAP server with self-signed certificate so that no password will be passed in clear text from WAS to the LDAP server. In this example, the Node Agent processes were not discussed. Each Node Agent needs to communicate with appservers on the same node and with the Deployment Manager. Node agents also need to communicate with LDAP servers when configured to use LDAP user registry. It is reasonable to let the Deployment manager and the node agents use the same certificate. Suppose application server A and C are on the same computer node. The Node Agent on that node needs to have certificates A and C in its trust file. WebSphere Application Server does not provide a user registry configuration or management utility. In addition, it does not dictate the user registry password policy. It is recommended that you use the password policy recommended by your user registry, including the password length and expiration period.

  1. Determine which versions of WAS you are using.
  2. Review the WAS security architecture.
  3. Review each of the following topics as also defined in Related reference.


See Also

Programmatic login
Assigning users to administrator roles
Assigning users to naming roles