WAS: Plan to secure your environment
Overview
WebSphere Application Server security is built on a layered security architecture...
Building blocks include...
- Operating System Security
The security infrastructure of the underlying operating system provides certain security services to the WebSphere Security Application. This includes the file system security support to secure sensitive files in WebSphere product installation. You can configure the product to obtain authentication information directly from the operating system user registry. - Network Security
The Network Security layers provides transport level authentication as well as message integrity and encryption. WebSphere Application Server inter-server communications can be configured to use Secure Socket Layer (SSL) and HTTPS. Additionally, IP Security and Virtual Private Network (VPN) may be used for added message protection. - JVM 1.3.1
The Java virtual machine 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 in order to access a protected resource. - CORBA Security
Any calls made among secure ORBs are invoked over the Common Security Interoperability Version 2 (CSIv2) security protocol, which 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. WebSphere Application Server supports the Secure Association Service (SAS) security protocol. - 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 Java Management Extensions (JMX) administrative resources. It consists of WebSphere security technologies and features to support the needs of a secure enterprise environment.
The following figure shows a typical multiple-tier business computing environment:
This figure shows WebSphere Application Server Network Deployment installation. Note that, although not shown in the picture, there is a node agent instance on every computer node.
Each product application server consists of a Web container and an EJB container, shown in blue. The administrative subsystem is shown in gray. The WebSphere Application Server deployment manager contains only WebSphere administrative code and the administrative console application. Administrative console is a special J2EE Web Application that provides the graphical interface for performing administrative functions.
WebSphere Application Server configuration data is stored in XML descriptor files. Those XML configuration files should be protected by operating system security. Passwords and other sensitive configuration data can be modified via administrative console. Hence, the administrative console Web application has setup data constraint which requires the administrative console servlets and JSP files to be accessed only through SSL connection when global security is enabled.
After installation, the administrative console HTTPS port is configured to use the DummyServerKeyFile.jks and DummyServerTrustFile.jks with the default self-signed certificate. Using the Dummy key and trust file certificate is not safe. You should generate your own certificate immediately. To ensure maximum security, enable global security first and then complete other configuration tasks.
WebSphere Application Server servers interact with each other through CSIv2 and SAS security protocols as well as HTTP and or HTTPS protocols. CSIv2 and SAS protocols can be configured to use SSL when WebSphere Application Server global security is enabled. The WebSphere Application Server administrative subsystem uses SOAP JMX connectors 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. You should enable global security and enable SSL to protect the sensitive configuration data.
Note: Global security and administrative security configuration is at the cell level.
While global security is enabled, application security at each individual application server may be disabled by disabling per server level security enable flag. Disabling application server security does not affect the administrative subsystem in that application server. The administrative subsystem 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.
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 in a form external to the application. In particular, the deployment descriptor is the primary vehicle for declarative security in the J2EE platform. WebSphere 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 runtime, 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 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 was not disabled at the server level, J2EE applications security will be enforced. If security policy is specified for a Web resource, access control is performed by the Web container when the resource is requested by a Web client. The Web container challenges the Web client for authentication data if there is none present according to the specified authentication method. The challenge ensures that the data constraints are met, and determines if 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 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 application server security is not disabled, EJB container will enforce access control on EJB method invocation. The authentication takes place regardless of whether method permission was defined for the specific enterprise bean.
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.
Enterprise bean 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.
WebSphere extended security role based access control to administrative resources includes the JMX system management subsystem, user registry, and JNDI name space. WebSphere administrative subsystem defines four administrative security roles:
- Monitor role, which can view configuration information and status but not anything more.
- Operator role, which is a monitor that can trigger runtime state changes, such as start an application server or stop an application, but cannot change configuration.
- Configurator role, which is a monitor that can modify configuration information but cannot change runtime state.
- Administrator role, which is an operator as well as a configurator.
You can perform most administrative work including installing new applications and application servers if you have a role as a configurator. There are certain configuration tasks a configurator does not have sufficient authority to do when global security is enabled. These include modifying WebSphere Application Server server identity and password, LTPA password and keys, and assigning users to administrative security roles. Those sensitive configuration tasks require the administrative role.
WebSphere Application Server administrative security is enforced when global security is enabled. It is recommended that WebSphere Application Server global security be enabled to protect administrative subsystem integrity. Application server security can be selectively disabled if there is no sensitive information to protect.
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. J2EE 1.3 Specification defines the typical set of Java 2 security permissions that Web and enterprise bean components should have. These security permissions are shown in the tables below.
J2EE Security Permissions set for Web components
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
2EE Security Permissions set for EJB components
Security Permission Target Action java.lang.RuntimePermission queuePrintJob java.net.SocketPermission * connect java.util.PropertyPermission * read
WebSphere Application Server Java 2 Security implementation was based on the 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. WebSphere Application Server default policy gives Web components read and write permission to the subdirectory and the subtree where the Web module was installed. The default Java 2 security policy for all Java virtual machines and WebSphere Application Server server processes are contained in the java.policy file (the default policy for the Java virtual machine) and the server.policy file (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). There are default policy files for embedded resources, for libraries shared by multiple applications, and for J2EE applications:
- spi.policy, which is for embedded resources defined in resources.xml, such as JMS, JavaMail and JDBC drivers.
- library.policy, which is for shared libraries that are defined by the administrative console.
- app.policy, which is the default policy for J2EE applications
In general, applications should not require more permissions to run than those recommended by the J2EE Specification, so they can be portable among application servers. Some applications, however, may require more permissions. WebSphere Application Server allows a policy file (was.policy) for each application, which can be packaged with the application and grants 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.
WebSphere Application Server uses a permission filtering policy file to alert users when an application requires permissions that are on the filter list during application installation, and could 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 WebSphere Application Server application server. The filtering policy is defined by the filterMask element in the filter.policy file.
WebSphere Application Server also performs runtime permission filtering based on the runtime filtering policy to ensure no application code has been granted any permission that is considered harmful to system integrity. Applying the Java 2 Security model to application servers is new.
WebSphere Application Server Version 4 supports Java 2 Security, but only enforces permission checks against exitVM, and creating and configuring the Security Manager. Other permission checks are disabled by default. Hence, many applications developed for prior releases of WebSphere Application Server may not be ready for Java 2 Security.
WebSphere Application Server runtime uses Java 2 Security to protect sensitive runtime functions. It is always a good idea to enforce Java 2 Security. Applications that are granted with AllPermission have access to sensitive system resources. Also, WebSphere Application Server runtime resources and can potentially cause damage. In cases where an application can be trusted to be safe, WebSphere Application Server allows Java 2 Security to be disabled on a per application server basis.
The global security configuration and Java 2 Security configuration 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. System integrity is maintained in these ways:
- When Java 2 Security is enforced, application code cannot access the WebSphere Application Server runtime classes that manage the configuration data unless the application code has been granted the required WebSphere Application Server runtime permissions.
- When Java 2 Security is enforced, application code cannot access the WebSphere Application Server configuration XML files unless it has been granted the required file read and write permissions.
- The JMX administrative subsystem provides SOAP over HTTP(S) and RMI/IIOP remote interface to allow application programs to extract and to modify configuration files and data. When global security is enabled, an application program can modify WebSphere Application Server configuration, provided that the application program has presented valid authentication data and that the security identity has the required security roles.
- If a user is allowed to disable Java 2 Security, then that user can modify WebSphere Application Server configuration including the WebSphere Application Server security identity and authentication data. Hence, only users with the administrator security role are allowed to disable Java 2 Security.
- Because WebSphere Application Server security identity is given the administrator role, only users with administrator role are allowed to disable global security, to change server id and password, and to map users and groups to administrative roles.
Other WebSphere Application Server runtime resources are protected by similar mechanisms. It is very important to enable WebSphere Application Server global security and to enforce Java 2 Security. J2EE Specification defines four authentication methods for Web components. WebSphere Application Server 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 HTTPS port. The CSIv2 security protocol also supports client certificate authentication. SSL client authentication can be used to setup secure communication among selected set of servers based on trust relationship.
Starting from the WebSphere Application Server plug-in at the Web server, SSL mutual authentication may be configured between it and the WebSphere Application Server HTTPS server.
When using a self-signed certificate, you can restrict the WebSphere Application Server plug-in to communicate with only the selected WebSphere Application Server servers. See the figure:
Suppose you want to restrict the HTTPS server in WebSphere Application Server server A and in WebSphere Application Server B to accept secure socket connection only from WebSphere Application Server plug-in W. You can generate three self-signed certificates using the iKeyman tool and certificate management utility, certificate W, A, and B. WebSphere Application Server plug-in is configured to use certificate W and trust certificates A and B.
The HTTPS server of WebSphere Application Server A is configured to use certificate A and to trust certificate W. The HTTPS server of WebSphere Application Server B is configured to use certificate B and to trust certificate W.
The trust relationship is shown in the following table:
Server Key Trust WebSphere Application Server plug-in W A, B WebSphere Application Server Server A A W WebSphere Application Server Server B B W
In a Network Deployment installation, the WebSphere Application Server deployment manager is a central point of administration. System management commands is sent from the Deployment manager to each individual WebSphere Application Server Server. When global security is enabled, all WebSphere Application Server servers may be configured to require SSL and mutual authentication.
To further restrict that WebSphere Application Server, application A can only communicate to WebSphere Application Server application server C. WebSphere Application Server application server B can only communicate to WebSphere Application Server application server D. Note that as mentioned above, all WebSphere Application Server application servers must be able to communicate with WebSphere Application Server Deployment Manager E. Hence, when using self-signed certificates, you could setup CSIv2 and SOAP/HTTPS Key and trust relationship as shown in the following table:
Server Key Trust WebSphere Application Server Server A A C, E WebSphere Application Server Server B B D, E WebSphere Application Server Server C C A, E WebSphere Application Server Server D D B, E WebSphere Application Server Deployment Manager E E A, B, C, D
When WebSphere Application Server is configured to use an LDAP user registry, SSL with mutual authentication may also be configured between every WebSphere Application Server server and the LDAP server with self-signed certificate so that no password will be passed in clear text from WebSphere Application Server to LDAP server. In this example Node Agent processes were not discussed. Each node agent needs to communicate with application servers 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 Deployment manager and 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 user registry password policy. It is recommended to use the password policy recommended by your user registry, including the password length and expiration period.