Before you begin
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. WebSphere Application Server security is built on a layered security architecture as shown in the following figure. 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:
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.
Each product application server consists of a Web container, an Enterprise Java Beans (EJB) container, and the administrative subsystem.
The administrative console is a special J2EE 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 Protecting plain text passwords.
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 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 you 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.
Global and administrative security:
WebSphere Application Servers interact with each other through CSIv2 and Secure Authentication Services (SAS) security protocols as well as the HTTP and HTTPS protocols.
You can configure these protocols to use Secure Sockets Layer (SSL) when you enable WebSphere Application Server global security. The WebSphere Application Server administrative subsystem in every server uses Simple Object Access Protocol (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 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 always uses the HTTPS protocol. When global security 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 global security and enable SSL to protect the sensitive configuration data.
When global security is enabled, you 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. Disabling 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. For more information, see Configuring server security.
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 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 J2EE platform. WebSphere Application Server maintains J2EE 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 run time, 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 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 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 global security is enabled and application server 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 J2EE role-based access control to protect valuable business data from access by unauthorized users through the Internet and the intranet. Refer to Securing Web applications using an assembly tool, and Securing enterprise bean applications.
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 global security 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.
WebSphere Application Server administrative security is enforced when global security is enabled. Enable WebSphere Application Server global 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 Assigning users to administrator roles and Assigning users and groups to roles.
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 J2EE Version 1.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 |
Security Permission | Target | Action |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | connect |
java.util.PropertyPermission | * | read |
Loading libraries into the 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 ${WAS_INSTALL_ROOT}/profiles/profile_name/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 migrate those applications to WebSphere Application Server Version 6.0.x quickly, you might temporarily give those applications the java.security.AllPermission permission in the was.policy file. Test those applications to ensure that they execute 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 to WebSphere Application Server Version 6.0.x, refer to Migrating Java 2 security policy.
The WebSphere Application Server run time 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 security center and clear the Java 2 security flag to disable it at the particular application server.
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 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. You can also use SSL client authentication to set up secure communication among a selected set of servers based on a trust relationship.
For example, 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. 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. Configure the HTTPS server of WebSphere Application Server B to use certificate B and to trust certificate W. For more information on IKEYMAN, refer to Starting the key management utility (iKeyman).
Server | Key | Trust |
---|---|---|
WebSphere Application Server plug-in | W | A, B |
WebSphere Application Server A | A | W |
WebSphere Application Server B | B | W |
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.
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.
Steps for this task
Related tasks
Migrating Java 2 security policy
Assigning users to administrator roles
Assigning users to naming roles