Managing WebLogic Security

Managing the Embedded LDAP Server

The embedded LDAP server is the default security provider database for the WebLogic Authentication, Authorization, Credential Mapping and Role Mapping providers.The following sections explain how to manage the embedded LDAP server.

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.

Note: The performance of the embedded LDAP server works best with less than 50,000 users.

To configure the embedded LDAP server:

Expand the Domain node (for example, Examples).

Select the Security-->Embedded LDAP tab.

Set attributes on the Embedded LDAP tab. The following table describes each attribute on the Embedded LDAP tab.

Table 7-1 Attributes on the Embedded LDAP Tab

LDAP Attribute	Description
Credential	The credential (usually a password) used to connect to the embedded LDAP server. If this password has not been set, WebLogic Server generates a password at startup, initializes the attribute, and saves the configuration to the `config.xml` file. If you want to connect to the embedded LDAP server using an external LDAP browser and the embedded LDAP administrator account (`cn=Admin`), change this attribute from the generated value.
Backup Hour	The hour at which to back up the embedded LDAP server data files. This attribute is used in conjunction with the Backup Minute attribute to determine the time at which the embedded LDAP server data files are backed up. At the specified time, WebLogic Server suspends writes to the embedded LDAP server, backs up the data files into a zip file in the `ldap/backup` directory, and then resumes writes. The default is 23.
Backup Minute	The minute at which to back up the embedded LDAP server data files. This attribute is used in conjunction with the Back Up Hour attribute to determine the time at which the embedded LDAP server data files are backed up. The default is 5 minutes.
Backup Copies	The number of backup copies of the embedded LDAP server data files. This value limits the number of zip files in the `ldap/backup` directory. The default is 7.
Cache Enabled	Specifies whether or not a cache is used with the embedded LDAP server. This cache is used when a Managed Server is reading or writing to the master embedded LDAP server that is running on the Administration Server.
Cache Size	The size of the cache (in K) that is used with the embedded LDAP server. The default is 32K.
Cache TTL	The time-to-live (TTL) of the cache in seconds. The default is 60 seconds.
Refresh Replica At Startup	Specifies whether or not a Managed Server should refresh all replicated data at boot time. This attribute is useful if you have made a large number of changes while the Managed Server was not active and you want to download the entire replica instead of having the Administration Server push each change to the Managed Server. Use this attribute to propagate a new system password to the Administration and Managed Servers in a domain. The default is false.
Master First	Specifies that connections to the master LDAP server (running on the Administration Server) should always be made instead of connections to the local replicated embedded LDAP server. This causes the Managed Server to retrieve security data from the embedded LDAP server in the Administration Server instead of going to the local embedded LDAP server that contains a replica of the information in the Administration Server.
Anonymous Bind Allowed	Specifies whether to permit anonyomous access to the embedded LDAP server. By default, anonymous access is disabled, since it might constitute a security vulnerability.

Click Apply to save your changes.

Reboot WebLogic Server.

Embedded LDAP Server Replication

When you use the embedded LDAP Server in a WebLogic Server domain, updates are sent to a master LDAP server. The master LDAP server maintains a log of all changes. The master LDAP server also maintains a list replicated servers and the current change status for each one. The master LDAP server sends appropriate changes to each replicated server and updates the change status for each server. This process occurs when an update is made to the Master LDAP 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. The master LDAP server is the embedded LDAP server on the Administration Server. The replicated servers are all the Managed Servers in the WebLogic Server domain.

Note: Deleting and modifying the configured security providers using the WebLogic Server Administration Console may require manual clean up of the embedded LDAP server. Use an external LDAP browser to delete unnecessary information.

Configuring Backups for the Embedded LDAP Server

To configure the backups of the embedded LDAP server:

Expand the Domain node (for example, Examples).

Select the Security--> Embedded LDAP tab.

Set the Backup Hour, Backup Minute, and Backup Copies attributes on the Embedded LDAP tab.

Click Apply to save your changes.

Reboot WebLogic Server.

Viewing the Contents of the Embedded LDAP Server from an LDAP Browser

To view the contents of the embedded LDAP server through an LDAP browser:

Download an external LDAP browser from the following location:

http:/www.iit.edu/~gawojar/ldap/

To view the contents, change the embedded LDAP credentials.

Expand the Domain node (for example, Examples).

Select the Security-->Embedded LDAP tab.

Change the Credential attribute from its generated value to a password you will use in the LDAP browser. See Table 7-1.

Click Apply.

Reboot WebLogic Server.

Enter the following command at a command prompt to start the LDAP browser:

lbe.sh

Configure a new connection in the LDAP browser:

Set the host field to localhost.

Set the port field to 7001 (7002 if SSL is being used).

Set the Base DN field to dc=mydomain where mydomain is the name of the WebLogic Server domain you are using.

Uncheck the Anonymous Bind option.

Set the User DN field to cn=Admin.

Set the Password field to the password you specified in Step 2c.

Click the new connection.

Use the LDAP browser to navigate the hierarchy of the embedded LDAP server.

Exporting and Importing Information in the Embedded LDAP Server

In this release of WebLogic Server, the Migration tab of each security provider can be used to import or export data from the embedded LDAP server.

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.

Optionally, an LDAP browser can be used to export and import data stored in the embedded LDAP Server. Table 7-2 summarizes where data is stored in the hierarchy of the embedded LDAP server.

Table 7-2 Location of Security Data in the Embedded LDAP Server

Security Data	Embedded LDAP Server DN
Users	`ou=people,ou=myrealm,dc=mydomain`
Groups	`ou=groups,ou=myrealm,dc=mydomain`
Security roles	`ou=ERole,ou=myrealm,dc=mydomain`
Security policies	`ou=EResource,ou=myrealm,dc=mydomain`

To export security data from the embedded LDAP server using an LDAP browser:

Enter the following command at a command prompt to start the LDAP browser:

lbe.sh

Specify the data to be exported (for example, to export users specify ou=people,ou=myrealm,dc=mydomain).

Select the LDIF-->Export option.

Select Export all children.

Specify the name of the file into which the data will be exported.

To import security data from the embedded LDAP server using an LDAP browser:

Enter the following command at a command prompt to start the LDAP browser:

lbe.sh

Specify the data to be imported (for example, to import users specify ou=people,ou=myrealm,dc=mydomain).

Select the LDIF-->Import option.

Select Update/Add.

Specify the name of the file from which the data will be imported.

LDAP Access Control Syntax

The embedded LDAP server supports the IETF LDAP Access Control Model for LDAPv3. This section describes how those access control is implemented within the embedded LDAP server. These rules can be applied directly to entries within the directory as intended by the standard or can be configured and maintained by editing the access control file (acls.prop).

Note: The default behavior of the embedded LDAP server is to only allow access from the Admin account in WebLogic Server and to block all anonymous access. 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. You may ignore the procedures in this section.

The Access Control File

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:

Location in the LDAP directory where the rule applies
Scope within that location to which the rule applies
Access rights (either grant or deny)
Permissions (either grant or deny)
Attributes to which the rule applies
Subject being granted or denied access

Listing 7-1 shows a sample access control file.

Listing 7-1 Sample acl.props File

[root]|entry#grant:r,b,t#[all]#public

ou=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:

Access Control Location

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.

Access Control Scope

The following access control scopes are defined:

Entry—An ACL with a scope of Entry is only evaluated if the entry in the LDAP directory shares the same DN as the location of the access control rule. Such rules are useful when a single entry contains more sensitive information than parallel or subentries entries.
Subtree—A scope of Subtree is evaluated if the entry in the LDAP directory equals or ends with the location of this access control. This scope protects means the location entry and all subentries.

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

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 creating or updating the access control rule.

Each of the LDAP access rights are discrete. One right does not imply another right. The rights specify the type of LDAP operations that can be performed.

Attribute Permissions

The following permissions apply to actions involving attributes.

Table 7-3 Attribute Permissions

Permission	Description
`r` Read	Read attributes. If granted, permits attributes and values to be returned in a Read or Search operation.
`w` Write	Modify or add attributes. If granted, permits attributes and values to be added in a Modify operation.
`o` Obliterate	Modify and delete attributes. If granted, permits attributes and values to be deleted in a Modify operation.
`s` Search	Search entries with specified attributes. If granted, permits attributes and values to be included in a Search operation.
`c` Compare	Compare attribute values. If granted, permits attributes and values to be included in a Compare operation.
`m` Make	Make attributes on a new LDAP entry below this entry.

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.

Entry Permissions

The following permissions apply entire LDAP entries.

Table 7-4 Entry Permissions

Permission	Description
`a` Add	Add an entry below this LDAP entry. If granted, permits creation of an entry in the DIT subject to control on all attributes and values placed on the new entry at the time of creation. In order to add an entry, permission must also be granted to add at least the mandatory attributes.
`d` Delete	Delete this entry. If granted, permits the entry to be removed from the DIT regardless of controls on attributes within the entry.
`e` Export	Export entry and all sub entries to new location. If granted, permits an entry and its sub entries (if any) to be exported; that is, removed from the current location and placed in a new location subject to the granting of suitable permission at the destination. If the last RDN is changed, `Rename` permission is also required at the current location. In order to export an entry or its subentries, there are no prerequisite permissions to the contained attributes, including the RDN attribute. This is true even when the operation causes new attribute values to be added or removed as the result of the changes to the RDN.
`i` Import	Import entry and subordinates from specified location. If granted, permits an entry and its subentries (if any) to be imported; that is, removed from one other location and placed at the specified location (if suitable permissions for the new location are granted). When importing an entry or its subentries, there are no prerequisite permissions for the contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN.
`n` RenameDN	Change the DN of an LDAP entry. Granting the `Rename` permission is necessary for an entry to be renamed with a new RDN, taking into account consequential changes to the DN of subentries. If the name of the superior entry is unchanged, the grant is sufficient. When renaming an entry, there are no prerequisite permissions to contained attributes, including the RDN attributes. This is true even when the operation causes new attribute values to be added or removed as the result of the changes of RDN.
`b` BrowseDN	Browse the DN of an entry. If granted, permits entries to be accessed using directory operations that do not explicitly provide the name of the entry.
`t` ReturnDN	Allows DN of entry to be disclosed in an operation result. If granted, allows the distinguished name of the entry to be disclosed in the operation result.

Attributes Types

The attribute type(s) to which an access control rule applies should be listed where necessary. The following keywords are available:

[entry] indicates the permissions apply to the entire object. This could mean actions such as delete the object, or add a child object.
[all] indicates the permissions apply to all attributes of the entry.

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.

Subject Types

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:

groupOfUniqueNames
groupOfNames
groupOfUniqueURLs

The first two types of groups contain lists of users, while the third type allows users to be included in the group automatically based on defined criteria.

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.

Grant/Deny Evaluation Rules

The decision whether to grant or deny a client access to an 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, there are guiding principles.

More specific rules override less specific ones (for example, individual user entries in an ACL take precedence over a group entry).
If a conflict still exists in spite of the specificity of the rule, the subject of the rule determines which rule will be applied. Rules based on an IP Address subject are given the most 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.
When there are conflicting ACL values, Deny takes precedence over Grant.
Deny is the default when there is no access control information. Additionally, an entry scope takes precedence over a subtree scope.