Plan to secure your environment

 

+

Search Tips   |   Advanced Search

 

Overview

When you access information on the Internet, you connect through Web servers and product servers to the enterprise data at the back end. This section examines some typical configurations and common security practices. WAS (WAS) security is built on a layered security architecture. This section also examines the security protection that is 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 operating system provides certain security services for WAS. These services include the file system security support that secures sensitive files in the product installation for WAS. The system administrator can configure the product to obtain authentication information directly from the operating system user registry.
Network Security The Network Security layers provide transport level authentication and message integrity and confidentiality. One can configure the communication between separate application servers to use SSL. Additionally, use IP Security and VPN for added message protection.
JVM 1.4 The JVM security model provides a layer of security above the operating system 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.
OMG CSIv2 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. For backward compatibility, WAS supports the SAS security protocol, which was used in prior releases of WAS and other IBM products.
J2EE Security The security collaborator enforces J2EE-based security policies and supports J2EE security APIs.
WebSphere Security WAS security enforces security policies and services in a unified manner on access to Web resources, enterprise beans, and JMX administrative resources. It consists of WAS security technologies and features to support the needs of a secure enterprise environment.

Each product application server consists of a Web container, an EJB container, and the administrative subsystem.

The WAS deployment manager contains only WebSphere administrative code and the administrative console.

The administrative console is a special J2EE Web application 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 administrative console. However, protect these passwords and sensitive data. For more information, see Protecting plain text passwords.

The administrative console Web application 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 DummyServerKeyFile.jks and DummyServerTrustFile.jks with the default self-signed certificate. Using the dummy key and trust store certificate is not safe and we need to 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. Figure 1. Multiple-tier business computing environment.

 

Global and administrative security:

Application servers interact with each other through CSIv2 and SAS security protocols as well as the HTTP and HTTPS protocols.

One can configure these protocols to use SSL when you enable WAS global security. The WAS administrative subsystem in every server uses SOAP JMX connectors and Remote Method Invocation over the RMI/IIOP JMX connectors to pass administrative commands and configuration data.

When global security is disabled, the SOAP JMX connector uses the HTTP protocol and the RMI/IIOP connector uses the TCP/IP protocol.

When global security is enabled, the SOAP JMX connector uses the HTTPS protocol. and one can configure the RMI/IIOP JMX connector to either use SSL or to use TCP/IP. It is recommended that you enable global security and enable SSL to protect the sensitive configuration data.

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

When global security is enabled, one can disable application security at each individual application server by clearing the Enable global security option on the global security panel. The global security panel is accessed through the administrative console by clicking...

Security > Global security

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

 

 

Security for J2EE resources

Security for J2EE resources is provided by the Web container and the EJB container. Each container provides two kinds of security:

 

 

Declarative security

The deployment descriptor is the primary vehicle for declarative security in the J2EE platform. 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 that is defined in the XML descriptor files to enforce data constraints and access control.

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.

When declarative security alone is not sufficient to express the security model of an application, you might use Programmatic login to make access decisions. When global security is enabled and application server security is not disabled at the server level, J2EE 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 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 it has one of the required security roles. Servlets and JSP pages can use the HttpServletRequest methods isUserInRole and getUserPrincipal.

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

The authentication takes place 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 J2EE role-based access control to protect valuable business data from access by unauthorized users from both the Internet and the intranet.

 

 

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 administrative subsystem defines four administrative 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 application server 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 run time.

Administrator role

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

A user with the configurator role can perform most administrative work including installing new applications and application servers. There are certain configuration tasks a configurator does not have sufficient authority to do when global security is enabled, including modifying a WAS 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.

WAS 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.

 

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 J2EE V1.4 specification 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.

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

J2EE V1.4 default policies grant Web components read and write file access permissions to any file in the file system.

The WAS default policy gives Web components read and write permission to the subdirectory and the subtree where the Web module is installed.

Java 2 security policies for all JVM and WAS processes are contained in...

${java.home}/jre/lib/security/java.policy

Default policy for JVM processes.

${USER_INSTALL_ROOT}/properties/server.policy

Default policy for WAS processes

WAS policy is based on resource type rather than code base (location).

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

${WAS_INSTALL_ROOT}/profiles/profile/config/cells/cell/nodes/node/spi.policy

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

${WAS_INSTALL_ROOT}/profiles/profile/config/cells/cell/nodes/node/library.policy

Used by the shared library that is defined by the WAS administrative console.

${WAS_INSTALL_ROOT}/profiles/profile/config/cells/cell/nodes/node/app.policy

The default policy for J2EE applications.

In general, applications should not require more permissions to run than those recommended by the J2EE specification to be portable among various application servers. However, some applications might require more permissions. WAS supports a per application policy file, was.policy, to be packaged together with each application from granting extra permissions to that application. Attention: Grant extra permissions to an application after careful consideration because of the potential of compromising the system integrity.

Loading libraries into the WAS does allow applications to leave the Java sandbox. When you install an application for WAS, the server uses a permission filtering policy file to alert you when an application requires additional permissions and causes the affected application installation to fail. For example, it is recommended 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...

${WAS_INSTALL_ROOT}/profiles/profile/config/cells/cell/filter.policy

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 migrate those applications to WAS V6.0.x, temporarily give those applications java.security.AllPermission in was.policy. It is recommended that you test those applications to ensure that they execute in an environment where Java 2 Security is active. For example, identity what extra permissions, if any, are required, and to grant only those permissions to a particular application. Not granting applications AllPermission can certainly reduce the risk of compromising system integrity.

The WAS run time uses Java 2 Security to protect sensitive run-time functions; therefore, it is recommended that you enforce Java 2 security. Applications that are granted AllPermission 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 to be safe, WAS allows Java 2 Security to be disabled on a per application server basis. We can enforce Java 2 security by default in the security center and disable the per application server Java 2 Security flag to disable it at the particular application server.

When you specify the Enable global security and Enable Java 2 Security options on the Global security panel of the administrative console, the information, 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. The example uses configuration data protection to illustrate how system integrity is maintained.

  • When Java 2 security is enforced, the application code cannot access the WAS run-time classes that manage the configuration data unless it is granted the required WAS run-time permissions.

  • When Java 2 security is enforced, application code cannot access the WAS configuration XML files unless it has been granted the required file read and write permission.

  • The JMX administrative subsystem provides SOAP over HTTP or HTTPS and RMI/IIOP remote interface to enable application programs to extract and to modify configuration files and data. When global security is enabled, an application program can modify the WAS configuration if the application program has presented valid authentication data and the security identity has the required security roles.

  • If a user can disable Java 2 security, then that user can modify the WAS configuration including the WAS security identity and authentication data along with other sensitive data. Only users with the administrator security role can disable Java 2 security.

  • Because WAS security identity is given to the administrator role, only users with the administrator role can disable global security, to change server ID and password, and to map users and groups to administrative roles, and so on.

  • Only users with administrator role can disable global security, change server ID and password, map users and groups to administrative roles, and so on.

 

Other Runtime resources

Other WAS run time resources are protected by a similar mechanism as described previously. It is very important to enable WAS global security and to enforce Java 2 Security. J2EE 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 you start from the WAS plug-in at the Web server, one can configure SSL mutual authentication 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 following figure. Suppose you want to restrict the HTTPS server in WAS A and in WAS B to accept secure socket connections only from the WAS plug-in W. We can generate three self-signed certificates using the IKEYMAN and the certificate management utilities. 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. For more information on IKEYMAN, refer to Starting the key management utility (iKeyman).

If you start from the WAS plug-in at the Web server, SSL mutual authentication can be configured between it and the WAS HTTPS server. When using self signed certificates, one can restrict the WAS plug-in to communicate with only the selected two WAS servers as shown in the following picture. Suppose you want to restrict the HTTPS server in WAS A and in WAS B to accept secure socket connections only from WAS plug-in W.

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

Server Key Trust
WAS plug-in W A, B
WAS A A W
WAS 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 application server. When global security is enabled, we can configure the application servers to require SSL and mutual authentication. Suppose you want to further restrict WAS A so that it can communicate with WAS C only and WAS B can communicate with WAS D only. Attention: As mentioned previously, all application servers must be able to communicate with WAS Deployment Manager E; therefore, 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, you also can configure SSL with mutual authentication between every application server and the LDAP server with self-signed certificates so that a password is not passed in clear text from WAS to the LDAP server.

In this example, the node agent processes are not discussed. Each node agent must communicate with application servers on the same node and with the Deployment Manager. Node agents also must communicate with LDAP servers when they are configured to use an 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 store.

WAS 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.

 

Procedure

  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


Security considerations when adding a Base Application Server node to Network Deployment
Creating login key files
Preparing truststore files
Configuring the application server for interoperability

 

See Also


Programmatic login

 

Related Tasks


Assigning users to administrator roles
Assigning users to naming roles