WAS v8.5 > Secure applications > Secure web applications > Web application security components and settings

Secure web applications using an assembly tool

We can use three types of web login authentication mechanisms to configure a web application: basic authentication, form-based authentication and client certificate-based authentication. Protect web resources in a web application by assigning security roles to those resources.

To secure web applications, determine the web resources that need protecting and determine how to protect them.

This procedure might not match the steps required when using your assembly tool, or match the version of the assembly tool that you are using. You should follow the instructions for the tool and version that you are using.

The following steps detail securing a web application using an assembly tool:

1. In an assembly tool, import your WAR file or an application archive (EAR) file containing one or more Web modules.
2. In the Project Explorer folder, locate the web application.
3. Right-click the deployment descriptor and click Open With > Deployment Descriptor Editor. The Deployment Descriptor window opens. To see online information about the editor, press F1 and click the editor name. If we select a WAR file, a web deployment descriptor editor opens. If we select an enterprise application (EAR) file, an application deployment descriptor editor opens.

4. Create security roles either at the application level or at the web module level. If a security role is created at the web module level, the role also displays in the application level. If a security role is created at the application level, the role does not display in all of the web modules. We can copy and paste a security role at the application level to one or more Web module security roles.

   • Create a role at a Web-module level. In a web deployment descriptor editor, click the Security tab. Under Security Roles, click Add.. Enter the security role name, describe the security role, and click Finish.

   • Create a role at the application level. In an application deployment descriptor editor, click the Security tab. Under the list of security roles, click Add. In the Add Security Role wizard, name and describe the security role and then click Finish.

5. Create security constraints. Security constraints are a mapping of one or more web resources to a set of roles.

   1. On the Security tab of a web deployment descriptor editor, click Security Constraints. On the Security Constraints tab, we can do the following actions:

      • Add or remove security constraints for specific security roles.

      • Add or remove web resources and their HTTP methods.
      • Define which security roles are authorized to access the web resources.

      • Specify None, Integral, or Confidential constraints on user data.

        None

        The application does not require transport guarantees.

        Integral

        Data cannot be changed in transit between the client and the server.

        Confidential

        Data content cannot be observed while it is in transit.

        Integral and Confidential usually require the use of SSL. When deploying applications available over public networks, specify Confidential for the web applications constraints

   2. Under Security Constraints, click Add.

   3. Under Constraint name, specify a display name for the security constraint and click Next.

   4. Type a name and description for the web resource collection.

   5. Select one or more HTTP methods. The HTTP method options are: GET, PUT, HEAD, TRACE, POST, DELETE, and OPTIONS.
   6. Beside the Patterns field, click Add.

   7. Specify a URL Pattern. For example, type - /*, *.jsp, /hello. Consult the Servlet specification v2.4 for instructions on mapping URL patterns to servlets. The security runtime uses the exact match first to map the incoming URL with URL patterns. If the exact match is not present, the security runtime uses the longest match. The wild card (*.,*.jsp) URL pattern matching is used last.

   8. Click Finish.
   9. Repeat these steps to create multiple security constraints.

6. Map security-role-ref and role-name elements to the role-link element. During the development of a web application, we can create the security-role-ref element. The security-role-ref element contains only the role-name field. The role-name field contains the name of the role referenced in the servlet or JSP (JSP) code to determine if the caller is in a specified role. 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. The Security-role-ref element is at the servlet level. A servlet or JSP file can have zero or more security-role-ref elements.

   1. Go to the References tab of a web deployment descriptor editor. On the References tab, we can add or remove the name of an enterprise bean reference to the deployment descriptor. We can define five types of references on this tab:
      • EJB reference
      • Service reference
      • Resource reference
      • Message destination reference
      • Security role reference
      • Resource environment reference

   2. Under the list of EJB references, click Add.

   3. Specify a name and a type for the reference in the Name and Ref Type fields.

   4. Select either Enterprise Beans in the workplace or Enterprise Beans not in the workplace.

   5. Optional: If we select Enterprise Beans not in the workplace, select the type of enterprise bean in the Type field. We can specify either an entity bean or a session bean.

   6. Optional: Click Browse to specify values for the local home and local interface in the Local home and Local fields before you click Next.
   7. Map every role-name used during development to the role using the previous steps. Every role name used during development maps to the actual role.

7. Specify the RunAs identity for servlets and JSP files. The RunAs identity of a servlet is used to invoke enterprise beans from within the servlet code. When enterprise beans are invoked, the RunAs identity is passed to the enterprise bean for performing an authorization check on the enterprise beans. If the RunAs identity is not specified, the client identity is propagated to the enterprise beans. The RunAs identity is assigned at the servlet level.

   1. On the Servlets tab of a web deployment descriptor editor, under Servlets and JSP, click Add. The Add Servlet or JSP wizard opens.

   2. Specify the servlet or JSP file settings, including the name, initialization parameters, and URL mappings and click Next.

   3. Specify the class file destination.

   4. Click Next to specify additional settings or click Finish.

   5. Click Run As on the Servlets tab, select the security role and describe the role.

   6. Specify a RunAs identity for each servlet and JSP file used by the web application.

8. Configure the login mechanism for the web module. This configured login mechanism applies to all the servlets, JSP files and HTML resources in the web module.

   1. Click the Pages tab of a web deployment descriptor editor and click Login. Select the required authentication method. Available method values include: Unspecified, Basic, Digest, Form, and Client-Cert.

   2. Specify a realm name.

   3. If we select the Form authentication method, select a login page and an error page web address. For example, you might use /login.jsp or /error.jsp. The specified login and error pages are present in the .war file.
   4. Install the client certificate on the browser or web client and place the client certificate in the server trust keyring file, if ClientCert is selected.

9. Close the deployment descriptor editor and, when prompted, click Yes to save the changes.

Results

After securing a web application, the resulting WAR file contains security information in its deployment descriptor. The web module security information is stored in web.xml. When you work in the web deployment descriptor editor, you also can edit other deployment descriptors in the web project, including information on bindings and IBM extensions in the ibm-web-bnd.xmi and ibm-web-ext.xmi files.

For IBM extension and binding files, the .xmi or .xml file name extension is different depending on whether you are using a pre-Java EE 5 application or module or a Java EE 5 or later application or module. An IBM extension or binding file is named ibm-*-ext.xmi or ibm-*-bnd.xmi where * is the type of extension or binding file such as app, application, ejb-jar, or web. The following conditions apply:

• For apps and modules that use a Java EE version prior to version 5, the file extension must be .xmi.

• For apps and modules that use Java EE 5 or later, the file extension must be .xml. If .xmi files are included with the application or module, the product ignores the .xmi files.

However, a Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension.

The ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, and ibm-portlet-ext.xmi files continue to use the .xmi file extensions. sptcfg

After using an assembly tool to secure a web application, we can install the web application using the dmgr console. During the web application installation, complete the steps in Deploy secured applications to finish securing the web application.

Related concepts:

Role-based authorization
Web component security
Delegations
Portlet URL security

Related

Deploy secured applications

Reference:

Security: Resources for learning

+

Search Tips   |   Advanced Search