GRC
HR
SCM
CRM
BI


Article

 

Build Security into Your J2EE Application Development Process with SAP NetWeaver Developer Studio

by Dr. Jürgen Schneider | SAPinsider

October 1, 2003

by Dr. Jürgen Schneider, SAP AG SAPinsider - 2003 (Volume 4), October (Issue 4)
 

“Build in security right from the start” is one of the golden rules for secure software and IT systems. Once all your systems are up and running, adding security measures is that much more difficult — and sometimes even impossible. So application programming models and development tools that support easy integration of security requirements during development are extremely helpful.

The J2EE (Java 2 Platform Enterprise Edition) model for application programming features security measures such as secure transport guarantees, user authentication, and security roles for authorization. In a previous article, I described how the SAP J2EE Engine provides the tools and runtime services to implement the J2EE security model and how administration of these services works once a Java application is deployed.1 Now, in SAP NetWeaver Developer Studio (part of SAP Web Application Server 6.30), developers will find additional development resources for more secure J2EE programming.

The powerful tools in NetWeaver Development Studio support direct, native integration of J2EE security requirements and constraints at development time. What’s more, SAP NetWeaver Developer Studio is seamlessly integrated with the SAP J2EE Engine. This not only facilitates development of J2EE applications, it also ensures that security features can be included during design and tested immediately.

This article offers a brief outline of the Developer Studio’s capabilities for integrating security requirements when creating J2EE-standard applications, including Web, EJB, and Web services applications. Programmers and J2EE application developers will find they can easily identify the resources required to enforce security in their daily work. For IT managers, project leaders, and decision makers, this overview provides a useful introduction to basic J2EE security principles and how they are supported in SAP NetWeaver Developer Studio and the SAP J2EE Engine.

Let’s start with a simple Web application from the SAP NetWeaver Developer Studio tutorial, and take the next steps for enforcing secure transport, user authentication, and access control at development time.

Securing a Web Application

The SAP NetWeaver Developer Studio tutorial guides developers through the creation of a very straightforward J2EE application — a basic online calculator,2 shown in Figure 1. The J2EE Explorer panel displays the “parts” required for any J2EE-compliant application:

  • An Enterprise Java Bean (EJB), which provides business methods for calculating two numbers, under myEJBProject.

  • A Java bean, used to invoke the EJB methods via a Web application using Java Server Pages (JSP), under myWebProject.

  • The EJB Assembly project (JAR), Web Application project (WAR), and Enterprise Application project (EAR), which create the required archive files containing the various Java application parts.

At this point, the Calculator application has been designed and deployed. If no additional security measures are taken, the calculator is ready to be accessed anonymously by anyone over the Web (http://: /calculator/Calculator.jsp).

This is perfectly fine if you are offering public information such as news, product catalogs, or free services (or probably even an online calculator!). But if you need to limit access to select individuals or groups, or if user preferences or other private attributes become crucial, you will need user authentication. In the steps that follow, we will add this and other safeguarding features.

Figure 1
   The Calculator Tutorial in the SAP NetWeaver Developer Studio

Step 1: Set Up User Authentication for the Application

To enforce user authentication, an authentication method first must be configured for the Web application. In the Developer Studio, you select the Web application (WAR) project in the J2EE Explorer view (myWarProject in Figure 1) and edit the Web.xml file in the General section (see Figure 2). When you mark the checkbox Login configuration, you can select the authentication method (BASIC, DIGEST, FORM, or CLIENT-CERT).

Figure 2
Choosing the Authentication Method for the Login Configuration

Selecting BASIC authentication, for example, triggers the standard browser authentication pop-up when a user accesses the calculator application (see Figure 3).

Figure 3
   Example of a Basic Authentication Pop-up

Step 2: Define Security Constraints for Web Resources

You may want to specify other measures to protect specific resources of the Web application by defining security constraints on a particular set of Web resources (i.e., the URL pattern to access the application). These constraints might include authorization, cryptographic services, security roles, or transport protocols such as HTTPS.

From the Developer Studio, these are set for the WAR file in the Security Constraints section (see Figure 4). Select Web Resource Collection (the tab encircled in red) and click on the add button to create a security constraint on a Web resource.3 For example, I have set up a security constraint definition called myAuthenticationConstraint. This will apply to the Web resource collection calculator as identified by the URL pattern /Calculator.jsp.

Within the Security Constraints section you will find three options, indicated in blue in Figure 4:

  • Under General, you can set transport guarantees, such as integrity or confidentiality protection. This will require the HTTPS4 protocol to use the application, with the required cryptographic services for integrity checking and encryption. When basic authentication is the login method, encrypted transport is highly recommended to protect password information.

  • If you have selected login configuration and transport guarantees, any Web resource named under the Web Resource Collection tab will require a valid userid and password for access to the application on the SAP J2EE Engine.

  • You may want to enforce authorization for selected parts of the Web application. For this you can use J2EE security roles. Select the Auth Constraint tab (see Figure 5) and add the name of a security role. (Suitable roles for the Web application can be created in the Security Roles section of the Web application project in the Developer Studio.) In the example, I created a security role CalculatorSecurityRole and assigned it to the authorization constraint part of the Web resource collection.

The steps for authentication, transport guarantee, and authorization in the Developer Studio result in corresponding entries made in the standard deployment descriptor.5 You can view these entries by going from the Security Constraints section to the Source section, then selecting the web.xml file for the Web application project.

Figure 4
Defining a Security Constraint on a Web Resource Collection

Figure 5
Defining an Authorization Constraint for a Web Resource Collection

Step 3: Save the Application and Redeploy It

At this point, the Web application project is then saved and rebuilt, and then is redeployed (the SAP NetWeaver Developer Studio tutorial shows you how to do this with a few mouse clicks). Any security constraints defined for the application are now enforced whenever someone accesses the Calculator application.

For example, if the role CalculatorSecurityRole has not yet been mapped to a user or user group in the SAP J2EE Engine, you will see the “403 Forbidden” error message (see Figure 6) when trying to access the Calculator with a Web browser.

To map this role to a user or user group in the J2EE Engine, log on as an administrator at the SAP J2EE Engine with the Visual Administrator tool6 and use the Security Provider section. Then, to test whether the security constraints defined for the Calculator application are enforced correctly, simply access the Calculator from a Web browser and login as a user who is assigned to the CalculatorSecurityRole or who is a member of a user group assigned to this role.

So, after a few configuration steps and redeployment from the Developer Studio, our Web application now features security (authentication and authorization) that can easily be added and tested on the SAP J2EE Engine. But what if you want to secure particular methods for the Calculator application or add security to the Calculator function after it’s exposed as a Web service? SAP NetWeaver Developer Studio can help here, too.

Figure 6
   “Not Authorized” Error Page

Securing Enterprise Java Bean (EJB) Applications

The J2EE standard specifies that Enterprise Java Beans (EJBs) must always run in a certain user context — they never run anonymously. The user is already authenticated, either in the session passed from a Web container (WAR project) or in the EJB container itself (e.g., using JNDI lookup7 or RUN-AS identities,8 as described in the J2EE specification). So, you won’t need to add authentication to an EJB application.

However, you may want to set authorizations to protect the methods in the EJB using J2EE security roles. Note that this process is distinct from setting authorizations for Web applications (covered previously in Step 3) and is specified separately in the EJB Assembly (JAR) project in the Developer Studio.

As an example, in the Assembly section of myJarProject (see Figure 7) I have created two different security roles — AddAndSubtractRole and MultiplyAndDivideRole — and two corresponding method permissions. The resulting entries can be viewed in the deployment descriptor for the EJB Assembly project (in the tutorial, take a look at the ejb-jar.xml file using the Source section of myJarProject).

Saving, rebuilding, and redeploying the enterprise application project will enforce these authorization checks when a method of the EJB is invoked. You can test this in the tutorial by assigning the AddAndSubtractRole and/or MultiplyAndDivideRole to a suitable user or user group in the SAP J2EE Engine and accessing the Calculator application again using a Web browser. To protect the EJB methods, access to the application now is only successful for users with the appropriate security roles.

Figure 7
   Protecting EJBs with Method Permissions

Turning EJBs into Secure Web Services

With the SAP NetWeaver Developer Studio, it is very simple to create standard Web services for existing EJBs.9 Just use the context menu (right mouse button) on the EJB Assembly project and choose “New” --> “Web Service.” For our example, I have created calcWebService (see Figure 8).

In the Web service deployment descriptor section, you can select from the list of authentication types to enforce authentication for the Web service.

Although Web services are based on EJBs, you can specify a separate authorization for any Web service. Simply mark the checkbox Use Authorization and select appropriate security roles for each operation. Then save and rebuild the EJB Assembly project and redeploy the enterprise application to update the version running on the SAP J2EE Engine.

Figure 8
   Specifying Security Constraints for Web Services

Conclusion

The new SAP NetWeaver Developer Studio facilitates setting security constraints for user authentication and authorization (as well as securing transport) during application development and assembly. Security-enabled J2EE applications can be deployed and tested immediately on the SAP J2EE Engine, which provides the corresponding runtime support for security enforcement. This leaves no excuse for your application developers to leave out security or postpone it to a later phase, right?

However, there are still a number of open issues concerning security on the J2EE standard. For instance, the J2EE authorization model, based on the logical grouping of users into security roles, is not well suited for access decisions that require instance-specific information at the time of Web access or method invocation. Also, there is no standard support for access control lists (ACLs), which seem better suited for protecting applications with large object spaces. What’s more, gathering audit information and providing corresponding services for security analysis and reviews is not yet the focus of J2EE standardization.

The SAP J2EE Engine complements the J2EE standard and enhances it where J2EE concepts are not reaching far enough — including areas like security. There is more to come concerning secure development and operation of Java applications with SAP Technology — stay tuned to this column.


1 See my article "J2EE Security Architecture Implementation with the SAP J2EE Engine" in the January-March 2003 issue of SAP Insider.

2 See "Writing your first J2EE Application" under J2EE Technology in SAP Web Application Server --> Getting Started in the SAP NetWeaver Developer Studio's Help menu.

3 Web resources are dynamic and static content of a Web application, for example servlets, JSP pages, HTML documents, or image files. A Web resource collection defines a subset of the Web resources and HTTP methods on those resources within a Web application.

4 HTTP over Secure Sockets Layer.

5 The contract between the Application Component Provider or Assembler and the Deployer. See the Java 2 Platform, Enterprise Edition Specification, v1.3, at http://java.sun.com/j2ee/docs.html.

6 The interactive administration client of the SAP J2EE Engine.

7 Java Naming and Directory Interface. See Section 5 in the Java 2 Platform, Enterprise Edition Specification, v1.3, at http://java.sun.com/j2ee/docs.html.

8 See Section 3.5.4 in the Java 2 Platform, Enterprise Edition Specification, v1.3, at http://java.sun.com/j2ee/docs.html.

9 For more on Web services, see Wolf Hengevoss's article in this issue of SAP Insider (www.SAPinsider.com).


Dr. Jürgen Schneider has been involved in the design and implementation of SAP security functions since 1996. Since 1998, he has been the Development Manager for Security in SAP’s Technology Development. He can be reached at j.schneider@sap.com.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ