You 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.
About this task
To secure web applications, determine the web resources that need protecting and determine
how to protect them.Note: This procedure might not match the steps that are 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:
Procedure
-
In an assembly tool, import your web application archive (WAR) file or an application archive
(EAR) file that contains one or more Web modules.
- In the Project Explorer folder, locate your web application.
- 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 you select
a web application archive (WAR) file, a web deployment descriptor editor opens.
If you select an enterprise application (EAR) file, an application
deployment descriptor editor opens.
- 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. You 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.
- Create security constraints.
Security constraints
are a mapping of one or more web resources to a set of roles.
- On the Security tab of a web deployment descriptor editor,
click Security Constraints.
On the Security Constraints
tab, you can do the following actions:
- Under Security Constraints, click Add.
- Under Constraint name, specify a display name for the
security constraint and click Next.
- Type a name and description for the web resource collection.
- Select one or more HTTP methods.
The HTTP
method options are: GET, PUT, HEAD, TRACE, POST, DELETE, and OPTIONS.
-
In the Patterns field, click Add.
- Specify a URL Pattern.
For example, type -
/*, *.jsp, /hello. Consult the Servlet specification Version
2.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.
- Click Finish.
- Repeat these steps to create multiple security constraints.
- Map security-role-ref and role-name elements to the role-link
element.
During the development of a web application, you
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 that is referenced in the servlet or JavaServer Pages
(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 JavaServer Pages (JSP) file can have zero or more security-role-ref
elements.
- Go to the References tab of a web deployment descriptor
editor.
On the References tab, you can add or remove the
name of an enterprise bean reference to the deployment descriptor.
You can define five types of references on this tab:
- EJB reference
- Service reference
- Resource reference
- Message destination reference
- Security role reference
- Resource environment reference
- Under the list of Enterprise JavaBeans (EJB)
references, click Add.
- Specify a name and a type for the reference in the Name and Ref
Type fields.
- Select either Enterprise Beans in the workplace or Enterprise
Beans not in the workplace.
- Optional: If you select Enterprise Beans
not in the workplace, select the type of enterprise bean in the Type field.
You can specify either an entity bean or a session bean.
- Optional: Click Browse to specify
values for the local home and local interface in the Local home and Local fields
before you click Next.
- Map every role-name that is used during development
to the role using the previous steps.
Every role name that
is used during development maps to the actual role.
- 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.
- On the Servlets tab of a web deployment descriptor editor,
under Servlets and JSP, click Add. The Add Servlet or
JSP wizard opens.
- Specify the servlet or JavaServer Pages (JSP) file settings,
including the name, initialization parameters, and URL mappings and
click Next.
- Specify the class file destination.
- Click Next to specify additional settings or
click Finish.
- Click Run As on the Servlets tab, select
the security role and describe the role.
- Specify a RunAs identity for each servlet and JSP file
that is used by your web application.
- Configure the login mechanism for the web module. This
configured login mechanism applies to all the servlets, JavaServer
Pages (JSP) files and HTML resources in the web module.
- 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.
- Specify a realm name.
- If you 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.
![[AIX Solaris HP-UX Linux Windows]](../images/ngdist.svg)
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.
Install
the client certificate on the browser web client and place the client
certificate in the server trust keyring file, if ClientCert certificate
is selected. The public certificate of the clients certificate authority
must be placed in the servers RACF® keyring. If the registry is
a local OS registry, use the RACDCERT MAP or the equivalent System
Authorization Facility (SAF) command to enable an MVS identity
creation using the client certificate.
- Close the deployment descriptor editor and, when prompted,
click Yes to save the changes.
Results
After securing a web application, the resulting web application archive (WAR) file contains
security information in its deployment descriptor. The web module security information is stored in
the web.xml file. 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. Supported configurations: 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 an application or module that uses a Java EE version
prior to version 5, the file extension must be .xmi.
- For an application or module that uses 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.
What to do next
After using an assembly tool to secure a web application, you can install the web
application using the administrative console. During the web application installation, complete the
steps in Deploying secured applications to finish securing the web application.