Customizing the Default Security Configuration

The following sections provide information about customizing the default security realm, creating a new security realm, and setting a security realm as the default (active) security realm.

 

Why Customize the Default Security Configuration?

To simplify the configuration and management of security in WebLogic Server, a default security configuration is provided. In the default security configuration, myrealm is set as the default (active) security realm and the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Credential Mapping, and Role Mapping 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 custom 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 an existing store of users and groups.)

  • Use an Authentication provider that accesses an LDAP server other than the embedded LDAP server.

  • Use an existing store of users and groups instead of defining users and groups in the WebLogic Authentication provider.

  • Add an Auditing provider to the default security realm.

  • Upgrade from Compatibility security to the security providers in this release of WebLogic Server.

  • Change the default attribute settings of the security providers.

The easiest way to customize the default security configuration is to modify the default security realm (myrealm) to contain the security providers you want.

However, you can also customize the default security configuration by creating a new security realm, configuring security providers in that realm, and setting the new security realm as the default security realm. BEA recommends this process when upgrading a security configuration.

The remainder of this chapter explains how to create a new security realm and set that security realm as the default (active) security realm.

 

Creating a New Security Realm

To create a new security realm:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms node.

    All security realms available for the WebLogic domain are listed in the Realms table.

  2. Click the Configure a new Realm... link.

  3. In the Name attribute on the General tab, enter the name of the new security realm.

  4. Set the Check Roles and Security Policies attribute. The following options are available:

    • 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 the Future Redeploys attribute as described in Step 6.

  5. Use the Future Redeploys attribute to tell WebLogic Server how URL and EJB resources are to be secured:

  6. You have the option of loading credential maps from weblogic-ra.xml deployment descriptor files into the embedded LDAP server and then using the WebLogic Server Administration Console to create new credential maps, or 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 Server 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.

    To avoid overwriting new credential mapping information with old information in a weblogic-ra.xml deployment descriptor file, enable the Ignore Deploy Credential Mapping attribute on the new security realm.

  7. 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 the Use Deprecated Web Resource attribute on the new security realm. This attribute changes the runtime behavior of the Servlet container to use a Web resource rather than a URL resource when performing authorization.

  8. Click Create.

  9. 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.

  10. Optionally, define Identity Assertion and Auditing providers.

  11. If you configured the WebLogic Authentication, Authorization, Credential Mapping or Role Mapping provider in the new security realm, verify the default attribute settings of the embedded LDAP server.

  12. 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 Managing WebLogic Security to ensure security is completely configured for a WebLogic Server deployment.

  13. Protect user accounts in the new security realm.

  14. Test the new security realm to ensure it is valid.

  15. Set the new realm as the default security realm for the WebLogic domain.

  16. Reboot WebLogic Server.

 

Testing a New Security Realm

Configuring a new security realm is a complicated task. If you configure a security realm incorrectly, you cannot set the security realm as the default security realm. WebLogic Server can validate the configuration of a security realm to ensure it is correct.

To validate the configuration of a new security realm:

  1. Configure the security realm as described in Creating a New Security Realm.

  2. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.

    The Realms table shows all security realms configured for the WebLogic Server domain.

  3. Select the realm you want to validate.

  4. Select the Testing tab.

  5. Click the Validate this realm... link.

    Any problems with the configuration of the security realm are displayed on the Testing page.

 

Setting a New Security Realm as the Default (Active) Security Realm

After you define attributes on the new security realm, configure the security providers for the security realm and ensure the configuration of the new security realm is valid, set the new security realm as the default (active) security realm.

To set the new security realm as the default (active) security realm:

  1. In the left pane of the WebLogic Server Administration Console, expand the node representing a domain (for example, Examples).

  2. Click the View Domain-wide Security Settings link.

  3. Select the General tab.

    The pull-down menu forthe Default Realm attribute displays the security realms configured in the WebLogic Server domain.

    Note: If you create a new security realm but do not configure the minimun required security providers in the security realm, the realm will not be available from the pull-down menu.

  4. Select the security realm you want to set as the default security realm.

  5. Click Apply.

  6. Reboot WebLogic Server. If you not reboot WebLogic Server, the new realm is not set as the default security realm.

To verify you set the default security realm correctly:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.

    The Realms table shows all realms configured for the WebLogic Server domain. The default (active) security realm has the Default Realm attribute set to true.

 

Deleting a Security Realm

When you delete a security realm, the user, group, security role, security policy, and credential map information is not deleted from the embedded LDAP server. Use an external LDAP browser to delete any unnecessary entries from the embedded LDAP server.

To delete a security realm:

  1. In the left pane of the WebLogic Server Administration Console, expand the Security-->Realms nodes.

    The Realms table shows all realms configured for the WebLogic domain.

  2. In the table row for the security realm you want to delete, click the trash can icon.

  3. Click Yes in response to the following question:

    Are you sure you want to permanently delete OldRealm from the domain configuration?

    A confirmation message appears when the security realm is deleted.

 

Reverting to a Previous Security Configuration

It is easy to make a mistake when configuring a new security realm or security providers. A mistake may make it impossible to boot the server or correct the mistake. Reverting the config.xml file will reinstate the previous realm configuration.

By default, the Administration Server archives up to 5 previous versions of the config.xml files in the domain-name/configArchive directory. To revert to a previous security configuration:

  1. Copy all the archived copies to a temporary directory.

  2. Copy one of the archived config.xml files to the domain directory you are currently using. The archived files are rotated so that the newest file has a suffix with the highest number.

  3. Reboot WebLogic Server.

Note this process will only revert your security realm (meaning, the realm and its providers) not users, groups, roles, or security policies. You will have to reconfigure the security realm and its providers, the user, groups, role, and security policies still exist.

Skip navigation bar  Back to Top Previous Next