Securing WebLogic Server

Customizing the Default Security Configuration

The following sections provide information about customizing the default security configuration and creating a new security realm:

For information about configuring security providers, see Configuring WebLogic Security Providers, and Configuring Authentication Providers.

For information about migrating security data to a new security realm, see Migrating Security Data.

Why Customize the Default Security Configuration?

To simplify the configuration and management of security, WebLogic Server provides a default security configuration. In the default security configuration, myrealm is set as the default (active) security realm, and the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Credential Mapping, Role Mapping, and CertPath providers are defined as the security providers.

Customize the default security configuration if you want to:

Replace one of the WebLogic security providers with a different security provider.
Configure 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 a Windows NT store of users and groups.)
Use an Authentication provider that accesses an LDAP server other than WebLogic Server's embedded LDAP server.
Use an existing store of users and groups (for example, a DBMS database) instead of defining users and groups in the WebLogic Authentication provider.
Add an Auditing provider to the default security realm.
Use an Identity Assertion provider that handles SAML assertions or Kerberos tokens.
Use the Certificate Registry to add certificate revocation to the security realm.
Change the default configuration settings of the security providers.

For information about configuring different types of security providers in a security realm, see see Configuring WebLogic Security Providers, and Configuring Authentication Providers.

The easiest way to customize the default security configuration is to add the security providers you want to the default security realm (myrealm). However, BEA recommends the following procedure to customize the default security configuration:

Create an entirely new security realm.

Configure security providers in the new realm.

Migrate any security data, such as users and groups, from the existing default security realm to the new realm.

Set the new security realm as the default security realm.

The remainder of this section explains describes the configuration decisions that need to be made when creating a new security realm and the main steps used to create a new security realm. Configuring a security realm is only one step in creating a new security configuration; you also need to configure security providers in that realm before in order for the security realm to be valid. For information about configuring different types of security providers in a security realm, see Configuring WebLogic Security Providers, and Configuring Authentication Providers.

Configuration Decisions When Creating a New Security Realm

Before creating a new security realm, you need to make decisions about how the WebLogic Security service will use security information defined in deployment descriptors (DDs), the method for securing URLs and EJBs, and how credential maps will be managed.

When creating a new security realm, consider the following:

Whether or not to set security roles and security policies for Web Applications and EJBs through deployment descriptors or through the WebLogic Administration Console.

The Check Roles and Security Policies option determines how the WebLogic Security Service uses the security information defined in DDs. The option can be set as follows:

Web Applications and EJBs Protected in DD—specifies that the WebLogic Security Service only performs security checks on URL and EJB resources that have security specified in their associated deployment descriptors (DDs). This option is the default Check Roles and Policies setting.
All Web Applications and EJBs—specifies that the WebLogic Security Service performs security checks on all URL (Web) and EJB resources, regardless of whether there are any security settings in the deployment descriptors (DDs) for these WebLogic resources. If you change the setting of the Check Roles and Policies drop-down menu to All Web Applications and EJBs, specify Future Redeploys as specified in Step 2.

How URL and EJB resources are to be secured. The Future Redeploy option determines how these WebLogic resources are to be secured. The option can be set as follows:

To secure URL and EJB resources using only the WebLogic Administration Console, select the Ignore Roles and Policies From DD (Deployment Descriptors) option.
To secure URL and EJB resources using only the deployment descriptors (that is, the ejb-jar.xml, weblogic-ejb-jar.xml, web.xml, and weblogic.xml files), select Initialize roles and policies from DD option.

How to create and manage credential maps. You can load credential maps from a resource adapter's deployment descriptor file (weblogic-ra.xml) into the embedded LDAP server and then use the WebLogic Administration Console to create new credential maps, or directly modify credential maps defined in the deployment descriptor.

Once information from a weblogic-ra.xml deployment descriptor file is loaded into the embedded LDAP server, the original resource adapter remains unchanged. Therefore, if you redeploy the original resource adapter (which will happen if you redeploy it through the WebLogic Administration Console, modify it on disk, or restart WebLogic Server), the data will once again be imported from the weblogic-ra.xml deployment descriptor file and new credential mapping information may be lost.

Whether or not to use the Web resource.

The Web resource is deprecated in this release of WebLogic Server. If you are configuring a custom Authorization provider that uses the Web resource (instead of the URL resource) in the new security realm, enable Use Deprecated Web Resource on the new security realm. This option changes the runtime behavior of the Servlet container to use a Web resource rather than a URL resource when performing authorization.

Note: When creating a new security realm, at least one of the configured Authentication providers must return asserted LoginModules. Otherwise, run-as tags defined in deployment descriptors will not work.

For more information, see Configure new security realms in the Administration Console online help.

Creating a New Security Realm: Main Steps

To create a new security realm:

Define a name and set the configuration options for the security realm. See Configuration Decisions When Creating a New Security Realm and Configure new security realms in the Administration Console online help.

Configure the required security providers for the security realm. A valid security realm requires an Authentication provider, an Authorization provider, an Adjudication provider, a Credential Mapping provider, and a Role Mapping provider. Otherwise, you will not be able to set the new security realm as the default security realm. See Configuring WebLogic Security Providers, and Configuring Authentication Providers.

Optionally, define Identity Assertion, Auditing, and Cert Registry providers. See Configuring WebLogic Security Providers, and Configuring Authentication Providers.

If you configured the WebLogic Authentication, Authorization, Credential Mapping or Role Mapping provider or the Certificate Registry in the new security realm, verify that the settings of the embedded LDAP server are appropriate. See Managing the Embedded LDAP Server.

Optionally, configure caches to improve the performance of the WebLogic or LDAP Authentication providers in the security realm. See Improving the Performance of WebLogic and LDAP Authentication Providers.

Protect WebLogic resources in the new security realm with security policies. Creating security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources. This document should be used in conjunction with Securing WebLogic Server to ensure security is completely configured for a WebLogic Server deployment.

Protect user accounts in the new security realm from dictionary attacks by setting lockout attributes. See Protecting User Accounts and Protect user accounts in the Administration Console online help.

Set the new realm as the default security realm for the WebLogic domain. See Change the default security realm in the Administration Console online help.

Note that you can also use the WebLogic Scripting Tool or Java Management Extensions (JMX) APIs to create a new security configuration. For information more information, see WebLogic Scripting Tool.