Before you begin
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. WebSphere Application Server 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.
The
following figure illustrates the building blocks that comprise the operating
environment of WebSphere Application Server 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. The WebSphere system administrator can configure the product to obtain authentication information directly from the operating system user registry, for example the Windows system Security Access Manager (SAM).
The following picture shows a typical multiple-tier business computing environment. Shown in the picture is a WebSphere Application Server Network Deployment (ND) installation. Note that there is a Node Agent instance on every computer node which is omitted in the picture. Each product application server consists of a web container, an EJB container, and the administrative subsystem. The WebSphere Application Server 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. 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 using the administrative console.
Hence, 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 file certificate
is not safe and you should 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.
WebSphere Application Server servers interact with each other through CSIv2 and SAS security protocols as well as HTTP and or HTTPS protocols. Those protocols can be configured to use SSL when WebSphere Application Server global security is enabled. The WebSphere Application Server 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.
Global security and administrative security configuration is performed at the cell level.
While global security is enabled, application security at each individual application server 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.
For more information, see Configuring server security.
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 WebSphere Application Server 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 login can 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 challenges 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 application server 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.
For enabling J2EE application
security, please refer to Warning: no string named [tsec_secweb] found. and Securing enterprise bean applications using the Application Assembly Tool.
For enabling J2EE application
security, please refer to Securing Web applications using the Assembly Toolkit and Securing enterprise bean applications using the Assembly Toolkit.
WebSphere Application Server 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 application servers. There are certain configuration tasks a configurator does not have sufficient authority to do when global security is enabled, including modifying WebSphere Application Server server identity and password, changing 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 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. For securing administrative security, refer to Assigning users to administrator roles and Assigning users to naming roles WebSphere Application Server 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 Version 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.
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 |
WebSphere Application Server Java 2 Security implementation was based on J2EE Version 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 sub directory and the sub tree 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 following policy files:
To simplify policy management, WebSphere Application Server policy is based on resource type rather than code base (location). Default policy for WebSphere Application Server subsystem that considered as an extension of WebSphere Application Server run time, which is referred to as SPI, for library shared by multiple applications, and for J2EE applications, are:
In general, applications should not require more permissions to run than those recommended by the J2EE Specification in order to be portable among various application servers. But some applications may require more permissions. WebSphere Application Server 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.
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 cause the offended application installation to fail. For example, the java.lang.RuntimePermission exitVM permission should not be given to an application so that application code is not allowed to terminate the WebSphere Application Server. The filtering policy is defined by the filterMask in ${was.install.root}/config/cells/<cellname>/filter.policy. Moreover, WebSphere Application Server 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 application server is new.
WebSphere Application Server Version 4 supported Java 2 Security but only enforced three permissions checking against exitVM, create and set the Security Manager. Other permission checking is disabled by default.
Hence many applications developed for prior releases of WebSphere Application Server might not be Java 2 Security ready. To migrate those applications to WebSphere Application Server Version 5 quickly, you might temporarily give those applications java.security.AllPermission in the was.policy file. It is recommended to test or make those applications Java 2 Security ready, for example, 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. For more information on migrating applications to WebSphere Application Server Version 5, refer to Migrating Java 2 security policy.
WebSphere Application Server 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 WebSphere Application Server run-time resources and can potential cause damage to both. 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. 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 previously. Hence it is very important to enable WebSphere Application Server global security and to enforce Java 2 Security. J2EE Specification defines four authentication method 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 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.
If you start from the WebSphere
Application Server plug-in at the Web server, SSL mutual authentication can
be configured between it and the WebSphere Application Server HTTPS server.
When using a self- signed certificate, one can restrict the WebSphere Application
Server plug-in to communicate with only the selected two WebSphere Application
Server servers as shown in the following picture. Suppose you want to restrict
the HTTPS server in WebSphere Application Server A and in WebSphere
Application Server B to accept secure socket connections only from
the WebSphere Application Server 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 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 depicted in the previous picture is shown in the following table.
Server | Key | Trust |
WebSphere Application Server plug-in | W | A, B |
WebSphere Application Server A | A | W |
WebSphere Application Server B | B | W |
In a Network Deployment installation, 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 global security is enabled, all WebSphere Application Server servers can be configured to require SSL and mutual authentication. Suppose you want to further restrict that WebSphere Application Server A so that it can only communicate with WebSphere Application Server C and WebSphere Application Server B can only communicate with WebSphere Application Server D. Note, as mentioned previously, 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 might configure the 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 also can be configured between every application server and the LDAP server with self-signed certificate so that no password will be passed in clear text from WebSphere Application Server to the LDAP server. In this example, the 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 they are configured to use LDAP user registry. It is reasonable to let the Deployment manager and the node agents use the same certificate. Suppose application servers 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.
Why and when to perform this task
Steps for this task