Security planning



Search Tips   |   Advanced Search


WAS security

WebSphere security

WAS security enforces security policies and services in a unified manner on access to Web resources, enterprise beans, and JMX admin resources.

Java security

Java EE security API

The security collaborator enforces Java EE-based security policies and supports Java EE security APIs.

CORBA security (CSIv2)

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.

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
  • etc...

Application code must explicitly grant the required permission to access a protected resource.

JVM 5.0

The JVM security model provides a layer of security above the operating system layer. For example, JVM security...

  • protects the memory from unrestricted access
  • creates exceptions when errors occur within a thread
  • defines array types

Platform security

Operating system security

OS security services include the file system security support that secures sensitive files in WAS installation for WAS. The system administrator can configure WAS to obtain authentication information directly from the operating system user registry.

The identity of the servant controller, and daemon Started Task, as established by the STARTED profile, is the identity used to control access to system resources such as files or sockets. Optionally, the operating system security can provide authentication services using the User Registry of local operating system, and/or authorization services using SAF Authorization for the WebSphere Administration console and for applications running under the appserver.

In addition to knowledge of SSL and TLS, the administrator must be familiar with System Authorization Facility (SAF) and Resource Access Control Facility (RACF), or an equivalent SAF based product.

The identity and verification of users can be managed by using a Local Operating System as the User Registry, RACF or equivalent SAF base product. Alternatively, an LDAP, Custom, or Federated User Registry can be used.

WebSphere can be configured to use SAF Authorization, which will use RACF or an equivalent SAF based product to manage and protect users and group resources. Alternatively, WebSphere can be configured to use WebSphere Authorization or a JACC External Authorization Provider.

When using either Local Operating System as the User Registry and/or using SAF Authorization, security auditing is an inherit feature of RACF or the equivalent SAF based products.

Network security

The Network Security layers provide transport level authentication and message integrity and confidentiality. Configure the communication between separate appservers to use SSL. Additionally, we can use IP Security and Virtual Private Network (VPN) for added message protection.

WAS ND installation

A node agent instance exists on every computer node.

Each product appserver consists of a Web container, an EJBs container, and the admin subsystem.

The WAS dmgr contains only WAS admin code and the admin console.

The admin console is a special Java EE Web app that provides the interface for performing administrative functions. WAS configuration data is stored in XML descriptor files, which must be protected by operating system security. Passwords and other sensitive configuration data can be modified using the admin console. However, protect these passwords and sensitive data.

The admin console Web app has a setup data constraint that requires access to the admin console servlets and JSPs only through an SSL connection when admin security is enabled.

In WAS V6.0.x and earlier, the administrator console HTTPS port was configured to use DummyServerKeyFile.jks and DummyServerTrustFile.jks with the default self- signed certificate. The dummy certificates and keys must be replaced immediately after WAS installation; the keys are common in all of the installation and are therefore insecure. WAS Version 6.1 provides integrated certificate and key management, which generate distinct private key and self-signed certificate with embedded server host name to enable host name verification. WAS V6.1 also enables integration with external certificate (CA) authority to use CA-issued certificates. The WAS V6.1 installation process provides an option to enable administrative security during installation. As a result, a WAS process is secured immediately after installation. WAS V7.0 extends the embedded certificate management capabilities by creating a chained certificate (personal certificate signed by a root certificate) to enable refresh of the personal certificate without affecting the trust established. It also enables tailoring of the certificate during profile creation (we can import our own or change the distinguished name (DN) of the one created by default) as well as the ability to change the default keystore password.

The following figure shows a typical multiple-tier business computing environment.


Administrative security

Servers interact with each other through CSIv2 and Secure Authentication Services (SAS) security protocols as well as the HTTP and HTTPS protocols.

SAS is supported only between V6.0.x and previous version servers that have been federated in a V6.1 cell.

Configure these protocols to use SSL when you enable WASadministrative security. The WAS admin subsystem in every server uses SOAP, JMX connectors and RMI/IIOP JMX connectors to pass admin commands and configuration data. When admin security is disabled, the SOAP JMX connector uses the HTTP protocol and the RMI/IIOP connector uses the TCP/IP protocol. When admin security is enabled, the SOAP JMX connector always uses the HTTPS protocol. When admin security is enabled, we can configure the RMI/IIOP JMX connector to either use SSL or to use TCP/IP.

IBM recommends that you enable admin security and enable SSL to protect the sensitive configuration data.

When admin security is enabled, we can disable application security at each individual appserver by clearing the Enable admin security option at the server level.

Disable appserver security does not affect the admin subsystem in that appserver, which is controlled by the security configuration only. Both admin subsystem and application code in an appserver share the optional per server security protocol configuration.


Security for Java EE resources

Security for Java EE resources is provided by the Web container and the EJB container. Each container provides two kinds of security: declarative security and programmatic security.

In declarative security, an application security structure includes network message integrity and confidentiality, authentication requirements, security roles, and access control. Access control is expressed in a form that is external to the application. In particular, the deployment descriptor is the primary vehicle for declarative security in the Java EE platform. WAS maintains Java EE security policy, including information that is derived from the deployment descriptor and specified by deployers and administrators in a set of XML descriptor files. At runtime, the container uses the security policy that is 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, we might use programmatic security to make access decisions. When admin security is enabled and application server security is not disabled at the server level, Java EE applications security is 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 challenges the Web client for authentication data if none is present according to the specified authentication method, ensures that the data constraints are met, and determines 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 decisions that are based on security policy derived from the deployment descriptor. An authenticated user principal can access the requested servlet or JSP file if the user principal has one of the required security roles. Servlets and JSPs can use the HttpServletRequest methods, isUserInRole and getUserPrincipal.

When administrative security and application security are enabled, and the application server level application security is not disabled, the EJB container enforces access control on EJB method invocation.

The authentication occurs regardless of whether method permission is 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 that are based on security policy derived from the deployment descriptor. An authenticated user principal can access the requested EJB method if it has one of the required security roles. EJB code can use the EJBContext methods, isCallerInRole and getCallerPrincipal. Use the Java EE role-based access control to protect valuable business data from access by unauthorized users through the Internet and the intranet. Refer to Secure Web apps using an assembly tool, and Securing enterprise bean applications.


Role-based security

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

Monitor role

A monitor can view the configuration information and status but cannot make any changes.

Operator role

An operator can trigger run-time state changes, such as start an appserver or stop an application but cannot make configuration changes.

Configurator role

A configurator can modify the configuration information but cannot change the state of the runtime.

Administrator role

An operator as well as a configurator, which additionally can modify sensitive security configuration and security policy such as setting server IDs and passwords, enable or disable admin security and Java 2 security, and map users and groups to the administrator role.


The iscadmins role has administrator privileges for managing users and groups from within the admin console only.

WAS defines two additional roles that are available when you use wsadmin scripting only.


A deployer can perform both configuration actions and run-time operations on applications.


An admin security manager can map users to administrative roles. Also, when fine grained admin security is used, users granted this role can manage authorization groups.


An auditor can view and modify the settings for the security auditing subsystem.

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

Enable WAS administrative security to protect admin subsystem integrity. Application server security can be selectively disabled if no sensitive information is available to protect. For securing admin security, refer to Authorizing access to admin roles and Assigning users and groups to roles.


Java 2 security permissions

WAS uses the 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. The Java EE V1.4 spec defines a typical set of Java 2 security permissions that Web and EJB components expect to have. These permissions are shown in the following table.

Table 1. Java EE 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

Table 2. Java EE security permissions set for EJB components

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

The Java 2 security default policies are based on the Java EE V1.4 specification. The specification grants Web components read and write file access permission to any file in the file system, which might be too broad. The WAS default policy gives Web components read and write permission to the subdirectory and the subtree where the Web module is installed. The default Java 2 security policies for all Java virtual machines and WAS processes are contained in the following policy files:


This file is used as the default policy for the JVM.


This file is used as the default policy for all product server processes.

To simplify policy management, WAS policy is based on resource type rather than code base (location).

The following files are the default policy files for a WAS subsystem. These policy files, which are an extension of the WAS runtime, are referred to as Service Provider Programming Interfaces (SPI), and shared by multiple Java EE applications:

In general, applications do not require more permissions to run than those recommended by the Java EE spec to be portable among various appservers. However, some applications might require more permissions. WAS supports the packaging of a was.policy file with each application to grant extra permissions to that application.

Grant extra permissions to an application only after careful consideration because of the potential of compromising the system integrity.

Loading libraries into WAS does allow applications to leave the Java sandbox. WAS uses a permission filtering policy file to alert you when an application installation fails because of additional permission requirements. For example, IBM recommends that you not give the java.lang.RuntimePermission exitVM permission to an application so that application code cannot terminate WAS.

The filtering policy is defined by the filtermask in the $WP_PROFILE/config/cells/cell_name/filter.policy file. Moreover, WAS also performs run-time permission filtering that is based on the run-time filtering policy to ensure that application code is not granted a permission that is considered harmful to system integrity.

Therefore, many applications developed for prior releases of WAS might not be Java 2 security ready. To quickly migrate those applications to the latest version of WAS, we might temporarily give those applications the permission in was.policy. Test those applications to verify they run in an environment where Java 2 security is active. For example, identify which extra permissions, if any, are required, and grant only those permissions to a particular application. Not granting the AllPermission permission to applications can reduce the risk of compromising system integrity.

The WAS runtime uses Java 2 security to protect sensitive run-time functions. Applications that are granted the AllPermission permission not only have access to sensitive system resources, but also WAS run-time resources and can potentially cause damage to both. In cases where an application can be trusted as safe, WAS does support having Java 2 security disabled on a per appserver basis. We can enforce Java 2 security by default in the admin console and clear the Java 2 security flag to disable it at the particular appserver.

When specify the Enable admin security and Use Java 2 security to restrict application access to local resources options on the Global security panel of the admin console, the information and 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. The example uses configuration data protection to illustrate how system integrity is maintained.

The Enable global security option in previous releases of WAS is the same as the Enable admin security option in V7.0. Also, the Enable Java 2 security option in previous releases is the same as the Use Java 2 security to restrict application access to local resources option in V7.0.


Other Runtime resources

Other WAS run-time resources are protected by a similar mechanism, as described previously. It is very important to enable WAS administrative security and to use Java 2 security to restrict application access to local resources. Java EE Specification defines several authentication methods for Web components: HTTP Basic Authentication, Form-Based Authentication, and HTTPS Client Certificate Authentication. When you use 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 automatically redirects the browser to the HTTPS port. The CSIv2 security protocol also supports client certificate authentication. We can also use SSL client authentication to set up secure communication among a selected set of servers based on a trust relationship.

If we start from the WAS plug-in at the Web server, we can configure SSL mutual authentication between it and the WAS HTTPS server. When using a certificate, we can restrict the WAS plug-in to communicate with only the selected two appservers as shown in the following figure. Note that we can use self-signed certificates to reduce administration and cost.

For example, you want to restrict the HTTPS server in A and in B to accept secure socket connections only from the WAS plug-in W.

Set the HTTPS server of B to use certificate B and to trust certificate W.

The trust relationship that is depicted in the previous figure is shown in the following table.

Server Key Trust
WAS plug-in W A, B

The WAS Deployment Manager is a central point of administration. System management commands are sent from the dmgr to each individual application server. When admin security is enabled, we can configure WASs to require SSL and mutual authentication.

We might want to restrict A so that it can communicate with C only and B can communicate with D only.

All WASs must be able to communicate with WAS dmgr E; therefore, when using self-signed certificates, we might configure the CSIv2 and SOAP/HTTPS Key and trust relationship, as shown in the following table.

Table 4. CSIv2 and SOAP/HTTPS Key and trust relationships from example

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

When WAS is configured to use LDAP user registry, you also can configure SSL with mutual authentication between every appserver and the LDAP server with self-signed certificates so that a password is not visible when it is passed from WAS to the LDAP server.

In this example, the node agent processes are not discussed. Each node agent must communicate with appservers on the same node and with the deployment manager. Node agents also must communicate with LDAP servers when configured to use an LDAP user registry. It is reasonable to let the dmgr and the node agents use the same certificate. Suppose appserver 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 store.

WAS does not provide a registry configuration or management utility. In addition, it does not dictate the registry password policy. IBM recommends that you use the password policy recommended by the registry, including the password length and expiration period. Before securing the WAS environment, determine which versions of WAS we are using, review the WAS security architecture, and review each of the following topics: