Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Overview and new features: Securing
Security planning overview
Security overview
| WebSphere security | Enforce security policies and services on Web resources, enterprise beans, and JMX administrative resources. |
| Java EE security API | The security collaborator enforces Java EE-based security policies and supports Java EE security APIs. |
| EJB security using CSIv2 | Message protection, interoperable authentication, and delegation. Layers include base transport security, supplemental client authentication, and security attribute. WAS for z/OS supports CSIv2, conformance level 0. |
| Java 2 security | Fine-grained access control file system, system property, socket connection, threading, class loading. Application code must explicitly grant the required permission to access a protected resource. |
| JVM 5.0 | Security above the OS. Protects the memory from unrestricted access, creates exceptions when errors occur within a thread, and defines array types. |
| Operating system security | The OS identity of the servant, controller, and daemon Started Task, as established by the STARTED profile, is the identity used to access files or sockets. OS security also provides authentication services using the local OS user registry and SAF Authorization. |
| Network security | Transport level authentication and message integrity and confidentiality between appservers using SSL, IP Security, and VPN. |
WAS ND installation
WAS configuration data is stored in XML descriptor files, which are protected by OS security. We can encrypt passwords stored in these files.
When administrative security is enabled, the admin console web application will require SSL connections for access.
Administrative security
The WAS administrative subsystem uses...
If administrative security is disabled, the SOAP JMX connector uses HTTP and the RMI/IIOP connector uses the TCP/IP protocol. When disabled, the former uses HTTPS and the latter uses either SSL or TCP/IP.
You can disable application security per appserver by, at the server level, clearing the option...
-
Enable administrative security
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. WAS 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 administrative security 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.
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 Secure web applications using an assembly tool, and Secure enterprise bean applications.
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:
WAS defines two additional roles that are available when you use wsadmin scripting only.
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 administrative security is enabled, including modifying a WAS 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 WAS 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 Authorizing access to administrative roles and Assign users and groups to roles.
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 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 |
The WAS Java 2 security default policies are based on the Java EE Version 1.4 specification. The specification grants web components read and write file access permission to any file in the file system, which might be too broad. The WAS default policy gives web components read and write permission to the subdirectory and the subtree where the web module is installed. The default Java 2 security policies for all Java virtual machines and WAS processes are contained in the following policy files:
To simplify policy management, WAS policy is based on resource type rather than code base (location). The following files are the default policy files for a WAS subsystem. These policy files, which are an extension of the WAS runtime, are referred to as Service Provider Programming Interfaces (SPI), and shared by multiple Java EE applications:
- $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 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 console.
- $PROFILE_ROOT/config/cells/cell_name/nodes/node_name/app.policy
This file is used as the default policy for Java EE applications.
In general, applications do not require more permissions to run than those recommended by the Java EE specification to be portable among various application servers. However, some applications might require more permissions. WAS supports the packaging of a was.policy file with each application to grant extra permissions to that application.
Attention: Grant extra permissions to an application only after careful consideration because of the potential of compromising the system integrity.
Load libraries into WAS does allow applications to leave the Java sandbox. WAS uses a permission filtering policy file to alert you when an application installation fails because of additional permission requirements. For example, IBM recommends 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 the $PROFILE_ROOT/config/cells/cell_name/filter.policy file. 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 quickly migrate those applications to the latest version of WAS, 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 Migrate Java 2 security policy.
The WAS 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 WAS run-time resources and can potentially cause damage to both. In cases where an application can be trusted as safe, WAS does support having Java 2 security disabled on a per application server basis. We can enforce Java 2 security by default in the admin console and clear the Java 2 security flag to disable it at the particular application server.
When you specify the Enable administrative security and Use Java 2 security to restrict application access to local resources options on the Global security panel of the admin console, the information and 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.
Attention: The Enable global security option in previous releases of is the same as the Enable administrative security option in v8.0. Also, the Enable Java 2 security option in previous releases is the same as the Use Java 2 security to restrict application access to local resources option in v8.0.
- When Java 2 security is enforced, the application code cannot access the WAS run-time classes that manage the configuration data unless the code is granted the required WAS run-time permissions.
- When Java 2 security is enforced, application code cannot access the WAS 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 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, the user can also modify the WAS configuration, including the WAS security identity and authentication data 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 administrative security, change server IDs and passwords, and 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 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. 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, you can configure SSL mutual authentication between it and the WAS HTTPS server. When using a certificate, you can restrict the WAS plug-in to communicate with only the selected two WASs as shown in the following figure. Note that you can use self-signed certificates to reduce administration and cost.
For example, 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.
- 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 WAS A to use certificate A and to trust certificate W.
Configure the HTTPS server of WAS B to use certificate B and to trust certificate W.
| Server | Key | Trust |
|---|---|---|
| WAS plug-in | W | A, B |
| WAS A | A | W |
| WAS B | B | W |
The WAS Deployment Manager is a central point of administration. System management commands are sent from the dmgr to each individual application server. When administrative security is enabled, you can configure WASs to require SSL and mutual authentication.
You might want to restrict WAS A so that it can communicate with WAS C only and WAS B can communicate with WAS D only. All WASs must be able to communicate with WAS dmgr 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 A | A | C, E |
| WAS B | B | D, E |
| WAS C | C | A, E |
| WAS D | D | B, E |
| WAS Deployment Manager E | E | A, B, C, D |
When WAS is configured to use 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 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 dmgr. Node agents also must communicate with LDAP servers when configured to use an LDAP user registry. It is reasonable to let the dmgr 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 registry configuration or management utility. In addition, it does not dictate the registry password policy. IBM recommends that you use the password policy recommended by your registry, including the password length and expiration period.
Topics
- Server and administrative security
- Authentication protocol support
- CSIv2
- Identity assertion to downstream server
- Authentication mechanism
- Select a registry
- Java 2 security
- JAAS
- Java EE connector security
- Access control exception for Java 2 security
- Custom authentication provider using JASPI
Related
Overview and new features for securing applications and their environmentMigrate Java 2 security policy
Authorizing access to administrative roles
Assign users to naming roles