Security in WebLogic Platform 8.1
|
 |
 |
|
 |
 |
The following sections provide a high-level view of the tasks associated with managing WebLogic Platform security:
This section discusses the following topics:
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.
If you are upgrading WebLogic Server 7.0 to 8.1, note the following changes regarding the security system:
config.xml file. Existing security configuration data is written to the config.xml file when the WebLogic Server 8.1 server is initially booted.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.
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:
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:
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:
@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.
For more information, see Creating Principals and Role-Principal Mappings in the WebLogic Workshop Help.
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.
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.
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.
For a complete list, see Types of WebLogic Resources in Securing WebLogic Resources. |
|
|
For a complete list, see Using WebLogic Integration Security in Deploying WebLogic Integration Solutions. |
|
|
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.
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.
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:
For information, see Customizing the Default Security Configuration and Configuring Security Providers in Managing WebLogic Security.
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:
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:
For information about using these tools, refer to the following:
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.
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.
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:
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
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:
If you are migrating security data to another security realm, in either the same or a different domain, note the following:
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.
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.
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:
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:
For information about securing these and other WebLogic Platform resources in a production environment, see the following documents.
|
"Setting Up a Secure Deployment" in Using WebLogic Integration Security in Deploying WebLogic Integration Solutions |
|
|
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 Service Security (WS-Security) in the WebLogic Workshop Help |
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:
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.
|
|
|