165 lines
17 KiB
HTML
165 lines
17 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>Overview of WebSphere security</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h2><a name="template"></a>Overview of WebSphere security</h2>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server -Express security is built on a layered security architecture, as shown in the figure below. This topic discusses the security protection offered by each security layer. The following figure
|
||
|
|
illustrates the building blocks that comprise the operating environment of WebSphere Security:</p>
|
||
|
|
|
||
|
|
<p><img src="rzamy509.gif" width="550" height="424" alt="WebSphere security operating environment"></p>
|
||
|
|
|
||
|
|
<p>The building blocks of WebSphere security are these:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><p><strong>Operating System Security</strong>
|
||
|
|
<br>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.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>Network Security</strong>
|
||
|
|
<br>The Network Security layers provides transport level authentication as well as message integrity and encryption. WebSphere Application Server - Express 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.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>JVM 1.3.1</strong>
|
||
|
|
<br>The Java virtual machine security model provides a layer of security above the operating system layer.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>Java 2 Security</strong>
|
||
|
|
<br>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.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>CORBA Security</strong>
|
||
|
|
<br>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. WebSphere Application Server - Express also supports the Secure Association Service (SAS) security protocol.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>J2EE Security</strong>
|
||
|
|
<br>The security collaborator enforces J2EE-based security policies and supports J2EE security APIs.</p></li>
|
||
|
|
|
||
|
|
<li><p><strong>WebSphere Security</strong>
|
||
|
|
<br>WebSphere security enforces security policies and services in a unified manner on access to Web resources and Java Management Extensions (JMX) administrative resources. It consists of WebSphere security technologies and features to support the needs of a secure environment.</p></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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 through the WebSphere administrative console. Hence, the administrative console Web application is setup with data constraints that require the administrative console servlets and JSP files to be accessed only through SSL connections when global security is enabled. </p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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 - Express administrative subsystem uses SOAP JMX connectors or RMI/IIOP JMX connectors to pass administrative commands and configuration data.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>Security for J2EE resources is provided by the Web container. The container provides two kinds of security: <strong>declarative security</strong> and <strong>programmatic security</strong>.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p>Servlets and JSP pages may use the HttpServletRequest methods isUserInRole() and getUserPrincipal().</p>
|
||
|
|
|
||
|
|
<p>IBM has applied security role based access control concepts to the administrative resources of WebSphere Application Server - Express. These resources include the JMX system management subsystem, the user registry, and the JNDI name space. WebSphere administrative subsystem defines four administrative security roles:</p>
|
||
|
|
<ul>
|
||
|
|
<li><strong>Monitor role</strong>, which can view configuration information and status but not anything more.</li>
|
||
|
|
<li><strong>Operator role</strong>, which is a monitor that can trigger runtime state changes, such as start an application server or stop an application, but cannot change configuration.</li>
|
||
|
|
<li><strong>Configurator role</strong>, which is a monitor that can modify configuration information but cannot change runtime state.</li>
|
||
|
|
<li><strong>Administrator role</strong>, which is an operator as well as a configurator.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>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 - Express server identity and password, LTPA password and keys, and assigning users to administrative security roles. Those sensitive configuration tasks require the administrative role.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express administrative security is enforced when global security is enabled. It is recommended that WebSphere Application Server - Express global security be enabled to protect administrative subsystem integrity. Application server security can be selectively disabled if there is no sensitive information to protect.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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 components should have. These security permissions are shown in the tables below.</p>
|
||
|
|
|
||
|
|
<p><strong>J2EE Security Permissions set for Web components</strong></p>
|
||
|
|
|
||
|
|
<table border="1" cellpadding="3">
|
||
|
|
<tr>
|
||
|
|
<th>Security Permission</th>
|
||
|
|
<th>Target</th>
|
||
|
|
<th>Action</th>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>java.lang.RuntimePermission </td>
|
||
|
|
<td>loadLibrary</td>
|
||
|
|
<td> </td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>java.lang.RuntimePermission </td>
|
||
|
|
<td>queuePrintJob</td>
|
||
|
|
<td> </td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>java.net.SocketPermission </td>
|
||
|
|
<td>* </td>
|
||
|
|
<td>connect</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>java.io.FilePermission </td>
|
||
|
|
<td>*</td>
|
||
|
|
<td>read, write</td>
|
||
|
|
</tr>
|
||
|
|
|
||
|
|
<tr>
|
||
|
|
<td>java.util.PropertyPermission </td>
|
||
|
|
<td>*</td>
|
||
|
|
<td> read</td>
|
||
|
|
</tr>
|
||
|
|
</table>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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 - Express 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 - Express 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).</p>
|
||
|
|
|
||
|
|
<p>To simplify policy management, WebSphere Application Server - Express 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:</p>
|
||
|
|
<ul>
|
||
|
|
<li>spi.policy, which is for embedded resources defined in resources.xml, such as JavaMail and JDBC drivers.</li>
|
||
|
|
<li>library.policy, which is for shared libraries that are defined by the administrative console.</li>
|
||
|
|
<li>app.policy, which is the default policy for J2EE applications</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>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 - Express 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.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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 offending application installation to fail.</p>
|
||
|
|
|
||
|
|
<p>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 - Express application server. The filtering policy is defined by the filterMask element in the filter.policy file.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express 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.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express supports Java 2 Security as part of its security implementation. However, when trusted applications are being deployed, Java 2 Security can be disabled for the application server.</p>
|
||
|
|
|
||
|
|
<p>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:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>When Java 2 Security is enforced, application code cannot access the WebSphere Application Server - Express runtime classes that manage the configuration data unless the application code has been granted the required WebSphere Application Server - Express runtime permissions.</li>
|
||
|
|
|
||
|
|
<li>When Java 2 Security is enforced, application code cannot access the WebSphere Application Server - Express configuration XML files unless it has been granted the required file read and write permissions. </li>
|
||
|
|
|
||
|
|
<li>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 - Express configuration, provided that the application program has presented valid authentication data and that the security identity has the required security roles. </li>
|
||
|
|
|
||
|
|
<li>If a user is allowed to disable Java 2 Security, then that user can modify WebSphere Application Server - Express configuration including the WebSphere Application Server - Express security identity and authentication data. Hence, only users with the administrator security role are allowed to disable Java 2 Security. </li>
|
||
|
|
|
||
|
|
<li>Because WebSphere Application Server - Express 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.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>Other WebSphere Application Server - Express runtime resources are protected by similar mechanisms. It is very important to enable WebSphere Application Server - Express global security and to enforce Java 2 Security. The J2EE specification defines several authentication methods for Web components. WebSphere Application Server - Express supports HTTP basic authentication, form-based authentication, and HTTPS client certificate authentication. <strong>HTTPS</strong> means that the HTTP protocol is performed using an SSL connection. In an SSL connection, the server always presents a certificate to the client during an authentication handshake. With HTTPS client certificate authentication, the authentication handshake requires an additional step where the client also presents a certificate to authenticate itself to the server. This is also known as mutual authentication.</p>
|
||
|
|
|
||
|
|
<p>When using client certificate login, it is more convenient for the browser client if the Web resources are configured with an integral or confidential data constraint. If a browser uses HTTP to access the Web resource, the Web container automatically redirects it to the HTTPS port. The CSIv2 security protocol also supports client certificate authentication. You can establish a trust relationship between an HTTP server and a WebSphere Application Server - Express server by configuring an SSL connection with mutual authentication.</p>
|
||
|
|
|
||
|
|
<p>WebSphere Application Server - Express supplies a plug-in module that can be used by the IBM HTTP Server (powered by Apache), or by the Domino HTTP Server. The plug-in forwards client HTTP and HTTPS requests on to the WebSphere Application Server - Express server. The transport on which these requests and replies are exchanged can be configured to use SSL for additional protection. The configuration can specify that the plug-in also needs to provide a certificate to authenticate itself to the WebSpehere Application Server - Express server.</p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|