Securing Webapps

 

There are three types of Web login authentication mechanisms that you can configure on a Webapp: basic authentication, form-based authentication and client certificate-based authentication. Protect Web resources in a Web application by assigning security roles to those resources. So, you need to know in advance what Web Resources need protecting and how. To secure Web applications, determine the Web resources that need protecting and determine how to protect them.

 

  1. Open the Webapp file by clicking File > Open. Browse and select the Webapp file. The application file can be a Web archive (WAR) file or an enterprise archive file that contains one or more Web modules.

  2. Create security roles either at the application level or at 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 the Web modules. One can copy and paste a security role at the application level to one or more Web module security roles.

    1. Create a role at the application level by right-clicking Security Roles under the application folder. Click New. Type the role name. If the role created for the application is required for a Web module, select that role from the application. Copy the role and select the Web module security role. Right-click the Web module security role and click Paste.

    2. Create a role at the Web module level by opening the corresponding Web module folder. Right-click Security Roles under the Web module and click New. Type the role name.

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

    1. Open the Web module folder and right-click Security Constraints. Click New. A new panel displays.

    2. Type the security constraints name and description.

    3. Add required roles by clicking Add under Roles. Browse and click the required roles. The asterisk (*) indicates all roles. An empty role list indicates that no user can have access to the Web resources specified under these security constraints.

    4. Set user data constraints by clicking Transport Guarantee from the menu. A transport guarantee of NONE indicates that the communication between the Web client or browser and the server or Web server is transported over HTTP. A transport guarantee of CONFIDENTIAL or INTEGRAL guarantees that the communication between the Web client and the Web server is secured and is transported over HTTP and HTTPS.

    5. Click OK when done. A new Security Constraints folder is created for the Web module.

    6. Open the security constraints created from previous steps and right-click Web Resources Collection. Click New. A new panel displays.

    7. Type a Web resource collection name and description.

    8. Click Add under Methods and select HTTP methods. Click OK. If no methods are selected, all methods are selected by default.

    9. Click Add under URLs and type the URL pattern (for example: - /*, *.jsp, /hello ). Consult the Servlet specification Version 2.3 for instructions on mapping URL patterns to servlets. Security run time uses the exact match first 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 ( *. , *.jsp ) URL pattern matching is used last.

    10. Click OK when done.

    11. Repeat these steps to create multiple security constraints.

  4. Map security-role-ref and role-name elements to the role-link element. During the development of a Webapp, you can create the security-role-ref element using development tools such as WebSphere Studio Application Developer. 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 (isUserInRole()). Since 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.

    1. Map the role-name element to the role-link element for a security-role-ref element, by opening the required servlet folder. Click Security Role References.

    2. Select each role name on the right navigation panel and click the actual role to be mapped to that rolename. Select a role from the menu of the link.

    3. If the security-role-ref element is not created already during development, right-click Security Role References. Click New. A new panel displays.

    4. Enter the role-name in the Name field and the role-link element in the Link field by selecting a proper role from the menu. Add a description in the Description field. Every role name used during development now maps to the actual role.

  5. 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. Set the RunAs identity for a servlet by clicking the servlet folder. Select the Security tab on the right navigation panel.

    2. Select the role name from the menu. Click Apply when done.

  6. Configure the login mechanism. Configure the login mechanism only at the Web module level. This configured login mechanism applies to all the servlets, JavaServer page files and HTML resources in the Web module.

    1. Configure the login mechanism for the Web module by clicking the Web Module folder.

    2. Click the Advanced tab on the right navigation panel.

    3. Select the Login Configuration check box.

    4. Select the required authentication method from the menu.

    5. Type the Login page and Error page URLs if you select form-based authentication (for example: /login.jsp and /error.jsp ). The specified login and error pages are present in the .war file.

    6. Install the client certificate on the browser or Web c lient and place the client certificate in the server trust keyring file, if ClientCert is selected.

 

Results

After securing a Webapp, the resulting WAR file contains security information in its deployment descriptor. The Web module security information is stored in the web.xml file.

 

What to do next

After using the Application Assembly Tool (AAT) to secure a Webapp, you can install the Webapp using the administrative console. During the Webapp installation, complete the steps in the Deploying Secured Applications article to finish securing the Webapp.

Role-based authorization
Web component security
Delegations
Security permissions assembly settings
Security: Links

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.