Introduction

 

The BEA Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server are applications that may store personal information about customers or display Web site content based on a customer's identity. However, the level of sensitivity for such data varies. For example, a customer's credit card information is highly sensitive data that must be protected; a customer's color preferences may be considered by some as less sensitive.

Regardless of the perceived sensitivity of these activities, the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications provide you with ways to protect the confidentiality and integrity of customer data, customer preferences, and the overall integrity of customer transactions. This Security Guide was designed to help you understand how the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server leverage the security features of the Java^TM 2 Platform Enterprise Edition (J2EE) specification and the J2EE-compliant security features of the WebLogic Server platform, as well as understand any additional security measures that have been established for application components. This guide also describes ways that you can modify security settings within the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server to inspire customer confidendence and solidify your e-business' online relationships.

As the introduction to this Security Guide, this topic includes the following sections:

• Determining Your Application Security Needs

• Development Roles

• Important Security Features

• Next Steps

 

---

Determining Your Application Security Needs

Security is a critical component of developing e-commerce applications that no organization can afford to ignore. Malicious users who gain access to your computer systems can temporarily interrupt business, but those who gain access to your customers' personal data can cause long-term damage to your reputation. Even if you have not had any security mishaps, customers are often hesitant to provide personal information over the Web, which could affect your abilitiy to tailor products and services to customer preferences. Therefore, your organization must develop e-commerce applications that protect customer data and communicate a sense of privacy and purpose through the user interface. At the same time, however, the application must not be difficult to navigate or perform slowly because of technical security requirements.

As the previous discussion suggests, determining your application security needs can be a difficult balancing act. BEA recommends that you ask yourself the following questions when attempting to define your application security requirements:

• What resources should I protect?

  There are many resources in the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications that can be protected, including Enterprise JavaBeans (EJBs), servlets, and JavaServer Pages (JSPs). Consider the resources you want to protect when deciding the level of security you must provide.

• From whom am I protecting these resources?

  Like many e-commerce Web sites, you may consider browsing product catalog pages an acceptable activity for both anonymous and authenticated users. Once a user decides to purchase an item, however, you may need to identify that user and retrieve some of their personal information. Obviously, this information must be protected from all other users of the Web site, who may or may not have malicious intent.

  Similarly, the tools included with the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications may allow administrators to modify the behavior of your e-commerce Web site. Should these administrators be able to access all resources and all data? Or should the most confidential and strategic information be trusted to only a few individuals?

• What are the consequences of ineffective or failed protection on the resource?

  In some cases, a fault in your application security is easily detected and considered nothing more than an inconvenience. In other cases, a fault might cause great damage to companies or individual clients that use the site. Understanding the security ramifications of each resource will help you to properly protect it.

As you read the rest of this Security Guide, keep the answers to these questions in mind. By thinking up-front about your security requirements, you will be more likely to design security-aware Web applications, and will be better prepared for deployment.

 

---

Development Roles

This Security Guide is intended mainly for individuals in the following roles:

• Application Assembler: The Application Assembler takes a set of components and assembles them into a complete J2EE application delivered in the form of a Enterprise ARchive (.EAR) file. The Application Assembler provides instructions that describe external dependencies of the application, which the Deployer will resolve in the deployment process.

• Deployer: The Deployer, usually expert in a specific operational environment, is responsible for deploying Web applications and Enterprise JavaBeans components into that environment. The deployment process is typically a three-stage process:

  • Installation: Moves the media to the server, generates the additional container-specific classes and interfaces that enable the container to manage the application components at runtime, and installs the application components and additional classes and interfaces into the J2EE containers.

  • Configuration: Resolves all the external dependencies and follows the application assembly instructions defined by the Application Assembler. For example, the Deployer is responsible for mapping the security roles defined by the Application Assembler to the user groups and accounts that exist in the operational environment into which the application components are deployed.

  • Execution: Starts up the newly installed and configured application.

    The Deployer's output is Web applications, Enterprise JavaBeans, applets, and application clients that have been customized for the target operational environment and are deployed in a specific J2EE container.

• Site Administrator: The Site Administrator is responsible for the configuration and administration of the enterprise's computing and networking infrastructure. The Site Administrator is also responsible for overseeing the run time well-being of the deployed J2EE applications.

Note: The roles described above are from the Java 2 Platform Enterprise Edition Specification v1.3, which you may consult for more information. For a quick reference, see the "Development Roles" section of the J2EE Tutorial.

 

---

Important Security Features

The important aspects of the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server security mechanisms are described in the following paragraphs.

Reliance on J2EE Standards and Platform Security

Security implementations in the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications rely upon the security definitions in the Java 2 Enterprise Edition (J2EE) specification and security measures implemented in the WebLogic Server platform.

This dependancy has two important implications. First, the applications you build using the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server products as a base will also leverage the security mechanisms implemented by the container, instead of requiring you to embed security code within your Enterprise JavaBeans (EJBs) routines or their clients. This architectural structure not only reduces debugging/maintenance issues and the likelihood of security holes due to programming errors, but it also avoids the requirement of tying security roles to individual applications. Second, because of the reliance on J2EE and the J2EE-compliant WebLogic Server, you can be certain that your Web applications will conform to the latest security standards in the industry.

For more information about J2EE security, see the Java 2 Platform Enterprise Edition Specification, v1.3. For more information about how the BEA WebLogic Server implements J2EE security, see Programming WebLogic Security.

Declarative Security with Deployment Descriptors

Because of the reliance on J2EE security and the WebLogic Server implementation of these techniques, security in the Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server applications is declarative. In other words, protections on resources are defined in a central configuration document called a deployment descriptor, which is then used by the WebLogic Server platform to enforce security restrictions. Access to protected resources is granted based on whether the requesting user's security role matches the role declared in the deployment descriptor for that resource.

Note: For more information about deployment descriptors and security roles, see Deployment Descriptors and Security Roles.

A declarative approach to security enforcement has three major advantages. First, this type of security is fine-grained, meaning that access can be restricted all the way down to a specific method on a JavaBean. Second, the administrator of the WebLogic Server (or other J2EE-compliant server) can customize the security attributes for a particular production environment at deployment time. Third, because deployment descriptor information is declarative, it can be changed without modifying any JavaBean source code. At run time, the WebLogic Server simply reads the deployment descriptor and acts upon the component accordingly.

Note: For more information about declarative security, see the Enterprise JavaBeans 1.1 Specification, or the Java 2 Platform Enterprise Edition Specification, v1.3.

 

---

Next Steps

As the topics in this introduction show, the Security Guide assumes a certain level of familiarity with standard J2EE security implementations and with the security mechanisms of the BEA WebLogic Server. If you have no prior or recent experience with J2EE or WebLogic Server, you may want to spend some time learning about these technologies before proceeding.

For more information about J2EE security, consult the following documents:

• Java Servlet Specification v2.2

• Java 2 Platform Enterprise Edition Specification, v1.3

• Enterprise JavaBeans 1.1 Specification

For more information about BEA WebLogic Server security, consult the following documents:

• Programming WebLogic Security

• "web.xml Deployment Descriptor Elements" in the Developing WebLogic Server Applications documentation.

Lastly, the Deployment Guide (which is part of the same Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server documentation set) may also be helpful in understanding the contents of this Security Guide.

If you feel comfortable with J2EE and WebLogic Server security topics, proceed through this guide — either sequentially or selectively — to answer your questions about Campaign Manager for WebLogic, WebLogic Commerce Server, and WebLogic Personalization Server security.