Note: Compatibility security is deprecated in this release of WebLogic Server. You should only use Compatibility security while upgrading your WebLogic Server deployment to the security features in this release of WebLogic Server.
Running Compatibility Security: Main Steps
To set up Compatibility security:
Make a back-up copy of your 6.x WebLogic domain (including your config.xml file) before using Compatibility security. A sample config.xml file that can be used to boot Compatibility security can be found in Booting WebLogic Server in Compatibility Security in the Upgrade Guide for BEA WebLogic Server 7.0.
Install WebLogic Server 7.0 in a new directory location. Do not overwrite your existing 6.x installation directory. For more information, see the WebLogic Server Installation Guide.
Modify the start script for your 6.x server to point to the WebLogic Server 7.0 installation. Specifically, you need to modify:
The classpath to point to the weblogic.jar file in the WebLogic Server version 7.0 installation.
The JAVA_HOME variable to point to the WebLogic Server version 7.0 installation.
Use the start script for your 6.x server to boot WebLogic Server.
To verify whether you are correctly running Compatibility security, do the following:
In the WebLogic Server Administration Console, expand the Domain node.
Click on your WebLogic Server domain (referred to as the domain).
Click the View the Domain Log link.
The following message appears in the log:
Security initializing using realm CompatibilityRealm
In addition, a CompatibilitySecurity node will appear in the WebLogic Server Administration Console.
The Default Security Configuration in the CompatibilityRealm
By default, the CompatibilityRealm is configured with a Realm Adapter Adjudication provider, a Realm Adapter Authentication provider, a WebLogic Authorization provider, a Realm Adapter Authorization provider, a WebLogic Credential Mapping provider, and a WebLogic Role Mapping provider.
In the CompatibilityRealm, the Realm Adapter Authentication provider is populated with users and groups from the 6.x security realm defined in the config.xml file.
If you were using the File realm in your 6.x security configuration, you can manage the users and groups in the Realm Adapter Authentication provider following the steps in "Defining Users in the CompatibilityRealm" and "Defining Groups in the CompatibilityRealm" topics in the Compatibility Security online help for the WebLogic Server Administration Console.
If you are using an alternate security realm (LDAP, Windows NT, RDBMS, or custom), you must use the administration tools provided by that realm to manage users and groups.
If you have large numbers of users and groups stored in a Windows NT, RDBMS, UNIX, or a custom security realm and you want to upgrade to a WebLogic, LDAP or custom Authentication provider, you can configure a Realm Adapter Authentication provider in the new security realm to access your existing 6.x store.
Note: The Realm Adapter Authentication provider is the only Realm Adapter provider that can be configured in a realm other than the CompatibiltyRealm.
Access Control Lists (ACLs) in the 6.x security realm are used to populate the Realm Adapter Authorization provider.
The Realm Adapter Adjudication provider enables the use of both ACLs and security roles and security policies in Compatibility security. The Realm Adapter Adjudication provider resolves access decision conflicts between ACLs and new security policies set through the WebLogic Server Administration Console.
The WebLogic Credential Mapping provider allows the use of credential maps in Compatibility security.
You can add a Realm Adapter Auditing provider to access implementations of the weblogic.security.audit.AuditProvider class from the CompatibilityRealm
Configuring the Identity Assertion Provider in the Realm Adapter Authentication Provider
The Realm Adapter Authentication provider includes an Identity Assertion provider.The Identity Assertion provider provides backward compatibility for implementations of the weblogic.security.acl.CertAuthenticator class. The identity assertion is performed on X.509 tokens. By default, the Identity Assertion provider is not enabled in the Realm Adapter Authentication provider.
To enable identity assertion in the Realm Adapter Authentication provider:
Expand the Security-->Realms nodes.
Click the CompatibilityRealm.
Expand the Providers node.
Click Authentication Providers.
Click the Realm Adapter Authenticator link in the Realms table.
The General tab appears.
Enter X.509 in the Active Types list box.
This step enables the use of 6.x Cert Authenticators.
Click Apply.
Reboot WebLogic Server.
Configuring a Realm Adapter Auditing Provider
The Realm Adapter Auditing provider allows you to use implementations of the weblogic.security.audit.AuditProvider class when using Compatibility security. In order for the Realm Adapter Auditing provider to work properly, the implementation of the weblogic.security.audit.AuditProvider class must have been defined in the Audit Provider class attribute on the Domain-->Security-->General tab.
To configure a Realm Adapter Auditing provider:
Expand the Compatibility Security-->Realms nodes.
Expand the Providers node.
Click Auditors.
Click Configure a Realm Adapter Auditor... link.
The General tab appears
Click Create to save your changes.
Reboot WebLogic Server.
Protecting User Accounts in Compatibilty Security
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 protect the user accounts in your WebLogic Server domain, perform the following steps:
Click on the Domains node.
Select the Security-->Passwords tab.
Define the desired attributes on this tab by entering values at the appropriate prompts and selecting the required checkboxes. (For details, see the following table).
Click Apply to save your choices.
Reboot WebLogic Server.
The following table describes each attribute on the Passwords tab.
Table 9-1 Password Protection Attributes
Attribute
Description
Minimum Password Length
Number of characters required in a password. Passwords must contain a minimum of 8 characters. The default is 8.
Lockout Enabled
Requests the locking of a user account after invalid attempts to log in to that account exceed the specified Lockout Threshold. By default, this attribute is enabled.
Lockout Threshold
Number of failed password entries for a user that can be tried to log in to a user account before that account is locked. Any subsequent attempts to access the account (even if the username/password combination is correct) raise a Security exception; the account remains locked until it is explicitly unlocked by the system administrator or another login attempt is made after the lockout duration period ends. Invalid login attempts must be made within a span defined by the Lockout Reset Duration attribute. The default is 5.
Lockout Duration
Number of minutes that a user's account remains inaccessible after being locked in response to several invalid login attempts within the amount of time specified by the Lockout Reset Duration attribute. In order to unlock a user account, you need to have the unlockuser permission for the weblogic.passwordpolicy. The default is 30 minutes.
Lockout Reset Duration
Number of minutes within which invalid login attempts must occur in order for the user's account to be locked.
An account is locked if the number of invalid login attempts defined in the Lockout Threshold attribute happens within the amount of time defined by this attribute. For example, if the value in this attribute is five minutes and three invalid login attempts are made within a six-minute interval, then the account is not locked. If five invalid login attempts are made within a five-minute period, however, then the account is locked.
The default is 5 minutes.
Lockout Cache Size
Specifies the intended cache size of unused and invalid login attempts. The default is 5.
There are two sets of attributes available to protect user accounts, one set at the domain and one set at the security realm. You may notice that if you set one set of attributes (for example, the attributes for the security realm) and exceed any of the values, the user account is not locked. This happens because the user account attributes at the domain override the user account attributes at the security realm. To avoid this situation, disable the user account attributes at the security realm.
To disable the user account attributes at the security realm:
Expand the Security-->Realms nodes.
Expand the CompatibilityRealm node.
Select the User Lockout tab.
Uncheck the Lockout Enabled attribute.
Click Apply.
Reboot WebLogic Server.
Warning: If you disable the user lockout attribute at the security realm, you must set the user attributes on the domain otherwise the user accounts will not be protected.
Accessing 6.x Security from Compatibility Security
When using Compatibility security, it is assumed you have an existing config.xml file with a security realm that defines users and groups and ACLs that protect the resources in your WebLogic Server domain. 6.x security management tasks such as configuring a security realm or defining ACLs should not be required therefore those management tasks are not described in this chapter. However, if you corrupt an existing 6.x security realm and have no choice but to restore it, the following 6.x security management tasks are described in the Compatibility Security section of the online help for the WebLogic Server Administration Console:
Configuring the File realm
Configuring the Caching realm
Configuring the LDAP V1 security realm
Configuring the LDAP V2 security realm
Configuring the Windows NT security realm
Configuring the UNIX security realm
Configuring the RDBMS security realm
Installing a custom security realm
Defining users
Deleting users
Changing the password for a user
Unlocking a user account
Disabling the Guest user
Defining groups
Deleting groups
Defining ACLs
Note: Compatibility security provides backward compatibility only and should not be considered a long-term security solution.