Security

 

Overview

This topic describes configuring and managing security in this release of WebLogic Server.

For information about configuring and managing security for WebLogic Server deployments using Compatibility security, see Compatibility Securityand Using Compatibility Security

 

Tasks

The Default Security Configuration in WebLogic Server

To simplify the configuration and management of security in WebLogic Server, a default security realm (myrealm) is provided. The default security realm has WebLogic Authentication, Identity Assertion, Authorization, Adjudication, Role Mapping, and Credential Mapping providers configured.

When using the default security configuration, you only need to define groups, users, and security roles for the security realm and create security policies for the WebLogic resources in the domain. You also need to verify that the configuration of the embedded LDAP server configuration is appropriate for your use. Optionally, you can configure an Auditing provider for the default realm.

If the default security configuration does not meet your requirements, you can create a new security realm with any combination of WebLogic and custom security providers and then set the new security realm as the default security realm.

 

Define Groups

This section applies to Authentication providers that implement the GroupReader Security Service Provider Interface (SSPI) (for example, the WebLogic Authentication provider). If the Authentication provider you are using does not implement this SSPI, you cannot manage users through the WebLogic Server Administration Console.

User and group names must be unique. BEA recommends using initial capitalization and plural names for groups; for example, Administrators.

To define a group:

  1. Expand...

    Security | Realms | realmname | Groups

    The Groups table appears.

    This table displays the names of all groups defined in the Authentication provider configured in the security realm.

  2. Click...

    Configure a New Group | Groups | General

  3. Enter the name of the group.

  4. Enter a short description of the group (for example, Product Managers for Code Examples).

  5. Click Apply to save your changes.

  6. Click the Membership tab to add existing groups to the new group.

    • All available groups appear in the Possible Groups table.

    • All the groups currently defined for a group appear in the Current Groups table.

    To add a group to another group, highlight the desired group name and click the right arrow to move the group name to the Current Groups table.

  7. Click Apply to save your changes.

 

Delete Groups

To delete a group:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Groups.

    The Groups table appears. This table displays the names of all groups defined in the Authentication provider configured in the security realm.

  4. To delete a group, click the trash can icon in the corresponding row of the Groups table.

 

Define Users

Note: This section applies to Authentication providers that implement the UserEditor SSPI (for example, the WebLogic Authentication provider). If the Authentication provider you are using does not implement the UserEditor SSPI, you cannot manage users through the WebLogic Server Administration Console.

User and group names must be unique. Do not define a group and a user with the same name. Be sure that there are no spaces or < > characters in the user name. User names are case sensitive.

Do not use the username/password combination weblogic/weblogic in production.

To define a user:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Users.

    The Userstable appears. This table displays the names of all users defined in the Authentication provider.

  4. Click the Configure a New User... link.

  5. On the User-->General page, enter the name of the user.

  6. Enter a password for the user.

Note: The minimum password length for a user defined in the WebLogic Authentication provider is 8 characters. However, password rules (for example, length and type of characters) vary by Authentication provider.

  1. Re-enter the password for the user in the Confirm Password field.

  2. Click Apply to save your changes.

    For more efficient management, BEA recommends adding users to groups.

  3. Click the Groups tab.

  4. In the Possible Groups list box, click the name of a group to highlight it.

  5. Click the right arrow to move the group to the Current Groups list box.

  6. If desired, repeat steps 6 and 7 to add the user to multiple groups.

  7. Click Apply to save your changes.

 

Delete Users

To delete a user:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Users.

    The Users table appears. This table displays the names of all users defined in the Authentication provider.

  4. To delete a user, click the trash can icon in the corresponding row of the Users table.

 

Change the Password of a User

Note that the minimum password length for a user defined in the WebLogic Authentication provider is 8 characters. However, password rules (for example, length and type of characters) vary by Authentication provider.

To change the password of a user:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Users.

  4. Select a user.

  5. Click the Change... link in the Password attribute.

  6. Enter a password for the user.

  7. Click Apply.

 

Protecting User Accounts

Weblogic Server provides a set of attributes to protect user accounts from intruders. By default, these attributes are set for maximum protection. As a system administrator, you have the option of turning off all the attributes, increasing the number of login attempts before a user account is locked, increasing the time period in which invalid login attempts are made before locking the user account, and changing the amount of time a user account is locked. Remember that changing the attributes lessens security and leaves user accounts vulnerable to security attacks.

To set the User Lockout attributes:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Select the User Lockout tab.

  4. Configure the attributes on this page by entering values at the appropriate prompts and selecting the required checkboxes.

  5. To save your changes, click Apply.

  6. Reboot WebLogic Server.

 

Unlocking a User Account

To unlock a user account:

  1. Expand the Servers-->Monitoring tab.

  2. Click the Security tab.

  3. Enter the user name for a user of this server who has been locked out in the Unlock User attribute.

  4. Click Apply.

    If the unlock was successful, a confirmation message appears at the top of the Monitoring-->Security page.

 

Define Global Roles

A security role that applies to all WebLogic resources deployed within a security realm (and thus the entire WebLogic Server domain) is called a global role.

This topic highlights the process for creating global roles. However, creating global roles is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources.

Note: BEA recommends using initial capitalization, singular names for global roles; for example, SecurityEng.

To define a global role:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Roles.

    The Select Rolespage appears. This page displays all the global roles currently defined in the WebLogic Role Mapping provider's database.

  4. Click the Configure a New Role... link.

    The Create Role page appears.

  5. On General page, enter the name of the global role in the Name field.

    Notes: Be sure that there are no spaces or < > characters in the security role name. Security role names are case sensitive. The BEA convention is that all security role names are singular.

  6. Click the Apply button to save your changes.

  7. Click the Conditions tab.

  8. In the Role Condition list box, click one of the conditions.

    Note: BEA recommends that you create expressions using the Caller is a Member of the Group condition. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

  9. Click the Add button. A customized window appears.

  10. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, and then click the OK button.

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, and then click the Add button.

      Note: You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      The Move Up and Move Down buttons change the ordering of the highlighted user or group name. The Change button switches the highlighted and and or statements between expressions. The Remove button deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement.

  11. If desired, repeat steps 8-10 to add expressions based on different role conditions.

  12. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • The Move Up and Move Down buttons change the ordering of the highlighted expression.

    • The Change button switches the highlighted and and or statements between expressions.

    • The Edit... button reopens the customized window for the highlighted expression and allows you to modify the expression.

    • The Remove button deletes the highlighted expression.

  13. When all the expressions in the Role Statement list box are correct, click the Apply button.

    Note: Clicking the Reset button will delete all expressions shown in the Role Statement list box.

 

Deleting Global Roles

To delete a global role:

  1. Expand the Security -->Realms nodes.

  2. Click the name of the realm you are configuring (for example, myrealm).

  3. Click Roles.

    The Select Rolespage appears. This page displays all the global roles currently defined in the WebLogic Role Mapping provider's database.

  4. To delete a role, click the trash can icon in the corresponding row of the Select Roles page.

    A confirmation window appears.

  5. Click Yes to delete the global role.

 

Define Scoped Roles

A security role that applies to a specific instance of a WebLogic resource deployed in a security realm (such as a method on an EJB or a branch of a JNDI tree) is called a scoped role. The procedure for creating scoped roles differs slightly, depending on the type of WebLogic resource and level at which you want to scope the security role. Use the appropriate instructions provided in the following sections:

 

URL (Web) Resources

To create a scoped role for a URL (Web) resource, follow these steps:

  1. Using the navigation tree at the left side of the WebLogic Server Administration Console, click the + sign next to Deployments.

    The Deployments node expands to show the types of WebLogic resources that can be deployed.

  2. Click the right mouse button at the level of the URL (Web) resource at which you want to create the scoped role.

    A menu of options appears.

    • To create a scoped role for all Web applications (WARs), click the right mouse button on Web Applications.

    • To create a scoped role for a particular WAR or a component in a WAR (for example, a specific servlet or JSP), click the + sign next to Web Applications, then click the right mouse button on the name of a Web application (WAR).

  3. If you are creating the scoped role for all Web applications (WARs), select the Define Role... option.

    If you are creating the scoped role for a particular WAR, or a component within a WAR, follow these steps:

    1. Select the Define Role... option.

      The General page appears.

    2. Enter a URL pattern in the text field.

      A URL pattern is a path to a specific component within a Web application. Or, you can use /* to associate the scoped role with all components (servlets, JSPs, and so on) within the Web application.

    3. Click the Define Role... button to proceed. The Select Roles page appears. If any are available, this page displays the scoped roles that are currently defined for this WebLogic resource in the WebLogic Role Mapping provider's database.

  4. Click the Configure a New Role... link.

    The Create Role page appears

  5. On General page, enter the name of the scoped role in the Name field.

    Notes: Be sure that there are no spaces or < > characters in the security role name. Role names are case sensitive. The BEA convention is that all security role names are singular.

    Warning: If you create a scoped role with the same name as a global role, the scoped role takes precedence over the global role.

  6. Click the Apply button to save your changes.

  7. Click the Conditions tab.

    The Role Editor page appears.

  8. In the Role Condition list box, click one of the conditions.

    Note: BEA recommends that you create expressions using the Caller is a Member of the Group condition. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

  9. Click the Add button.

  10. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, and then click the OK button.

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, and then click the Add button.

      Note: You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      The Move Up and Move Down buttons change the ordering of the highlighted user or group name. The Change button switches the highlighted and and or statements between expressions. The Remove button deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement.

  11. If desired, repeat steps 8 - 10 to add expressions based on different role conditions.

  12. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • The Move Up and Move Down buttons change the ordering of the highlighted expression.

    • The Change button switches the highlighted and and or statements between expressions.

    • The Edit... button reopens the customized window for the highlighted expression and allows you to modify the expression.

    • The Remove button deletes the highlighted expression.

  13. When all the expressions in the Role Statement list box are correct, click the Apply button.

    Note: Clicking the Reset button will delete all expressions shown in the Role Statement list box.

 

Enterprise JavaBean (EJB) Resources

To create a scoped role for an EJB resource, follow these steps:

  1. Using the navigation tree at the left side of the WebLogic Server Administration Console, click the + sign next to Deployments.

    The Deployments node expands to show the types of WebLogic resources that can be deployed.

  2. Click the right mouse button at the level of the EJB resource for which you want to create the scoped role. .

    To create a scoped role for all EJB JARs, click the right mouse button on EJB. To create a scoped role for a particular EJB JAR, or for an EJB within a JAR, click the + sign next to EJB, then click the right mouse button on the name of an EJB JAR.

  3. If you are creating the scoped role for all EJB JARs or for a particular EJB JAR, select the Define Role... option.

    The Select Roles page appears. If any are available, this page displays the scoped roles that are currently defined for this WebLogic resource in the WebLogic Role Mapping provider's database.

    If you are creating the scoped for a particular EJB within an EJB JAR, follow these steps:

    1. Select the Define Policies and Roles for Individual Beans... option. A list of EJBs appears.

    2. Click the [Define Roles] link that is located in the same row as the particular EJB for which you want to create the scoped role. The Select Roles page appears. If any are available, this page displays the scoped roles that are currently defined for this WebLogic resource in the WebLogic Role Mapping provider's database.

  4. Click the Configure a New Role... link.

    The Create Role page appears

  5. On General page, enter the name of the scoped role in the Name field.

    Notes: Be sure that there are no spaces or < > characters in the security role name. Security role names are case sensitive. The BEA convention is that all security role names are singular.

    Warning: If you create a scoped role with the same name as a global role, the scoped role takes precedence over the global role.

  6. Click the Apply button to save your changes.

  7. Click the Conditions tab.

    The Role Editor page appears.

  8. In the Role Condition list box, click one of the conditions.

    Note: BEA recommends that you create expressions using the Caller is a Member of the Group condition. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

  9. Click the Add button.

  10. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, and then click the OK button.

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, and then click the Add button.

      Note: You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      The Move Up and Move Down buttons change the ordering of the highlighted user or group name. The Change button switches the highlighted and and or statements between expressions. The Remove button deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement.

  11. If desired, repeat steps 8 - 10 to add expressions based on different role conditions.

  12. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • The Move Up and Move Down buttons change the ordering of the highlighted expression.

    • The Change button switches the highlighted and and or statements between expressions.

    • The Edit... button reopens the customized window for the highlighted expression and allows you to modify the expression.

    • The Remove button deletes the highlighted expression.

  13. When all the expressions in the Role Statement list box are correct, click the Apply button.

    Note: Clicking the Reset button will delete all expressions shown in the Role Statement list box.

 

JNDI Resources

To create a scoped role for a JNDI resource, follow these steps:

  1. Using the navigation tree at the left side of the WebLogic Server Administration Console, click the + sign next to Servers.

    The Servers node expands to show the servers available in the current WebLogic Server domain.

  2. Click the right mouse button on the name of the server that contains the JNDI resource for which you want to create the scoped role. (For example, myserver.)

  3. Select the View JNDI Tree option.

  4. Click the right mouse button at the level of the JNDI tree at which you want to create the scoped role.

  5. Select the Define Role... option.

  6. Click the Configure a New Role... link.

    The Create Role page appears. If any are available, this page displays the scoped roles that are currently defined for this WebLogic resource in the WebLogic Role Mapping provider's database.

  7. On General page, enter the name of the scoped role in the Name field.

    Notes: Be sure that there are no spaces or < > characters in the security role name. Security role names are case sensitive. The BEA convention is that all security role names are singular.

    Warning: If you create a scoped role with the same name as a global role, the scoped role takes precedence over the global role.

  8. Click the Apply button to save your changes.

  9. Click the Conditions tab. The Role Editor page appears.

  10. In the Role Condition list box, click one of the conditions.

    Note: BEA recommends that you create expressions using the Caller is a Member of the Group condition. When a group is used to create a security role, the security role can be granted to all members of the group (that is, multiple users).

  11. Click the Add button.

  12. If you selected the Hours of Access are Between condition, use the Time Constraint window to select start and end times, and then click the OK button.

    If you selected one of the other conditions, follow these steps:

    1. Use the Users or Groups window to enter the name of a user or group, and then click the Add button.

      Note: You can repeat this step multiple times to add more than one user or group.

    2. If necessary, use the buttons located to the right of the list box to modify the expressions.

      The Move Up and Move Down buttons change the ordering of the highlighted user or group name. The Change button switches the highlighted and and or statements between expressions. The Remove button deletes the highlighted user or group name.

    3. Click OK to add the expression to the role statement.

  13. If desired, repeat steps 10 - 12 to add expressions based on different role conditions.

  14. If necessary, use the buttons located to the right of the Role Statement list box to modify the expressions:

    • The Move Up and Move Down buttons change the ordering of the highlighted expression.

    • The Change button switches the highlighted and and or statements between expressions.

    • The Edit... button reopens the customized window for the highlighted expression and allows you to modify the expression.

    • The Remove button deletes the highlighted expression.

  15. When all the expressions in the Role Statement list box are correct, click the Apply button.

    Note: Clicking the Reset button will delete all expressions shown in the Role Statement list box.

 

Other Types of WebLogic Resources

With the exception of Web Services resources, you can create scoped roles for the other types of WebLogic resources using the WebLogic Server Administration Console. However, not all WebLogic resource types are listed under the Deployments node in the WebLogic Server Administration Console's navigation tree, and not all of the WebLogic resource types allow scoped roles to be created at the same levels in the resource hierarchy. JDBC connection pools, for example, are shown under the Services - >JDBC node, and scoped roles for JMS resources may only be created at the Services - >JMS node. Therefore, you will need to adapt the instructions provided in the previous sections to create scoped roles for other WebLogic resource types, as the process for accomplishing this task differs only in small ways.

 

Delete Scoped Roles

To delete a scoped role, follow these steps:

  1. Navigate to the Select Roles page for your WebLogic resource.

    This page displays all the scoped roles currently defined in the WebLogic Role Mapping provider's database.

  2. Click the trash can icon that is located in the same row as the scoped role you want to delete.

  3. Click the Yes button.

Click the Continue link.

 

Protecting WebLogic Resources

Security policies are used to protect WebLogic resources. A security policy is created when you define an association between between a WebLogic resource and a user, group, or security role. You can also optionally associate a time constraint with a security policy. A WebLogic resource has no protection until you assign it a security policy.

Create security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources.

 

Configuring the Embedded LDAP Server

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. The WebLogic Authentication, Authorization, Credential Mapping, and Role Mapping providers use the embedded LDAP server as their database. If you use any of these providers in a new security realm, you may want to change the default values for the embedded LDAP server to optimize its use in your environment.

To configure the embedded LDAP server:

  1. Expand the Domain node (for example, Examples).

  2. Click the View Domain-Wide Security Settings link on the Domain-->General page.

  3. Select the Security Configuration-->Embedded LDAP tab.

  4. Set attributes on the Embedded LDAP Server page.

  5. Click Apply to save your changes.

  6. Reboot WebLogic Server.
Note that the WebLogic Security providers stored their data in the embedded LDAP server. When you delete a WebLogic Security provider, the security data in the embedded LDAP server is not automatically deleted. The security data remains in the embedded LDAP server in case you want to use the provider again. Use an external LDAP browser to delete the security data from the embedded LDAP server.

 

Configuring Backups for the Embedded LDAP Server

To configure the backups of the embedded LDAP server:

  1. Expand the Domain node (for example, Examples).

  2. Click the View Domain-Wide Security Settings link on the Domain-->General page.

  3. Click the Security Configuration-->the Embedded LDAP tab.

  4. Set the Backup Hour, Backup Minute, and Backup Copies attributes on the Embedded LDAP Server page.

  5. Click Apply to save your changes.

  6. Reboot WebLogic Server.

 

Configuring a New Security Realm

To configure a new security realm:

  1. Expand the Security node.

  2. Expand the Realms node.

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

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

  4. Enter the name of the new security realm in the Name attribute on the General page.

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

    • Web Applications and EJBs Protected in DD - This option 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 - This option 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.

  6. Use the Future Redeploys attribute to tell WebLogic Server how URL and EJB resources are to be secured. The following options are provided:

    • To secure URL and EJB resources using only the WebLogic Server 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.

  7. 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 existing credential maps.

    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 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 Security Data in Deployment Descriptors attribute.

    To use load credential maps into the embedded LDAP server, the Credential Mapping provider in the security realm must have the Credential Mapping Deployment Enabled attribute checked.

  8. The Web resource was deprecated in a previous release of WebLogic Server. If you wrote a custom Authorization provider that uses the Web resource (instead of the URL resource), enable the Use Deprecated Web Resource attribute. This attribute changes the runtime behavior of the Servlet container to use a Web resource rather than a URL resource when performing authorization.

  9. Click Create.

  10. Configure the required security providers for the security realm. In order for a security realm to be valid, configure 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.

  11. Optionally, define an Identity Assertion and Auditing provider.

  12. Define groups and users for the security realm.

  13. Grant users and groups in the security realm roles.

  14. Protect WebLogic resources in the security realm with security policies.

  15. Reboot WebLogic Server. If you do not reboot WebLogic Server, you cannot set the realm to the default security realm.

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

 

Testing a New Security Realm

Configuring a new security realm is a complicated task. If you configure a security realm incorrectly, you will not be able to 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 Configuring a New Security Realm.

  2. Expand the Security-->Realms nodes.

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

  3. Click the realm you want to validate.

  4. Click 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.

 

Configuring an Authentication Provider: Main Steps

WebLogic Server offers the following types of Authentication providers:

Note: You are not limited to these LDAP Authentication providers. To use an LDAP server other than the supported LDAP servers, choose the LDAP server type that has the closest defaults to the LDAP server you want to use and modify the attribute values accordingly.

In addition, you can use a Custom Authentication provider which offers different types of authentication technologies.

Note that the WebLogic Server Administration Console refers to the WebLogic Authentication provider as the Default Authenticator.

Each security realm must have one at least one Authentication provider configured. The WebLogic Security Framework is designed to support multiple Authentication providers (and thus multiple LoginModules) for multipart authentication. Therefore, you can use multiple Authentication providers as well as multiple types of Authentication providers in a security realm. The Control Flag attribute determines how the LoginModule for each Authentication provider is used in the authentication process.

To configure an Authentication provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose an Authentication provider by selecting the appropriate link.

    • Configure a new Active Directory Authenticator...
    • Configure a new Realm Adapter Authenticator...
    • Configure a new Novell Authenticator...
    • Configure a new iPlanet Authenticator...
    • Configure a new Default Authenticator...
    • Configure a new OpenLDAP Authenticator...

  5. Go to the appropriate sections to configure an Authentication provider.

  6. Repeat these steps to configure additional Authentication providers.

    If you are configuring multiple Authentication providers, refer to Setting the JAAS Control Flag.

  7. After you finish configuring Authentication providers, reboot WebLogic Server.

 

Setting the JAAS Control Flag

If a security realm has multiple Authentication providers configured, the Control Flag attribute on the Authenticator-->General page determines the ordered execution of the Authentication providers. The values for the Control Flag attribute are as follows:

REQUIRED The Authentication provider is always called, and the user must always pass its authentication test.
REQUISITE If the user passes the authentication test of this Authentication provider, other providers are executed but can fail (except for Authentication providers with the JAAS Control Flag set to REQUIRED).
SUFFICIENT If the user passes the authentication test of the Authentication provider, no other Authentication providers are executed (except for Authentication providers with the JAAS Control Flag set to REQUIRED) because the user was sufficiently authenticated.
OPTIONAL TThe user is allowed to pass or fail the authentication test of this Authentication provider. However, if all Authentication providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

The order in which the Authentication providers are configured is the order in which in the LoginModules for the Authentication providers are called. The ordering of the Authentication providers can be changed at any time.

Notes: If you define multiple Authentication providers, in order to boot WebLogic Server, the user from which the server is booted must be defined as a user in all the Authentication providers than have the Control Flag attribute set to REQUISITE or REQUIRED.

The WebLogic Server Administration Console actually sets the JAAS Control Flag to OPTIONAL when creating a security provider. MBeans for the security providers actually default to REQUIRED.

 

Configuring the WebLogic Authentication Provider

Note that the WebLogic Server Administration Console refers to the WebLogic Authentication provider as the Default Authenticator.

The WebLogic Authentication provider is case insensitive. Ensure user names are unique.

The WebLogic Authentication provider allows you to edit, list, and manage users and group membership. User and group membership information for the WebLogic Authentication provider is stored in the embedded LDAP server.

To configure the WebLogic Authentication provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose the Configure a new Default Authenticator... link.

  5. Define values for the attributes on the General page.

  6. Click Apply to save your changes.

  7. Define values on the Details page.

  8. Optionally, configure additional Authentication providers.

  9. Reboot WebLogic Server.

 

Configuring an LDAP Authentication Provider

To configure an LDAP Authentication provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose an LDAP Authentication provider from the following available links:

    • Configure a new Active Directory Authenticator...

    • Configure a new Novell Authenticator...

    • Configure a new OpenLDAP Authenticator...

    • Configure a new iPlanet Authenticator...

  5. If you using multiple Authentication providers, define a value for the Control Flag attribute on the General page.

  6. Click Apply to create a new LDAP Authentication provider.

  7. Proceed to Setting LDAP Server and Caching Information.

 

Setting LDAP Server and Caching Information

To set LDAP server and caching information:

  1. Click the LDAP tab under the Configuration tab for the LDAP Authentication provider you want to use.

    For example, click the iPlanet LDAP tab under the iPlanet Configuration tab.

  2. Enable communication between WebLogic Server and the LDAP server by defining values for the attributes shown on the LDAP page.

  3. To save your changes, click Apply.

  4. Click the Details tab to configure additional attributes that control the behavior of the LDAP server. The following attributes are available:

    • Follow Referrals - Specifies that a search for a user or group within the Active Directory Authentication provider will follow referrals to other LDAP servers or branches within the LDAP directory. By default, this attribute is enabled.

    • Bind Anonymously On Referrals - By default, an LDAP Authentication provider uses the same DN and password used to connect to the LDAP server when following referrals during a search. If you want to connect as an anonymous user, enable this attribute. Contact your LDAP system administrator for more information.

    • Results Time Limit - The maximum number of milliseconds for the LDAP server to wait for results before timing out. If this attribute is set to 0, there is not maximum time limit. The default is 0.

    • Connect Timeout - The maximum time in seconds to wait for the connection to the LDAP server to be established. If this attribute is set to 0, there is not a maximum time limit. The default is 0.

    • Parallel Connect Delay - The delay in seconds when making concurrent attempts to attempt to multiple LDAP servers. If this attribute is set to 0, connection attempts are serialized. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. If this attribute is not set and an LDAP server is unavailable, an application may be blocked for a long time. If this attribute is greater than 0, another connection is started after the specified time.

  5. To save your changes, click Apply.

  6. Proceed to Locating Users in the LDAP Directory.

For a more secure deployment, BEA recommends using the SSL protocol to protect communications between the LDAP server and WebLogic Server.

 

Locating Users in the LDAP Directory

To specify how users are located in the LDAP directory:

  1. Click the Users tab under the Configuration tab for the LDAP server you chose.

    For example, click the Users tab under the iPlanet Configuration tab.

  2. Define information about how users are stored and located in the LDAP directory by defining values for the attributes shown on the Users page.

  3. To save your changes, click Apply.

  4. Proceed to Locating Groups in the LDAP Directory.

 

Locating Groups in the LDAP Directory

To specify how groups are stored and located in the LDAP directory:

  1. Click the Groups tab under the Configuration tab.

    For example, click the Groups tab under the iPlanet Configuration tab.

  2. Define information about how groups are stored and located in the LDAP directory by defining values for the attributes shown on the Groups page.

  3. To save your changes, click Apply.

  4. Proceed to Locating Members of a Group in the LDAP Directory.

 

Locating Members of a Group in the LDAP Directory

Note that the iPlanet Authentication provider supports dynamic groups. To use dynamic groups, set the Dynamic Group Object Class, Dynamic Group Name Attribute, and Dynamic Member URL Attribute attributes on the Members page.

To specify how groups members are stored and located in the LDAP directory:

  1. Click on the Membership tab under the Configuration tab.

    For example, click the Membership tab under the iPlanet Configuration tab.

  2. Define information about how group members are stored and located in the LDAP directory by defining values for the attributes shown on the Membership page.

  3. To save your changes, click Apply.

  4. Optionally, configure additional Authentication and/or Identity Assertion providers.

  5. Reboot WebLogic Server.

 

Configuring Failover for LDAP Authentication Providers

To configure failover of the LDAP servers configured for an LDAP Authentication provider, perform the following steps:

  1. Click the LDAP tab under the Configuration tab for the LDAP Authentication provider for which you want to configure failover.

    For example, click the iPlanet LDAP tab under the iPlanet Configuration tab.

  2. Click the LDAP tab.

  3. Specify more than on LDAP server name in the Host attribute on the LDAP tab. The attribute must contain a space-delimited list of host names. Each host name may include a trailing colon and port number. For example:

    directory.knowledge.com:1050 people.catalog.com 199.254.1.2

  4. Click Apply.

  5. Click the Details tab.

  6. Set the Parallel Connect Delay attribute.

    The Parallel Connect Delay attribute specifies the number of seconds to delay when making concurrent attempts to connect to multiple servers. An attempt is made to connect to the first server in the list. The next entry in the list is tried only if the attempt to connect to the current host fails. This setting might cause your application to block for unacceptably long time if a host is down. If the attribute is set to a value greater than 0, another connection setup thread is started after the specified number of delay seconds has passed. If the attribute is set to 0, connection attempts are serialized.

  7. Set the Connection Timeout attribute.

    The Connection Timeout attribute specifies the maximum number of seconds to wait for the connection to the LDAP server to be established. If the attribute is set to 0, there is no maximum time limit and WebLogic Server will wait until the TCP/IP layer times out to return a connection failure. This attribute may be set to a value over 60 seconds depending upon the configuration of TCP/IP.

  8. Click Apply.

  9. Reboot WebLogic Server.

 

Configuring the Realm Adapter Authentication Provider

To configure the Realm Adapter Authentication provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  4. Choose the Configure a new Realm Adapter Authenticator... link.

  5. Set the Control Flag for the Realm Adapter Authentication provider.

  6. Set the Active Type for the Identity Asserter in the Realm Adapter Authentication provider.

    1. In the Available list box, click X.509 to highlight it.

    2. Click the right arrow to move X.509 to the Chosen list box.

  7. Click Apply to save your changes.

  8. Optionally, configure additional Authentication and/or Identity Assertion providers.

  9. Reboot WebLogic Server.

 

Change the Order of Authentication Providers

The way you configure multiple Authentication providers can affect the overall outcome of the authentication process, which is especially important for multipart authentication. Authentication providers are called in the order in which they are configured. The Authentication Providers table lists the authentication providers in the order they were configured. Click the Re-order the Configured Authentication Providers... link to change the order of the providers. Be aware that the way each Authentication provider's Control Flag attribute is set effects the outcome of the authentication process.

To change the ordering of Authentication providers:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose the Re-order the Configured Authentication Providers... link.

  5. Select an Authentication provider from the list of configured Authentication providers.

  6. Use the arrow buttons to move it up or down in the list.

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 

Configuring the WebLogic Authorization Provider

Note that the WebLogic Server Administration Console refers to the WebLogic Authorization provider as the Default Authorizer.

To configure the WebLogic Authorization provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Click Authorizers.

  5. Click the Configure a new Default Authorizer... link.

  6. Define values for the attribute on the General page.

  7. Click Apply to save your changes.

  8. Define values for the attribute on the Details tab.

  9. Reboot WebLogic Server.

 

Configuring the WebLogic Credential Mapping Provider

To configure the WebLogic Credential Mapping provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Click Credential Mappers.

  5. Click the Configure a new Default Credential Mapper... link.

  6. On the General page, set the Credential Mapping Deployment Enabled attribute.

    The Credential Mapping Deployment Enabled attribute specifies whether or not this Credential Mapping provider imports credential maps from a weblogic-ra.xml deployment descriptor file. In order to support the Credential Mapping Deployment Enabled attribute, a Credential Mapping provider must implement the DeployableCredentialProvider SSPI. By default, the WebLogic Credential Mapping provider has this attribute enabled. The credential mapping information is stored in the embedded LDAP server.

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 

Configuring the WebLogic Role Mapping Provider

To configure an Role Mapping provider:

  1. Expand the Security node.

  2. Expand the Realms node.

  3. Click the name of the realm you are configuring (for example, TestRealm).

  4. Click the Providers node.

  5. Click Role Mappers.

    The Role Mappers page appears. This page displays the name of the default Role Mapping provider for the realm that is being configured.

  6. Click the Configure a new Default Role Mapper... link.

    The General page appears.

  7. Define values for the attributes on the General page.

  8. Click Apply to save your changes.

  9. Reboot WebLogic Server.

 

Configuring a WebLogic Identity Assertion Provider

Note that the WebLogic Server Administration Console refers to the WebLogic Identity Assertion provider as the Default Identity Asserter.

To define attributes for the WebLogic Identity Assertion provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

    The Authenticators table displays the name of the default Authentication and Identity Assertion providers.

  4. Choose the Configure a new Default Identity Asserter... link from the Authenticators tab.

    The General tab appears.

  5. Configure a user name mapper.

  6. In the Trusted Client Principals attribute define the list of client principals that can use CSIv2 identity assertion. You can use an asterisk (*) to specify all client principals.

  7. Define the active token type for the WebLogic Identity Assertion provider. The list of token types supported by the Identity Assertion is displayed in the Available list box. To define the active token type for the Identity Assertion provider:

    1. In the Available list box, click the desired token type to highlight it.

    2. Click the right arrow to move token type to the Chosen list box.

  8. Click Apply to save your changes.

  9. Click the Details tab.

  10. Verify the setting of the Base64 Decoding Required attribute.

    If the authentication type in a Web application is set to CLIENT-CERT, the Web Application Container in WebLogic Server performs identity assertion on values from request headers and cookies. If the header name or cookie name matches the active token type for the configured Identity Assertion provider, the value is passed to the provider.

    The Base64 Decoding Required attribute determines whether the request header value or cookie value must be Base64 Decoded before sending it to the Identity Assertion provider. The setting is enabled by default for purposes of backward compatibility, however, most Identity Assertion providers will disable this attribute.

  11. Click Apply.

  12. Optionally, configure additional Authentication and/or Identity Assertion providers.

  13. Reboot WebLogic Server.

 

Configuring the WebLogic Adjudication Provider

Note that the WebLogic Server Administration Console refers to the WebLogic Adjudication provider as the Default Adjudicator.

To configure the WebLogic Adjudication provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm.)

  3. Expand the Providers node.

  4. Click Adjudicators.

  5. Click the Configure a new Default Adjudicator... link.

  6. Optionally, on the Detail page, set the Require Unanimous Permit attribute.

  7. Click Apply to save your changes.

  8. Reboot WebLogic Server.

 

Configuring a WebLogic Auditing Provider

Warning: Using an Auditing provider affects the performance of WebLogic Server even if only a few events are logged.

Warning: If you are creating a new security realm, configuring an Auditing provider is an optional step. The WebLogic Server Administration Console refers to the WebLogic Auditing provider as the Default Auditor.

To configure the WebLogic Auditing provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers node.

  4. Click Auditors.

  5. Click the Configure a new Default Auditor... link.

    The General page appears.

  6. Click the details

  7. Choose the auditing severity level appropriate for your WebLogic Server deployment by setting the Severity attribute.

  8. Click Create to save your changes.

  9. Reboot WebLogic Server.

 

Configuring a Custom Security Provider

To configure a Custom security provider:

  1. Write a Custom security provider.

  2. Put the MBean JAR file for the provider in...

    WL_HOME/lib/mbeantypes

  3. Start the WebLogic Server Administration Console.

  4. Expand the Security-->Realms nodes.

  5. Click on the name of the realm you are configuring (for example, TestRealm.)

  6. Expand the Providers node.

  7. Expand the node for the type of provider you are configuring. For example, expand the Authentication Providers node to configure a Custom Authentication provider.

    The table page for the provider appears.

  8. Click the Configure a new Custom Security_Provider_Type... link

    where Security_Provider_Type is the name of your custom security provider. This name is read from the DisplayName attribute in the MBeanType tag of the MBean Definition File (MDF).

  9. The General page appears.

    The Name attribute displays the name of your Custom Security provider.

  10. If desired, adjust the values for the attributes for the Custom Security provider.

  11. Click Apply to save your changes.

  12. Reboot WebLogic Server.

 

Deleting a Security Provider

To delete a security provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm in which the provider you want to delete is configured (for example, TestRealm).

  3. Expand the Providers node.

  4. Click the type of provider you want to delete (for example, TestRealm-->Authorizers).

  5. The table page for the provider appears (for example, the Authorizers table). The table page for the provider displays the names of all the available providers.

  6. To delete a provider, click the trash can icon in the corresponding row of the provider table.

  7. Reboot WebLogic Server.

Note: Deleting and modifying configured security providers by using the WebLogic Server Administration Console may require manual clean up of the databases.

 

Configuring a User Name Mapper

When using 2-way SSL, WebLogic Server verifies the digital certificate of the Web browser or Java client when establishing an SSL connection. However, the digital certificate does not identify the Web browser or Java client as a user in the WebLogic Server security realm. If the Web browser or Java client requests a WebLogic Server resource protected by a security policy, WebLogic Server requires the Web browser or Java client to have an identity. The WebLogic Identity Assertion provider allows you to enable a user name mapper that maps the digital certificate of a Web browser or Java client to a user in a WebLogic Server security realm.

The user name mapper is an implementation the weblogic.security.providers.authentication.UserNameMapper interface. By default, WebLogic Server provides a default implementation of the weblogic.security.providers.authentication.UserNameMapper interface. You can also write your own implementation

The WebLogic Identity Assertion provider calls the user name mapper for the following types of identity assertion token types:

  • X.509 digital certificates passed via the SSL handshake

  • X.509 digital certificates passed via CSIv2

  • X.501 distinguished names passed via CSIv2

The default user name mapper uses the attributes from the subject DN of the digital certificate or the distinguished name to map to the appropriate user in the WebLogic Server security realm. For example, the user name mapper can be configured to map a user from the Email attribute of the subject DN (smith@bea.com) to a user in the WebLogic Server security realm (smith).

To use the default user name mapper:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose the Default Identity Assertion provider.

  5. Click the Details tab.

  6. Check the Use the Default User Name Mapper attribute to enable the user name mapper.

  7. Specify the following attributes:

    • Default User Name Mapper Attribute Type - The attribute of the subject distinguished name (DN) in a digital certificate used to create a username. Valid values are: C, CN, E, L, O, and OU.

    • Default User Name Mapper Attribute Delimiter - The attribute that ends the username. The user name mapper uses everything to the left of the attribute to create a username.

  8. Click Apply.

  9. Reboot WebLogic Server.

 

Configuring a Custom User Name Mapper

To install a custom user name mapper:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Expand the Providers-->Authentication Providers nodes.

  4. Choose the Default Identity Assertion provider.

  5. Click the General tab.

  6. Enter the name of the implementation of the weblogic.security.providers.authentication.UserNameMapper interface in the User Name Mapper Class Name attribute.

  7. Click Apply.

  8. Reboot WebLogic Server.

 

Importing and Exporting Security Data from Security Realms

When creating new security realms, security data (authentication, authorization, credential map, and role data) from one security realm can be exported into a file and then imported into another security realm. This feature allows you to develop and test new security realms without recreating all the security data (for example, when moving a development security realm to production). Only information from the WebLogic security providers can be exported and imported. Two options are available:

Note: You can only export and import security data between security realms in the same WebLogic Server release.

To export and import security data:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Click the Migration-->Export tab.

  4. Specify the directory and filename in which to export the security data in the Export Directory on Server attribute.

    Note: You can specify a directory and file location on another server.

  5. Click Export.

  6. Expand the Realms node.

  7. Click the name of the security realm in which the security data is to be imported.

  8. Click the Migration-->Import tab.

  9. Specify the directory location and file name of the file that contains the exported security data in the Import Directory on Server attribute.

  10. Click Import.

To verify the security data was imported correctly:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm into which the security data was imported.

  3. Click Users.

  4. Users from the security realm from which you exported the security data should appear in the Users table.

 

Importing and Exporting Security Data from Security Providers

Provider-specific security data can also be exported and imported between providers in different security realms. Each provider displays the supported formats (DefaultAtn, DefaultAtz, DefaultCreds, or DefaultRoles). The constraints define the data types (users, groups, roles, and credmaps). The constraints are only displayed for the WebLogic Authentication provider because you have the option of exporting or importing users and groups, just users, just groups, specific users, or specific groups.

To export and import security data from a security provider:

  1. Expand the Security-->Realms nodes.

  2. Click the name of the realm you are configuring (for example, TestRealm).

  3. Click the type of provider from which you want to export security data (for example, Authentication Providers).

  4. Click the security provider from which you want to export security data.

  5. Click the Migration-->Export tab.

  6. Specify the directory and filename in which to export the security data in the Export Directory attribute.

  7. Optionally, define a specific set of security data to be exported in the Export Constraints box.

  8. Click Export.

  9. Expand the Realms node.

  10. Click the name of the security realm in which the security data is to be imported.

  11. Expand the Providers node.

  12. Click the security provider in which the security data is to be imported.

  13. Click the Migration-->Import tab.

  14. Specify the directory location and file name of the file that contains the exported security data in the Import Directory on Server attribute or use the Browse button to locate the exported file on your computer.

  15. Click Import.

 

Change the Default Security Realm

By default, WebLogic Server sets the myrealm as the default security realm.

  1. Configure a new security realm.

  2. Reboot WebLogic Server.

  3. Expand the Domain node (for example, Examples).

  4. Click the View Domain-Wide Security Settings link on the General page.

  5. Select the Security Configuration-->General tab.

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

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

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

  7. Click Apply.

  8. 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. Expand the Security node.

  2. Expand the Realm node.

    The Realms table appears. All the realms available in the domain are listed. The default security realm has the Default Realm attribute set to true.

 

Delete A Security Realm

  1. Expand the Security node.

  2. Expand the Realm node.

    The Realms table appears. All the realms available the domain are listed in a table.

  3. To delete a security realm, click the trash can icon in the corresponding row of the Realms table.

  4. A Delete confirmation window appears.

  5. Click Yes in response to the following prompt:

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

    A confirmation message appears when the security realm is deleted.

 

Create Credential Maps

Resource adapters defined by the J2EE Connector Architecture can acquire the credentials necessary to authenticate users defined in an Enterprise Information System (EIS) when they request access to a protected WebLogic resource. The container in WebLogic Server that hosts resource adapters can retrieve the appropriate set of credentials for the WebLogic resource using a credential map. A credential map creates an association between a user in WebLogic Server security realm and an identity (a username and password combination) used to authenticate that user in an EIS such as an Oracle database, a SQL server, or a SAP application.

Credential maps can be created through the WebLogic Server Administration Console. If you are using the WebLogic Credential Mapping provider, the credential maps are stored in the embedded LDAP server.

To create a credential map:

  1. Verify the Ignore Security Data in Deployment Descriptors attribute is enabled on the default (active) security realm. Otherwise, you risk overwriting credential maps with old information in weblogic-ra.xml deployment descriptor files.

  2. Define a user or group for the EIS user.

  3. Deploy a resource adapter.

  4. In the left pane of the WebLogic Server Administration Console, expand Deployments, then Connector Modules.

  5. Right-click the name of the Connector for which you want to create a credential map, and choose Define Credential Mappings... to display the Credential Mappings page.

    If available, a table of currently defined credential maps appears in the right pane.

  6. Click the Configure a New Credential Mapping... link.

    If multiple WebLogic Credential Mapping providers are configured in the security realm, select which WebLogic Credential Mapping provider's database should store information for the new credential map.

  7. Enter the WebLogic Server user or group name you defined for the EIS user in step 2 in the WLS User field.

  8. Click Apply to save your changes.

 

Configuring Keystores and SSL

By default, WebLogic Server is configured with two keystores:

  • DemoIdentity.jks - Contains a demonstration private key for WebLogic Server. This keystore establishes an identity for WebLogic Server.

  • DemoTrust.jks - Contains a list of certificate authorities trusted by WebLogic Server. This keystore establishes trust for WebLogic Server.

These keystores are located in the BEA_HOME\weblogic710\server\lib directory. For testing and development purposes, the keystore configuration is complete. Use the steps in this section to configure identity and trust keystores for production use.

Before you perform the steps in this section, you need to:

  1. Obtain private keys and digital certificates from a reputable certificate authority such as Verisign, Inc. or Entrust.net.

  2. Create identity and trust keystores.

  3. Load the private keys and trusted CAs into the keystores.

To set attributes for the identity and trust keystores:

  1. Expand the Servers node.

  2. Click the name of the server for which you want to configure keystores (for example, exampleserver).

  3. Click the Configuration-->Keystores and SSL tab.

    The information about the demonstration keystores is displayed in the Keystore Configuration.

  4. Click the Change... link in the Keystore Configuration to configure new keystores.

  5. Choose the type of keystore configuration being used. The following options are available:

    Demo Identity and Demo Trust The demonstration identity and trust keystores located in...

    BEA_HOME/server/lib

    ...and configured by default.

    Custom Identity and Java Standard Trust A keystore you create and the trusted CAs defined in the cacerts file in...

    JAVA_HOME/jre/lib/security/cacerts
    Custom Identity and Custom Trust Identity and trust keystores you create.
    Custom Identity and Command-Line Trust An identity keystore you create and command-line arguments that specify the location of the trust keystore.

  6. Click Continue.

  7. Define attributes for the Identity keystore.

    • Custom Identity Keystore File - The fully qualified path to the identity keystore.

    • Custom Identity Keystore Type - The type of the keystore. Generally, this attribute is jks.

    • Custom Identity Keystore Passphrase - The password defined when creating the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore. Note that the passphrase for the Demo Identity keystore is DemoIdentityPassPhrase.

  8. Define properties for the trust keystore.

    If you choose Java Standard Trust, specify the password defined when creating the keystore. Confirm the password.

    If you choose Custom Trust, define the following attributes:

    • Custom Trust Keystore File - The fully qualified path to the trust keystore.

    • Custom Trust Keystore Type - The type of the keystore. Generally, this attribute is jks.

    • Custom Trust Keystore Passphrase - The password defined when creating the keystore. This attribute is optional or required depending on the type of keystore. All keystores require the passphrase in order to write to the keystore. However, some keystores do not require the passphrase to read from the keystore. WebLogic Server only reads from the keystore so whether or not you define this property depends on the requirements of the keystore.

  9. Click Continue.

  10. If necessary, update the definitions for the SSL attributes. The attributes are:

    • Alias - The alias you used when loading the private key for WebLogic Server into the identity keystore.

    • Passphase - The password used to retrieve the private key for WebLogic Server from the identity keystore.

    • Confirm - Re-enter the password.

  11. Click Continue.

  12. Click Finish.

  13. Reboot WebLogic Server.

 

Configuring Two-Way SSL

By default, WebLogic Server is configured to use one-way SSL (the server passes its identity to the client). For a more secure SSL connection, use two-way SSL. In a two-way SSL connection, the client verifies the identity and trust of the server and then passes its identity and trust to the server. The server then validates the identity and trust of the client before completing the SSL connection. The server determines whether or not two-way SSL is used.

To enable two-way SSL:

  1. Expand...

    Servers | servername | Configuration | Keystores and SSL tab | Advanced Options | Show link | Server attributes section

  2. Set the Two Way Client Cert Behavior attribute. The following options are available:

    • Client Certs Not Requested - The default (meaning one-way SSL).

    • Client Certs Requested But Not Enforced - Requires a client to present a certificate. If a certificate is not presented, the SSL connection continues.

    • Client Certs Requested And Enforced - Requires a client to present a certificate. If a certificate is not presented, the SSL connection is terminated.

  3. Click Apply.

  4. Reboot WebLogic Server.

 

Enabling Trust Between WebLogic Domains

A trust relationship is established when principals in a Subject from one WebLogic Server domain (referred to as a domain) are accepted as principals in the local domain. If you want two domains to interoperate, perform the following procedure in both domains.

To establish a trust relationship between WebLogic Server domains:

  1. Expand the Domains node (for example, Examples).

  2. Click the View Domain-Wide Security Settings link on the Domain-->General page.

  3. Select the Security Configuration-->Advanced tab.

  4. Uncheck the Enable Generated Credential attribute.

  5. Enter a password for the domain in the Credential text field. Choose the password carefully. BEA Systems recommends using a combination of upper and lower case letters and numbers.

  6. Confirm the password by entering it in the Confirm Credential text field.

  7. Click Apply.

  8. Reboot WebLogic Server.

If you want a WebLogic Server 6.x domain to interoperate with a WebLogic Server 7.0 domain, change the Credential attribute in the WebLogic Server 7.0 domain to the password of the system user in the WebLogic Server 6.x domain.

 

Configuring Connection Filtering

To configure a connection filter:

  1. Expand the Domains node.

  2. Click the View Domain-Wide Security Settings link on the Domain-->General tab.

  3. Select the Security Configuration-->Filter tab.

  4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages.

  5. Enter the class that implements the network connection filter in the Connection Filter attribute. This class must also be specified in the CLASSPATH for WebLogic Server.

  6. Enter the syntax for the connection filter rules.

  7. Click Apply.

  8. Reboot WebLogic Server.

Skip navigation bar  Back to Top Previous Next