Security planning 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.
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. The following figure illustrates the building blocks that comprise the operating environment for security within WebSphere® Application Server:
- WebSphere Application Server security
- WebSphere security
- WebSphere Application Server 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 Application Server security technologies and features to support the needs of a secure enterprise environment.
- Java security
- Java Platform, Enterprise Edition (Java EE) security application programming interface (API)
- The security collaborator enforces Java Platform, Enterprise Edition (Java EE)-based security policies and supports Java EE security APIs.
- EJB security using Common Secure Interoperability Protocol Version 2 (CSIv2)
- Common Secure Interoperability Version 2 (CSIv2) is an IIOP-based, three-tiered, security protocol that is developed by the Object Management Group (OMG). This protocol provides message protection, interoperable authentication, and delegation. The three layers include a base transport security layer, a supplemental client authentication layer, and a security attribute layer. WebSphere Application Server for z/OS® supports CSIv2, conformance level 0.
- 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.
- Java Virtual Machine (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, and defines array types.
- Platform security
Operating system security
The security infrastructure of the underlying operating system provides certain security services for WebSphere Application Server. These services include the file system security support that secures sensitive files in the product installation for WebSphere Application Server. The system administrator can configure the product to obtain authentication information directly from the operating system user registry.
Operating system security
The security infrastructure of the underlying operating system provides certain security services for WebSphere Application Server. The operating system identity of the servant, controller, and daemon Started Task, as established by the STARTED profile, is the identity that is 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 application server.
In addition to knowledge of Secure Sockets Layer (SSL) and Transport Layer Security (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. You can configure the communication between separate application servers to use Secure Sockets Layer (SSL). Additionally, you can use IP Security and Virtual Private Network (VPN) for added message protection.
Each product application server consists of a web container, an Enterprise Java Beans (EJB) container, and the administrative subsystem.
The WebSphere Application Server deployment manager contains only WebSphere Application Server administrative code and the administrative console.
The administrative console is a special Java EE web application that provides the interface for performing administrative functions. WebSphere Application Server 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, you must protect these passwords and sensitive data. For more information, see 在文件中对密码进行编码.
The administrative console web application has a setup data constraint that requires access to the administrative console servlets and JavaServer Pages (JSP) files only through an SSL connection when 管理安全性 is enabled.
In WebSphere Application Server Version 6.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 WebSphere Application Server installation;
the keys are common in all of the installation and are therefore insecure. WebSphere Application Server 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. WebSphere Application Server Version 6.1 also
enables integration with external certificate (CA) authority to use
CA-issued certificates. The WebSphere Application Servers Version 6.1 installation
process provides an option to enable administrative security during
installation. As a result, a WebSphere Application Server process is secured
immediately after installation. WebSphere Application Server Version 7.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 (you can import your 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.
The following figure shows a typical
multiple-tier business computing environment.
Administrative security
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
You can configure these protocols to use Secure Sockets Layer (SSL) when you enable WebSphere Application Server 管理安全性. The WebSphere Application Server administrative subsystem in every server uses SOAP, Java Management Extensions (JMX) connectors and Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) JMX connectors to pass administrative commands and configuration data. When 管理安全性 is disabled, the SOAP JMX connector uses the HTTP protocol and the RMI/IIOP connector uses the TCP/IP protocol. When 管理安全性 is enabled, the SOAP JMX connector always uses the HTTPS protocol. When 管理安全性 is enabled, you can configure the RMI/IIOP JMX connector to either use SSL or to use TCP/IP. It is recommended that you enable 管理安全性 and enable SSL to protect the sensitive configuration data.
You can enable HTTPS for applications even when 管理安全性 is disabled. You can
configure the SSL port for a particular server by adding the SSL port
to the HTTP port list in the server web container, in addition to
where it is added to the virtual hosts in the Environment configuration.
You can connect to the web application using HTTPS and the correct
port. Internal WebSphere Application Server for z/OS communication does not use
SSL unless you enable 管理安全性.
When administrative security is enabled, you can disable application security at each individual application server by clearing the Enable administrative security option at the server level. For more information, see 保护特定应用程序服务器. Disabling application server security does not affect the administrative subsystem in that application server, which is controlled by the security configuration only. Both administrative subsystem and application code in an application server 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. WebSphere Application Server 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, you might use programmatic security to make access decisions. When 管理安全性 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 JSP files 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.
When cell-level security is enabled, unless server
security is 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 使用组装工具保护 Web 应用程序, and 保护企业 Bean 应用程序.
Role-based security
- 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 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 管理安全性 and Java 2 security, and map users and groups to the administrator role.
- iscadmins
- The iscadmins role has administrator privileges for managing users and groups from within the administrative console only.
- Deployer
- A deployer can perform both configuration actions and run-time operations on applications.
- Adminsecuritymanager
- An administrative security manager can map users to administrative roles. Also, when fine grained admin security is used, users granted this role can manage authorization groups.
- Auditor
- An auditor can view and modify the configuration settings for the security auditing subsystem.
A user with the configurator role can perform most administrative work including installing new applications and application servers. Certain configuration tasks exist that a configurator does not have sufficient authority to do when 管理安全性 is enabled, including modifying a WebSphere Application Server identity and password, Lightweight Third-Party Authentication (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.
Enable WebSphere Application Server administrative security to protect administrative subsystem integrity. Application server security can be selectively disabled if no sensitive information is available to protect. For securing administrative security, refer to 授予管理角色访问权 and 为用户和组指定角色.
Java 2 security permissions
WebSphere Application Server 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 Version 1.4 specification defines a typical set of Java 2 security permissions that web and EJB components expect to have.
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 |
Security Permission | Target | Action |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connect |
java.util.PropertyPermission | * | read |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
Used as the default policy for the Java virtual machine (JVM).
${java.home}/jre/lib/security/java.policy
This file is used as the default policy for the Java virtual machine (JVM).
${USER_INSTALL_ROOT}/properties/server.policy
This file is used as the default policy for all product server processes.
$WAS_HOME/properties/server.policy
This file is used as the default policy for all product server processes.
To simplify policy management, WebSphere Application Server policy is based on resource type rather than code base (location). The following files are the default policy files for a WebSphere Application Server subsystem. These policy files, which are an extension of the WebSphere Application Server runtime, are referred to as Service Provider Programming Interfaces (SPI), and shared by multiple Java EE applications:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- profile_root/config/cells/cell_name/nodes/node_name/spi.policy
This file is used for embedded resources defined in the resources.xml file, such as the Java Message Service (JMS), JavaMail, and JDBC drivers.
- profile_root/config/cells/cell_name/nodes/node_name/library.policy
This file is used by the shared library that is defined by the WebSphere Application Server administrative console.
- profile_root/config/cells/cell_name/nodes/node_name/app.policy
This file is used as the default policy for Java EE applications.
![[z/OS]](../images/ngzos.gif)
- $WAS_HOME/config/cells/cell_name/nodes/node_name/spi.policy
This file is used for embedded resources that are defined in the resources.xml file, such as the Java Message Service (JMS), JavaMail API, and JDBC drivers.
- $WAS_HOME/config/cells/cell_name/nodes/node_name/library.policy
This file is used by the shared library that is defined by the WebSphere Application Server administrative console.
- $WAS_HOME/config/cells/cell_name/nodes/node_name/app.policy
This file is used as the default policy for Java EE applications.
![[IBM i]](../images/iseries.gif)
- profile_root/config/cells/cell_name/nodes/node_name/spi.policy
Used for embedded resources defined in the resources.xml file, such as the Java Message Service (JMS), JavaMail, and JDBC drivers.
- profile_root/config/cells/cell_name/nodes/node_name/library.policy
Used by the shared library that is defined by the WebSphere Application Server administrative console.
- profile_root/config/cells/cell_name/nodes/node_name/app.policy
Used as the default policy for Java EE applications.
Loading libraries into WebSphere Application Server does allow applications to leave the Java sandbox. WebSphere Application Server uses a permission filtering policy file to alert you when an application installation fails because of additional permission requirements. For example, it is recommended that you not give the java.lang.RuntimePermission exitVM permission to an application so that application code cannot terminate WebSphere Application Server.
The filtering policy is defined by the filtermask in the profile_root/config/cells/cell_name/filter.policy file. Moreover, WebSphere Application Server 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 WebSphere Application Server might not be Java 2 security ready. To quickly migrate those applications to the latest version of WebSphere Application Server, you might temporarily give those applications the java.security.AllPermission permission in the was.policy file. Test those applications to ensure that 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. For more information on migrating applications, refer to 迁移 Java 2 安全策略.
The WebSphere Application Server 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 WebSphere Application Server run-time resources and can potentially cause damage to both. In cases where an application can be trusted as safe, WebSphere Application Server does support having Java 2 security disabled on a per application server basis. You can enforce Java 2 security by default in the administrative console and clear the Java 2 security flag to disable it at the particular application server.
- When Java 2 security is enforced, the application code cannot access the WebSphere Application Server run-time classes that manage the configuration data unless the code is granted the required WebSphere Application Server run-time permissions.
- When Java 2 security is enforced, application code cannot access the WebSphere Application Server configuration XML files unless the code is granted the required file read and write permission.
- The JMX administrative subsystem provides SOAP over HTTP or HTTPS and a RMI/IIOP remote interface to enable application programs to extract and to modify configuration files and data. When administrative security is enabled, an application program can modify the WebSphere Application Server 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, the user can also modify the WebSphere Application Server configuration, including the WebSphere Application Server security identity and authentication data with other sensitive data. Only users with the administrator security role can disable Java 2 security.
- Because WebSphere Application Server security identity is given to the administrator role, only users with the administrator role can disable 管理安全性, change server IDs and passwords, and map users and groups to administrative roles, and so on.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Other Runtime resources
Other WebSphere Application Server run-time resources are protected by a similar mechanism, as described previously. It is very important to enable WebSphere Application Server 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. You can also use SSL client authentication to set up secure communication among a selected set of servers based on a trust relationship.
The CSIv2 security protocol
also supports client certificate authentication. SSL client authentication
can also be used to set up secure communication among a selected set
of servers based on a trust relationship.

To complete this task, you can generate three certificates using the IKEYMAN and the certificate management utilities. Also, you can use certificate W and trust certificate A and B. Configure the HTTPS server of WebSphere Application Server A to use certificate A and to trust certificate W.
To complete this task, you can generate three certificates using Resource Access Control Facility (RACF) called certificate W, A, and B. Configure the WebSphere Application Server plug-in to use certificate W and trust certificate A and B. Configure the HTTPS server of WebSphere Application Server A to use certificate A and to trust certificate W.
Server | Key | Trust |
---|---|---|
WebSphere Application Server plug-in | W | A, B |
WebSphere Application Server A | A | W |
WebSphere Application Server B | B | W |
The WebSphere Application Server Deployment Manager is a central point of administration. System management commands are sent from the deployment manager to each individual application server. When 管理安全性 is enabled, you can configure WebSphere Application Server to require SSL and mutual authentication.
Server | Key | Trust |
---|---|---|
WebSphere Application Server A | A | C, E |
WebSphere Application Server B | B | D, E |
WebSphere Application Server C | C | A, E |
WebSphere Application Server D | D | B, E |
WebSphere Application Server Deployment Manager E | E | A, B, C, D |
When WebSphere Application Server is configured to use Lightweight Directory Access Protocol (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 visible when it is passed from WebSphere Application Server 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 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.
WebSphere Application Server does not provide
a registry configuration or management utility. In addition, it does
not dictate the registry password policy. It is recommended that you
use the password policy recommended by your registry, including the
password length and expiration period.