76 lines
6.6 KiB
HTML
76 lines
6.6 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>Edit the web.xml file to add security settings</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h3><a name="secaweb"></a>Edit the web.xml file to add security settings</h3>
|
|
|
|
<p>There are three types Web login (authentication) mechanisms that can be configured on a Web application: basic authentication, form-based authentication, and client certificate-based authentication. Web resources in a Web application can be protected by assigning security roles to those resources. So, you need to know in advance which Web resources need protecting and how to protect them.</p>
|
|
|
|
<p>Perform these steps to secure your Web application with WebSphere Development Studio Client:</p>
|
|
|
|
<ol>
|
|
<li><p><strong>Open the web.xml file.</strong></p>
|
|
<ol type="a">
|
|
<li>Open the project that contains your Web application.</li>
|
|
|
|
<li>In the Navigator window, expand the WEB-INF directory. Double-click the web.xml file. The web.xml file is the deployment descriptor for your Web application. The deployment descriptor contains runtime security settings.</li>
|
|
</ol><p></p></li>
|
|
|
|
<li><p><strong>Create security roles.</strong></p>
|
|
<ol type="a">
|
|
<li>Click the <strong>Security</strong> tab.</li>
|
|
<li>Next to the Security Roles table, click <strong>Add</strong>.</li>
|
|
<li>Type the role name and a description of the role.</li>
|
|
<li>Repeat steps b and c to add all required security roles.</li>
|
|
</ol><p></p></li>
|
|
|
|
<li><p><strong>Create security constraints.</strong>
|
|
<br>Security constraints are a mapping of one or more Web resources to a set of roles. To create security constraints, follow these steps:</p>
|
|
<ol type="a">
|
|
<li>Under the Security Constraints window, click <strong>Add</strong>. A new security constraint is added to the window, and a new Web resource collection is added to the Web resource collection window.</li>
|
|
<li>Select <strong>(New Web Resource Collection)</strong>, and click <strong>Edit</strong>.</li>
|
|
<li>In the Web Resource Collections dialog, enter a name and description for the Web resource collection.</li>
|
|
<li>Select the appropriate HTTP methods.</li>
|
|
<li>Next to <strong>URL Patterns</strong>, click <strong>Add</strong>. Type the URL pattern (for example: <tt>/*</tt>, <tt>*.jsp</tt>, <tt>/hello</tt>). Consult the Servlet 2.3 Specification for more information about mapping URL patterns to servlets. The security run time uses the first exact match to map the incoming URL with URL patterns. If the exact match is not present, the security run time uses the longest match. The wild card URL pattern (such as <tt>*.*</tt> or <tt>*.jsp</tt>) is used last. Click <strong>OK</strong>.</li>
|
|
<li>Next to the Authorized roles window, click <strong>Edit</strong>. Type a description, and select the required Role Names. Note that if you do not select any role names, no user can have access to the Web resources that are specified under these security constraints. Click <strong>OK</strong>.</li>
|
|
<li>Select the appropriate user data constraint from the drop-down list. A user data constraint of <strong>None</strong> indicates that the communication between the Web client (browser) and the server (Web server) is transported over HTTP. A user data constraint of <strong>Confidential</strong> or <strong>Integral</strong> guarantees that the communication between the Web client and the Web server is secured and is transported over HTTPS.</li>
|
|
<li>Repeat the previous steps to create multiple security constraints.</li>
|
|
</ol><p></p></li>
|
|
|
|
<li><p><strong>Map security-role-ref and role-name to the role-link.</strong>
|
|
<br>During development of the Web application, you can create the security-role-ref element using development tools such as WebSphere Development Studio Client. The security-role-ref element contains only the role-name field at this stage. The role-name field contains the name of the role that is referenced in the servlet or JSP code to determine if the caller is in a specified role (if the isUserInRole() method returns true). Because security roles are created during the assembly stage, the developer uses a logical role name in the role-name field and provides enough description in the description field for the assembler to map the role actual (role-link). The Security-role-ref element is at the servlet level. A servlet or JSP file can have zero or more security-role-ref elements.</p>
|
|
<p>To map the elements to role-link, perform these steps:</p>
|
|
<ol type="a">
|
|
<li>Click the <strong>Source</strong> tab.</li>
|
|
<li>In the Outline window, expand the servlet to which you want to update the security-role-ref element.</li>
|
|
<li>Double-click the security-role-ref element.</li>
|
|
<li>In the source editor, type the appropriate values for the role-link element.</li>
|
|
<li>Repeat these steps until all servlets have the required role-link element defined.</li>
|
|
</ol><p></p></li>
|
|
|
|
<li><p><strong>Configure the login mechanism.</strong>
|
|
<br>The configured login mechanism applies to all the servlets, JSP files, and HTML resources in the Web module.</p>
|
|
<p>Click the <strong>Pages</strong> tab, and in the Login section, specify these settings:</p>
|
|
<ul>
|
|
<li><strong>Realm name:</strong> Specify the realm name to use for HTTP Basic authorization. The realm is defined on the server. It is a way to divide and limit the authorization of users on a HTTP server.</li>
|
|
<li><strong>Authentication method:</strong> Specifies the authentication mechanism for the Web application. As a prerequisite for gaining access to any Web resources that are protected by an authorization constraint, a user must be authenticated using the configured mechanism. Available authentication mechanisms include Basic, Digest, Form, and client certificate (Client-Cert). If you select Client-Cert, install the client certificate in the Web client (browser) and place the client certificate in the server trust keyring file.</li>
|
|
<li>(Optional) <strong>Login page:</strong> Browse to select a login page within the WAR file. This value is only specified for the form-based authentication method.</li>
|
|
<li>(Optional) <strong>Error page:</strong> Browse to select an error page within the WAR. This value is only specified for the form-based authentication method.</li>
|
|
</ul><p></p></li>
|
|
|
|
<li><p><strong>Save the web.xml file.</strong></p></li>
|
|
</ol>
|
|
|
|
</body>
|
|
</html>
|
|
|