Secure applications during assembly and deployment
Several assembly tools exist that are GUIs for assembling enterprise or Java EE applications. We can use these tools to assemble an application and secure EJB and web modules in that application.
An EJB module consists of one or more beans. We can enforce security at the EJB method level. A web module consists of one or more web resources: an HTML page, a JSP file, or a servlet. We can also enforce security for each web resource.
For information about the tools that WebSphere Application Server supports, see Assembly tools.
To secure an EJB module, a JAR file, a web module, a WAR file, or an application EAR file, we can use an assembly tool. We can create an application, an EJB module, or a web module and secure them using an assembly tool or development tools such as the IBM Rational Application Developer.
- Secure EJB applications by using an assembly tool. For more information, see Secure enterprise bean applications.
- Secure web applications by using an assembly tool. For more information, see Secure web applications using an assembly tool.
- Add users and groups-to-roles while assembling a secured application using an assembly tool. For more information, see Add users and groups to roles using an assembly tool.
- Map users to RunAs roles using an assembly tool. For more information, see Mapping users to RunAs roles using an assembly tool.
- Add the was.policy file to applications for Java 2 security.
- Assemble the application components that you secured using an assembly tool. For more information, see Assembling applications.
Results
After securing an application, the resulting .ear file contains security information in its deployment descriptor. The EJB module security information is stored in the ejb-jar.xml file and the web module security information is stored in the web.xml file. The application.xml file of the application EAR file contains all the roles used in the application. The user and group-to-roles mapping is stored in the ibm-application-bnd.xmi file of the application EAR file.
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. sptcfg
The was.policy file of the application EAR contains the permissions that are granted for the application to access system resources that are protected by Java 2 security.
This task is required to secure EJB modules and web modules in an application. This task is also required for applications to run properly when Java 2 security is enabled. If the was.policy file is not created and it does not contain required permissions, the application might not be able to access system resources.
What to do next
After securing an application, we can install an application using the console. When you install a secured application, refer to Deploy secured applications to complete this task.
Subtopics
- Update and redeploying secured applications
This section addresses the way to update existing applications.
- Deploy secured applications
Deploying applications that have security constraints (secured applications) is not much different than deploying applications that do not contain any security constraints. The only difference is that we might need to assign users and groups to roles for a secured application. The secured application requires that we have the correct active user registry.
Related tasks
Task overview: Deploy web applications Secure enterprise bean applications Secure web applications using an assembly tool Assembling applications Add users and groups to roles using an assembly tool Mapping users to RunAs roles using an assembly tool Add the was.policy file to applications for Java 2 security
Java 2 security policy files