|
|
WebLogic Server includes an embedded LDAP server that acts as the default security provider data store for the WebLogic Authentication, Authorization, Credential Mapping, and Role Mapping providers.The following sections explain how to manage 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 type of information. The WebLogic Authentication, Authorization, Credential Mapping, and Role Mapping providers use the embedded LDAP server as their data store. 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.
| Note: | The performance of the embedded LDAP server is best with fewer than 50,000 users. If you have more users, consider using a different LDAP server and Authentication provider. |
See Configure the embedded LDAP server in the Administration Console online help.
The data file and change log file used by the embedded LDAP server can potentially grow quite large. You can configure maximum sizes for these files with the following weblogic.Server command line arguments:
-Dweblogic.security.ldap.maxSize=<max bytes>, which limits the size of the data file used by the embedded LDAP server. When the data file exceeds the specified size, WebLogic Server eliminates from the data file space occupied by deleted entries.-Dweblogic.security.ldap.changeLogThreshold=<number of entries>, which limits the size of the change log file used by the embedded LDAP server. When the change log file exceeds the specified number of entries, WebLogic Server truncates the change log by removing all entries that have been sent to all managed servers.
The WebLogic Server embedded LDAP server for a domain consists of a master LDAP server, maintained in the domain’s Administration Server, and a replicated LDAP server maintained in each Managed Server in the domain. When changes are made using a Managed Server, updates are sent to the embedded LDAP server on the Administration Server. The embedded LDAP server on the Administration Server maintains a log of all changes. The embedded LDAP server on the Administration Server also maintains a list of Managed Servers and the current change status for each one. The embedded LDAP server on the Administration Server sends appropriate changes to each Managed Server and updates the change status for each server. This process occurs when an update is made to the embedded LDAP server on the Administration Server. However, depending on the number of updates, it may take several seconds or more for the change to be replicated to the Managed Server.
You can configure the behavior of the embedded LDAP server on the Administration Server and the Managed Servers in a domain using the Administration Console. On the Domain: Security: Embedded LDAP Server page in the Administration Console, you can set these attributes:
See Configure the embedded LDAP server in the Administration Console online help.
| Note: | Deleting and modifying the configured security providers through the WebLogic Administration Console may require manual clean up of the embedded LDAP server. Use an external LDAP browser to delete unnecessary information. |
To view the contents of the embedded LDAP server through an LDAP browser:
http://www-unix.mcs.anl.gov/~gawor/ldap/
In this procedure it is assumed that you are using this LDAP browser; other LDAP browsers may differ in detail.
| Caution: | Changing the credential can affect the operation of the domain. Do not perform this step on a production server. |
localhost. 7001 (7002 if SSL is being used). dc=mydomain where mydomain is the name of the WebLogic Server domain you are using.cn=Admin.Use the LDAP browser to navigate the hierarchy of the embedded LDAP server.
| Note: | You can also view the contents of the embedded LDAP server by exporting its data and reviewing the exported file. See Exporting and Importing Information in the Embedded LDAP Server. |
You can export and import data from the embedded LDAP server using either the WebLogic Server Administration Console or an LDAP browser. To export and import data with the Console, use the Migration page of each security provider. See Export data from a security provider and Import data into a security provider in the Administration Console online help.
| WARNING: | When you use the Administration Console Migration tab to export security data, the export process deletes any existing files in the target directory with the .dat extension. Always export security data to an empty directory. |
This section describes how to use an LDAP browser to export and import data stored in the embedded LDAP server. Table 9-1 summarizes where data is stored in the hierarchy of the embedded LDAP server.
To export security data from the embedded LDAP server using the LDAP Browser/Editor:
ou=people,ou=myrealm,dc=mydomain).To import security data into the embedded LDAP server using the LDAP Browser/Editor:
ou=people,ou=myrealm,dc=mydomain).
The embedded LDAP server supports the IETF LDAP Access Control Model for LDAPv3. This section describes how that access control is implemented within the embedded LDAP server. You can apply these rules directly to entries within the directory as intended by the standard or you can configure and maintain them by editing the access control file (acls.prop).
| Note: | The default behavior of the embedded LDAP server is to allow access only from the Admin account in WebLogic Server. The WebLogic security providers use only the Admin account to access the embedded LDAP server. If you are not planning to access the embedded LDAP server from an external LDAP browser or if you are planning only to use the Admin account, you do not need to edit the acls.prop file and can ignore the information in this section. |
The access control file (acls.prop) maintained by the embedded LDAP server contains the complete list of access control lists (ACLs) for an entire LDAP directory. Each line in the access control file contains a single access control rule. An access control rule is made up of the following components:
Listing 9-1 shows a sample access control file.
[root]|entry#grant:r,b,t#[all]#publicou=Employees,dc=octetstring,dc=com|subtree#grant:r,c#[all]#public:,
ou=Employees,dc=octetstring,dc=com|subtree#grant:b,t#[entry]#public:
ou=Employees,dc=octetstring,dc=com|subtree#deny:r,c#userpassword#public:
ou=Employees,dc=octetstring,dc=com|subtree#grant:r#userpassword#this:
ou=Employees,dc=octetstring,dc=com|subtree#grant:w,o#userpassword,title
description,
postaladdress,telephonenumber#this:
cn=schema|entry#grant:r#[all]#public:
Each access control rule is applied to a given location in the LDAP directory. The location is normally a distinguished name (DN) but the special location [root] can be specified in the acls.prop file if the access control rule applies to the entire directory.
If an entry being accessed or modified on the LDAP server does not equal or reside below the location of the access control rule, the given access control rule is not evaluated further.
The following access control scopes are defined:
If an entry in the directory is covered by conflicting access control rules (for example, where one rule is an Entry rule and the other is a Subtree rule), the Entry rule takes precedence over rules that apply because of the Subtree rule.
Access rights apply to an entire object or to attributes of the object. Access can be granted or denied. Either of the actions grant or deny may be used when you create or update the access control rule.
Each LDAP access right is discrete. One right does not imply another right. The rights specify the type of LDAP operations that can be performed.
The following permissions apply to actions involving attributes.
The m permission is required for all attributes placed on an object when it is created. Just as the w and o permissions are used in the Modify operation, the m permission is used in the Add operation. The w and o permissions have no bearing on the Add operation and m has no bearing on the Modify operation. Since a new object does not yet exist, the a and m permissions needed to create it must be granted to the parent of the new object. This requirement differs from w and o permissions which must be granted on the object being modified. The m permission is distinct and separate from the w and o permissions so that there is no conflict between the permissions needed to add new children to an entry and the permissions needed to modify existing children of the same entry. In order to replace values with the Modify operation, a user must have both the w and o permissions.
The following permissions apply to entire LDAP entries.
The attribute types to which an access control rule applies should be listed in the ACL where necessary. The following keywords are available:
If the keyword [all] and another attribute are both specified within an ACL, the more specific permission for the attribute overrides the less specific permission specified by the [all] keyword.
Access control rules can be associated with a number of subject types. The subject of an access control rule determines whether the access control rule applies to the currently connected session.
The following subject types are defined:
authzID—Applies to a single user that can be specified as part of the subject definition. The identity of that user in the LDAP directory is typically defined as a DN.Group—Applies to a group of users specified by one of the following object classes: Subtree—Applies to the DN specified as part of the subject and all subentries in the LDAP directory tree.IP Address—Applies to a particular Internet address. This subject type is useful when all access must come through a proxy or other server. Applies only to a particular host, not to a range or subnet.Public—Applies to anyone connected to the directory, whether they are authenticated or not.This—Applies to the user whose DN matches that of the entry being accessed.The decision whether to grant or deny a client access to the information in an entry is based on many factors related to the access control rules and the entry being protected. Throughout the decision making process, these guiding principles apply:
IP Address subject are given the highest precedence, followed by rules that are applied to a specific AuthzID or This subject. Next in priority are rules that apply to Group subjects. Last priority is given to rules that apply to Subtree and Public subjects.
|