Skip navigation.
Downloads | Product Documentation | Support

Deploying WebLogic Platform Applications

# Configuring Security

WebLogic Platform 8.1 provides a single, unified security framework for all deployments, including portal applications, integration applications, and J2EE applications running on WebLogic Server.

This section summarizes the ways that you can secure the target environment, provides considerations for configuring security, and describes how to promote embedded LDAP security data to the target database. This section also describes how to maintain security policy files under version control.

Topics include:

- Ways to Secure the Target Environment
- Considerations for Configuring Security
- Promoting Embedded LDAP Security Data to the Target Database
- Maintaining Security Policy Files Under Version Control

For more details about WebLogic security features, see the following resources:

- Security in WebLogic Platform 8.1
- Introduction to WebLogic Security

Note: BEA strongly recommends that you maintain an archive of your user information in the event of a machine failure or other problem. For more information, see "Backing Up User Information" in "Configuring WebLogic Platform Security" in Managing WebLogic Platform Security in Security in WebLogic Platform 8.1.

# Ways to Secure the Target Environment

Table 5-1 lists ways you can secure a target environment, and includes recommendations for securing a production environment, in particular.

The following figure illustrates a WebLogic domain within a typical network configuration. Refer to this diagram when reviewing the security areas in Table 5-1.

Figure 5-1 WebLogic Domain Within a Typical Network Configuration

Table 5-1 Ways to Secure the Target Environment

Security Area | Considerations
--- | ---
Configure a firewall | A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines. Placing a firewall in front of your load balancing hardware enables you to set up a De-Militarized Zone (DMZ) for your web application using minimal firewall policies. The DMZ is a logical collection of hardware and services that is made available to outside, untrusted sources. For best practice tips when setting up a firewall, see "Firewall Considerations" in "Avoiding Problems" in Clustering Best Practices in Using WebLogic Server Clusters.
Use a load balancer or Web proxy server | A load balancer or Web proxy server distributes client connection requests, provides load balancing and failover across a WebLogic cluster, and provides security by concealing the local area network addresses from external users. For more information, see Using Load Balancers and Web Proxy Servers.
Secure the network connections | When designing network connections, you balance the need for a security solution that is easy to manage with the need to protect strategic WebLogic resources. You need to determine whether to set up firewalls and connection filters, for example, to secure network access. For tips on securing the network connections, review "Securing Network Connections" in Ensuring the Security of Your Production Environment in Securing a Production Environment.
Secure the WebLogic Server hosts | A WebLogic Server production environment is only as secure as the security of the machine on which it is running. Therefore, it is important that you lock down the physical machine, the operating system, and all other software that is installed on the host machine. For tips on securing the WebLogic Server host, review Securing the WebLogic Server Host in Securing a Production Environment.
Secure the WebLogic domain | Install the Administration Server on its own machine and target applications on Managed Servers to insulate the application and its users from the production environment infrastructure. Do not target applications (other than WebLogic Portal applications and modules) on the Administration Server.
Secure WebLogic resources | A WebLogic resource represents an underlying WebLogic Server entity that can be protected from unauthorized access. Examples of WebLogic resources include Enterprise Applications (EARs), EJBs (JARs), and Web Applications (WARs). A security realm comprises mechanisms for protecting WebLogic resources. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. A user must be defined in a security realm in order to access the WebLogic resources. For an overview of how resources are secured in WebLogic in a security realm, see Security Realms in Introduction to WebLogic Security. For information about customizing the default security realm, see Customizing the Default Security Configuration in Managing WebLogic Security. For more information about securing WebLogic resources, see: Securing WebLogic Resources Configuring Security Providers in Managing WebLogic Security. "Protecting Resources in a Platform-Based Application" in "Securing a Platform-Based Application" in Introducing WebLogic Platform 8.1 Security in Securing in WebLogic Platform 8.1. Protecting User Accounts in Managing WebLogic Security.
Secure WebLogic Portal resources | WebLogic Portal entitlements let you define rules (roles) to identify who can access specific portal resources. When a portal administrator logs in to the WebLogic Administration portal, the administrator sees only the areas that the administrator is allowed to administrator. When a visitor logs in to a portal, the visitor sees only the books, pages, and portlets to which the visitor is entitled. For more information about: The WebLogic Portal authentication framework, see Securing Portal Applications in WebLogic Workshop Online Help. Using Multiple Authentication Providers with WebLogic Portal in WebLogic Administration Portal Online Help. Configuring and promoting WebLogic Portal database tables, see Creating and Preparing a Production Database. Using an external database store, see Using an External Store for User Information in Security in WebLogic Platform 8.1.
Secure WebLogic Integration resources | You need to configure and manage security for trading partners for which security management is particularly important. Trading partners produce digital certificates for sending and receiving business messages in a secure environment. For more information about: WebLogic Integration security, see Using WebLogic Integration Security in Deploying WebLogic Integration Solutions. Configuring and promoting WebLogic Integration database tables, see Promoting WebLogic Integration Application Database Information.
Secure the database | A security provider database contains the users, groups, security roles, security policies, and credentials used by some types of security providers to provide security services. The security provider database can be the embedded LDAP server, a properties file, or a production-quality, customer-supplied database. The embedded LDAP server is the default security provider database for the WebLogic Authentication, Authorization, Credential Mapping and Role Mapping providers. The use of an external user store, such as an external LDAP or Relational Database Management System (RDBMS), enables centralized user management by security administrators across multiple domains. Also review the following information, as it applies to your environment: For tips on securing the database, review "Securing Your Database" in Ensuring the Security of Your Production Environment in Securing a Production Environment. For information about managing the embedded LDAP server, see Managing the Embedded LDAP Server in Managing WebLogic Security. If you are using an external user store, see Using an External Store for User Information in Security in WebLogic Platform 8.1.
Secure the applications | Although most of the responsibility for securing the WebLogic resources in a WebLogic Server domain fall within the scope of the server, some security responsibilities lie within the scope of individual applications. For tips on securing the applications, review the following: Preparing Application Security "Securing Applications" in Ensuring the Security of Your Production Environment in Securing a Production Environment Programming WebLogic Security
Enable Auditing | BEA recommends that you enable auditing in a production environment. An auditing provider stores operating requests and the results of those requests are collected, stored, and distributed for the purposes of non-repudiation. For more information about configuring auditing, see Configuring Security Providers in Managing WebLogic Security.

# Considerations for Configuring Security

Consider the following when configuring security:

- Enable Secure Sockets Layer (SSL) security. By default, SSL is enabled and configured to use the demonstration Identity and Trust keystores. The demonstration keystores are suitable for a development environment, but should not be used in a production environment. You can configure SSL to use a commercial digital certificate (such as VeriSign). For information about configuring SSL, see Secure Sockets Layer (SSL) in Introduction to WebLogic Security and Configuring SSL in Managing WebLogic Security.
- Set the configuration startup mode to `prod`. For more information, see Configuring Servers to Start in Production Mode.
- Optionally, configure controls that receive external callbacks to enforce the role restrictions.Your application will run without these role restrictions, but it will not behave exactly as the developer intended in terms of the role restrictions placed on a control's callback methods. This process is described in Step 3 of "To Manually Create Required Resources on the Production Server" in How Do I: Deploy a WebLogic Workshop Application to a Production Server? in the WebLogic Workshop Online Help.
- Enable trust between WebLogic Server domain, if required. BEA Systems does not recommend enabling trust between WebLogic Server domains in a production environment unless the servers have a secure means of communication such as a dedicated line or are protected by a firewall. For information, see Enabling Trust Between WebLogic Server Domains in Managing WebLogic Security.
- Do not configure the domain-wide Administration Port, as it is not supported for use by WebLogic Platform applications. You should use the SSL port. For more information about the Administration Port, see Enabling the Domain-Wide Administration Port in WebLogic Server Administration Console Online Help.
- If you wish to configure single sign-on, be careful that you do not inadvertently enable access permissions to untrusted users. For information about configuring single sign-on, see Single Sign-On with Enterprise Information Systems in Managing WebLogic Security.

# Promoting Embedded LDAP Security Data to the Target Database

The following sections describe how you can promote existing embedded LDAP data to the target embedded LDAP database:

- Promoting Security Data to the Target Environment
- Promoting WebLogic Portal and WebLogic Integration Data

Note: WebLogic Platform does not support an automated process for promoting embedded LDAP server data to an external user store, such as an external LDAP server or RDBMS. If you develop a custom tool to handle this process, you should be aware that the existing password information is not maintained during the promotion.

## Promoting Security Data to the Target Environment

The embedded LDAP server is the default security provider database for the WebLogic Authentication, Authorization, Credential Mapping and Role Mapping providers. The embedded LDAP server contains user, group, group membership, security role, security policy, and credential map information. By default, each WebLogic Server domain has an embedded LDAP server configured with the default values set for each attribute.

If you have created security information, or configured security providers, in development that you expect to be used in the target environment, you will want to promote that information and security provider configuration to the target environment. Promoting this data ensures that your application will work correctly in the target environment. WebLogic Server provides utilities you can use to export the following security data from one security realm, and import them into a new security realm:

- Users and groups
- Security policies
- Security roles
- Credential maps

You can migrate security data for each security provider individually, or migrate security data for all the WebLogic security providers for an entire security realm at once. You migrate security data through the WebLogic Server Administration Console or by using the `weblogic.admin` utility. For information about importing and exporting security data from security realms and security providers, see:

- Migrating Security Data in Managing WebLogic Security
- Exporting and Importing Information in the Embedded LDAP Server in Managing WebLogic Security

Note: Optionally, you can use an LDAP browser to export and import data stored in the embedded LDAP Server.

## Promoting WebLogic Portal and WebLogic Integration Data

When you set up the production database, you must define the database tables required by your application. In some cases, you can promote existing security data to the target environment. For information about configuring and promoting WebLogic Portal and WebLogic Integration data, see Promoting Database Information to the Production Database.

# Maintaining Security Policy Files Under Version Control

You can maintain the security policy files using a source control tool, such as Perforce or CVS, by performing the following steps:

1. Export security policy information, as described in the following sections:

- Migrating Security Data in Managing WebLogic Security
- Exporting and Importing Information in the Embedded LDAP Server in Managing WebLogic Security

2. Check the data into your version control system.