Skip navigation.
Downloads | Product Documentation | Support

Security in WebLogic Platform 8.1

# Managing WebLogic Platform Security

The following sections provide a high-level view of the tasks associated with managing WebLogic Platform security:

- Configuring WebLogic Platform Security
- Securing a Production Environment

# Configuring WebLogic Platform Security

This section discusses the following topics:

- Upgrading the Security Configuration from a Previous Release
- Configuring Security Using the Configuration Wizard
- Configuring Security Using the Administration Consoles
- Configuring Your Platform Applications on Multiple Servers, Across Domains, and in Clusters
- Customizing the Security Configuration
- Backing Up User Information
- Migrating User Information to Another Security Realm or Domain

## Upgrading the Security Configuration from a Previous Release

This section summarizes key points about upgrading your security configuration from previous releases of WebLogic Platform, and provides links to security upgrade topics throughout the WebLogic Platform documentation. For a comprehensive list of all upgrade topics in the WebLogic Platform documentation, see the WebLogic Platform Upgrade Planning Guide.

Note: Compatibility Security is not supported for WebLogic Platform. If you use only WebLogic Server in a domain, you can use Compatibility Security. However, if you add a WebLogic Portal or WebLogic Integration component to that domain, then Compatibility Security is not supported.

### Upgrading to WebLogic Server 8.1 Security

If you are upgrading WebLogic Server 7.0 to 8.1, note the following changes regarding the security system:

- All security configuration data is now stored in the `config.xml` file. Existing security configuration data is written to the `config.xml` file when the WebLogic Server 8.1 server is initially booted.
- A new keystore implementation is available in WebLogic Server 8.1. The keystore retrieves trusted certificate authorities, private keys, and server certificates from JDK keystores. Any JDK-supported keystore provider can be used WebLogic Server 8.1; however, the custom WebLogic Keystore Provider introduced in 7.0 is deprecated.

For more information about upgrading to WebLogic Server 8.1 security, see "Security" in Upgrading WebLogic Server 7.0 to Version 8.1 in WebLogic Server 8.1 Upgrade Guide.

### Upgrading to WebLogic Integration 8.1 Security

The security model used by WebLogic Integration has changed significantly in WebLogic Platform 8.1. In version 7.0, WebLogic Integration used Compatibility Security, which is no longer supported in WebLogic Platform. In version 8.1, WebLogic Integration uses the new security model introduced in WebLogic Server 7.0.

See the WebLogic Integration Upgrade Guide for the following topics related to upgrading the security configuration from previous releases of WebLogic Integration:

- Business Process Management: migrating users and roles, organizations, calendars, email, and permissions
- B2B: migrating the keystore, trading partner security information, and the packaging of some Java classes you may be using
- Application Integration: upgrading EIS authentication and authorization and Application View Access Control
- Security API changes
- Mapping ACL information to security policies

### Upgrading to WebLogic Portal 8.1 Security

The security model used by WebLogic Portal has changed significantly in WebLogic Platform 8.1. In version 7.0, WebLogic Portal used Compatibility Security, which is no longer supported in WebLogic Platform. In version 8.1, WebLogic Portal uses the new security model introduced in WebLogic Server 7.0.

See the WebLogic Portal Upgrade Guide for the following notes related to upgrading the security configuration from previous releases of WebLogic Portal:

- Existing WebLogic Portal 7.0 users will be able to continue to leverage their RDBMS user stores by leveraging an SSPI Authentication Provider that will be provided for connecting to a RDBMS.
- Entitlement segments on 7.0 cannot be upgraded because of the change to leveraging the WebLogic Server SSPI. Customers will need to create roles using the WebLogic Administration Portal for entitlements.
- The Unified User Profile is unchanged for 8.1.

### Upgrading to WebLogic Workshop 8.1 Security

If you are upgrading from release 7.0 to 8.1, there are no security-related upgrade requirements. However, there are a number of new security tools and capabilities available, including the following:

- The annotation `@common:security`, which automatically writes role restrictions into the EJB configuration files, eliminating a tedious manual process. This annotation can be used in all Java-derived files (Web services, business process definitions, extensible Java controls, and so on), except Java page flows.

For more information, see An Overview of Role-Based Security in the WebLogic Workshop Help.

- The Security Roles folder, which provides a convenient way to add test users and application-scoped roles for testing your security designs.

For more information, see Creating Principals and Role-Principal Mappings in the WebLogic Workshop Help.

- A new Web Services Security implementation, described in Web Service Security (WS-Security) in the WebLogic Workshop Help.

## Configuring Security Using the Configuration Wizard

When you create a new domain using the Configuration Wizard, you are prompted to specify an administrative username and password for the domain. You can also specify additional security for application resources by defining users, groups, and roles for that domain. For more information about configuring security using the Configuration Wizard, see Configuring Security in Creating WebLogic Configurations Using the Configuration Wizard.

## Configuring Security Administratively Versus Programmatically

One of the most powerful features of WebLogic Platform Security is the flexibility it provides for supporting robustly secure deployments. One important choice you must make when planning your security configuration is whether to implement it administratively, programmatically, or as a combination of the two.

Administrators typically use the administration console to provide security for various resources. For example, instead of requiring developers to modify multiple deployment descriptors when organizational security requirements change, administrators can modify all security configurations from a centralized, graphical user interface. Users, groups, security roles, and security policies can all be defined, modified, and managed using an administration console. As a result, the process of making changes based on updated security requirements becomes more efficient.

Using this technique, you can configure security for all types of WebLogic Platform resources. Therefore, the recommendations in this document for providing security for WebLogic Platform resources are intended specifically for users of the administration consoles.

Developers typically define and enforce roles programmatically. Roles are associated with the deployment descriptor. Later, administrators can always add roles and security policies. The primary benefit of specifying the security for resources such as EJBs and Web applications in their deployment descriptors is that the technique is a widely known and standard method for adding declarative security to those types of applications. This technique may also be the one with which most organizations are familiar. When this technique is used, security roles and policies are specified in the `web.xml`, `weblogic.xml`, `ejb-jar.xml`, and `weblogic-ejb-jar.xml` deployment descriptors.

When choosing the administrative model that works best for you, consider who is responsible for managing security in your organization. Developers are most familiar with the application components they build, but they might not necessarily be familiar with the deployment environment in which those components run. In addition, as security policies change, it is more economical to reconfigure security administratively instead of rebuilding, retesting, and redeploying applications.

## Configuring Security Using the Administration Consoles

The security settings you configure in the WebLogic Server Administration Console are propagated by default to all the platform components. For example, the users and groups you add in the WebLogic Server Administration Console are users of WebLogic Integration, WebLogic Portal, and WebLogic Workshop applications and resources by default. Conversely, as you add users in the WebLogic Integration or WebLogic Portal administration consoles, those users become WebLogic Server users by default.

The purpose of the administration consoles for WebLogic Integration and WebLogic Portal, however, is to configure and manage entities that are specific to those components. The security that you configure for WebLogic Portal and WebLogic Integration resources is visible only from the administration consoles for those components.

Table 2-1 lists the resources you can secure via the administration consoles available in WebLogic Platform.

Table 2-1 Consoles for Configuring Security

Console | Resource Types
--- | ---
WebLogic Server | Users, groups, roles (global and scoped), and security policies. Security providers, such as those that provide authentication, authorization, adjudication, role mapping, credential mapping, and auditing services. Security for WebLogic Server resources, such as Administrative resources, Application resources, EJB resources, URL resources, JDBC resources, JMS resources, and so on. The embedded LDAP server (which serves as the registry, or store, for the authentication and authorization information needed by your application) For a complete list, see Types of WebLogic Resources in Securing WebLogic Resources.
WebLogic Integration | Users, groups, and roles Business processes and business process operations Trading partners, including certificates and transports Message broker channels Process security policies Application views, for application integration For a complete list, see Using WebLogic Integration Security in Deploying WebLogic Integration Solutions.
WebLogic Portal | Users, groups, and roles Delegated administration Visitor entitlements Portals, desktops, shells, books, pages, layouts, look & feels, and portlets Web applications, JSPs, EJBs, and other J2EE resources Content providers Campaigns For a complete list, see Securing Portal Applications in the WebLogic Workshop Help.

Note: You can use any of the administration consoles in WebLogic Platform to define security policies for an application that has been developed in WebLogic Workshop. However, if you redeploy your application from Weblogic Workshop in a development mode server, those security policies will be reset to the policies specified in the deployment descriptors for that application. This does not happen for a production mode server.

## Configuring Your Platform Applications on Multiple Servers, Across Domains, and in Clusters

You may want to configure the applications based on the WebLogic Platform components on different servers within a domain. For example, you might want to manage your WebLogic Portal application independently from your WebLogic Integration, Workshop, and EJB applications. By configuring your WebLogic Portal application in its own server, you can adjust quickly to the needs of your customers and still communicate with your applications.

If your application spans multiple domains, you need to set up a trust relationship among those domains. In a trust relationship, principals from one domain will be accepted as principals in another. The trust relationship is established when the `Credential` attribute of the `SecurityConfigurationMBean` (see the `config.xml` file) in one domain matches the `Credential` attribute on the `SecurityConfigurationMBean` in the other domain. If you boot an administration server for the first time, and the `Credential` attribute is not set, the administration server notices that this attribute is not set and generates a random credential that is then used to sign the principals created in that domain. Other servers in the domain retrieve the credential from the administration server and, therefore, will be able to establish the trust relationship within the domain. (Note that setting up a trust relationship is required only when multiple domains are involved; it is not necessary for multiple servers operating within the same domain.) For more information, see "Enabling Trust Between WebLogic Server Domains" in Configuring Security for a WebLogic Domain in Managing WebLogic Security.

If you want to configure your WebLogic Platform applications in a clustered environment, note that all the servers in a given cluster need to be identical. Therefore, if you want to deploy the servers for one WebLogic Platform component separately from the servers for other WebLogic Platform components, you would target one cluster for one WebLogic Platform component, and another cluster for a different component. For example, you could deploy a WebLogic Integration application in one cluster, and a WebLogic Portal application in another cluster. However, in a clustered domain, the security settings apply uniformly to the entire domain. The difference among the clusters is in how you deploy your application. For more information, see Using WebLogic Server Clusters.

## Customizing the Security Configuration

WebLogic Platform gives you a great deal of flexibility in how you can customize your default security configuration. Some of the ways in which you can customize your security configuration include:

- Replacing the WebLogic security providers with your custom security providers, for example, the authentication provider, authorization provider, or auditing provider
- Changing the default attribute settings for a WebLogic Security provider
- Configuring additional security providers in the default security realm. (For example, if you want to use two Authentication providers—one that uses the embedded LDAP server and one that uses an existing store of users and groups—you would configure them in the default security realm.)

For information, see Customizing the Default Security Configuration and Configuring Security Providers in Managing WebLogic Security.

## Backing Up User Information

BEA strongly recommends that you maintain an archive of your user information in the event of a machine failure or other problem. The following sections describe backing up user information:

- Backing Up User Information in the Embedded LDAP Server
- Backing Up Digital Certificates
- Backing Up Trading Partner Profiles
- Additional Resources on dev2dev

### Backing Up User Information in the Embedded LDAP Server

If you store user information in the embedded LDAP server, WebLogic Platform provides built-in tools that can do the following to either an archive or to another embedded LDAP server:

- Export user information
- Back up the entire security content of an embedded LDAP server

For information about using these tools, refer to the following:

- Managing the Embedded LDAP Server in Managing WebLogic Security
- Backing Up Security Data in Configuring and Managing WebLogic Server

If you are using an external LDAP server, you must use the tools available with that server for backing up stored information about users. You can also use the tools available with your RDBMS to back up the system and user profiles stored by WebLogic Platform.

### Backing Up Digital Certificates

Digital certificates are electronic documents used to identify principals and objects as unique entities over networks such as the Internet. A digital certificate securely binds the identity of a user or object, as verified by a trusted third party known as a certificate authority, to a particular public key. The combination of the public key and the private key provides a unique identity for the owner of the digital certificate.

Once you have obtained private keys, digital certificates, and trusted CA certificates, you need to store them so that WebLogic Server can use them to find and verify identity. Private keys, their associated digital certificates, and trusted CA certificates are stored in keystores. The keystores can be configured through the WebLogic Server Administration Console or specified on the command-line. Use the Keystore Configuration section of the Keystores and SSL page of the WebLogic Server Administration Console to configure Identity and Trust keystores for WebLogic Server.

Note: WebLogic Platform does not provide tools for archiving or restoring digital certificates, so you should make sure you keep backup copies of certificates in the event of a system failure.

### Backing Up Trading Partner Profiles

WebLogic Integration provides a utility that allows you to export and import trading partner profiles, as described in the following topics in Trading Partner Management in Managing WebLogic Integration Solutions:

- "Exporting Management Data"
- "Importing Management Data"

### Additional Resources on dev2dev

Additional resources for use with WebLogic Platform 8.1 can be found at the BEA dev2dev Web site, available at the following URL:

http://dev2dev.bea.com/products/wlplatform81/index.jsp

## Migrating User Information to Another Security Realm or Domain

The WebLogic Security Service supports the ability to export users, groups, and security roles from one security realm, and import them into another—into the same or a new domain. You can migrate security data associated one security provider individually, or migrate all the security data associated with each security provider at once (that is, security data for an entire security realm). You migrate security data through the WebLogic Server Administration Console or by using the `weblogic.Admin` utility.

Migrating security data may be helpful when you must:

- Transition from development mode to production mode
- Move production-mode security configurations to new WebLogic Server domains
- Move data from one security realm to another, within a single WebLogic Server domain, and one or more of the WebLogic Platform security providers is replaced by custom or third-party security providers

If you are migrating security data to another security realm, in either the same or a different domain, note the following:

- The source and target realms must be alike with respect to the type of data store and security providers used. For example, if the source security realm uses the default Authentication provider, the target realm must as well.
- If your security realm uses a custom security provider or LDAP store, you must use migration tools specific to the provider or LDAP store. The built-in WebLogic Server migration tools for security information are supported for only the default set of security providers and the embedded LDAP server.

For more information, see Migrating Security Data in Managing WebLogic Security. For information about using the `weblogic.Admin` utility to migrate security information to another security realm, see "Using the weblogic.Admin Utility" in Migrating Security Data in Managing WebLogic Security.

# Securing a Production Environment

This section discusses considerations for securing the production environment in which WebLogic Platform applications can run. It also provides links to helpful documents about security in a production environment in the documentation for WebLogic Server, WebLogic Integration, WebLogic Portal, and WebLogic Workshop.

## Securing the Production Environment

The WebLogic Server document, Securing a Production Environment, contains several basic tips for providing security in a WebLogic Platform production environment. Specifically, the document offers both general and detailed advice about securing the following key resources:

- WebLogic Server host
- Network connections
- Databases
- WebLogic Security Service
- Applications

## Securing WebLogic Platform Resources

In addition to making your basic application environment secure, we recommend that you provide security for resources that are specific to WebLogic Platform, such as the following:

- Database tables and pools
- Configuration files on disk
- Keystores
- Security realms (embedded LDAP store)
- Thread pools
- J2EE connector resources from WebLogic Integration
- JNDI resources for platform components
- EJBs and Web applications generated through WebLogic Integration

For information about securing these and other WebLogic Platform resources in a production environment, see the following documents.

Table 2-2 Securing WebLogic Platform Resources in a Production Environment

For information about how to secure . . . | See the following documents . . .
--- | ---
WebLogic Server resources | Securing WebLogic Resources
WebLogic Integration resources | "Setting Up a Secure Deployment" in Using WebLogic Integration Security in Deploying WebLogic Integration Solutions
WebLogic Portal resources | Securing Portal Applications and Implementing Authentication in the WebLogic Workshop Help. See also Preparing and Deploying the EAR File in the WebLogic Portal Production Operations User Guide.
Web services created in WebLogic Workshop | Web Service Security (WS-Security) in the WebLogic Workshop Help

## Configuring a Domain for a Production Environment

You should not deploy applications on the Administration Server or expose that server directly to the Internet. When setting up a production system, BEA recommends that you deploy your applications on a domain that is configured with an Administration Server and one or more Managed Servers. This type of domain configuration is recommended for production environments that require the improved availability and performance provided by the built-in failover and load balancing features in a WebLogic Server cluster.

Deploying your applications on Managed Servers gives the added security benefit of insulating the application and its users from the production environment infrastructure. It is also important to avoid making the Administration Server, or any components deployed on it, available outside the enterprise.

Note: The default setting of an option defined in the WebLogic Server Administration Console presents a potential security risk. The option is the "Anonymous Admin Lookup Enabled" option, and by default it is selected. To protect your application, we recommend that you deselect this option when you enter production mode. To find this option in the console, select Domain Wide Security Settings, Configuration and then select the General tab. Remove the checkmark from the box beside "Anonymous Admin Lookup Enabled." Keep in mind, however, that applications that perform anonymous lookup of the administration MBeanHome interface, intentionally or otherwise, might not work correctly when this feature is disabled.

For more information, see the following topics:

- "Deployment Targets" in Overview of WebLogic Server Deployment Deploying WebLogic Server Applications
- "The Administration Server and Managed Servers" in Overview of WebLogic Server System Administration Configuring and Managing WebLogic Server
- "Example: Creating a Domain with Administration Server and Clustered Managed Servers" in Creating and Configuring Domains Using the Configuration Wizard in Configuring and Managing WebLogic Server

## Enabling Security Auditing

Auditing is the process whereby information about operating requests and the outcomes of those requests is collected, stored, and distributed in order to prevent repudiation. In other words, auditing provides an electronic trail of computer activity. In the WebLogic Server security architecture, an Auditing provider is used to provide auditing services.

If configured, the WebLogic Security Framework calls an Auditing provider before and after the performance of security operations (such as authentication or authorization). The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and/or severity levels.

You can use either the WebLogic Auditing provider or a custom Auditing provider in a security realm. Although an Auditing provider is configured per security realm, each server writes auditing data to its own log file in the server directory. By default, all auditing information recorded by the WebLogic Auditing provider is saved in the following file:

`WL_HOME\yourdomain\yourserver``\DefaultAuditRecorder.log`.

By writing a custom Auditing provider, however, you can send the records containing audit information to any one of various output repositories, such as an LDAP server, database, or a simple file.

For information about configuring an Auditing provider and enabling auditing, see "Configuring a WebLogic Auditing Provider" in Configuring Security Providers in Managing WebLogic Security.