The Providers

Now we'll take a closer look at the different SSPIs that constitute a security realm. We'll learn about WebLogic's default implementation of these security providers and how to configure them. The default implementation provides the authentication architecture (and much more) that we have just seen. You can replace one or more of the providers with your own code if you want to change its behavior. Once again, the Administration Console lets you view and modify the configuration of these security providers. All of the security providers available to your realm can be found under the Security/Realms/myrealm/Providers node in the left pane of the Administration Console, where "myrealm" refers to the name of the security realm. Finally, we'll learn about the embedded LDAP server that holds all of the security data for the domain on behalf of the default security providers.

17.4.1 Authentication Providers

Authentication refers to the server's ability to reliably verify the identity of a user or system. We generally refer to a user or system being authenticated as simply a user. A user requires some proof of identity before it can establish trust with the server. WebLogic supports Authentication Providers that can validate user credentials based on a username-password combination or a digital certificate. The security provider repository, which stores the user and group information, can be implemented in the following ways:

• As an embedded LDAP server, which is the default used by WebLogic's security providers
• As an external LDAP store, such as Open LDAP, Active Directory, Novell, or NDS
• As a DBMS, which you may already be using to host the data for your enterprise applications
• As a text file, which is used by WebLogic's sample security providers

WebLogic's authentication provider architecture closely follows the authentication part of the standard JAAS. Following the JAAS terminology, a subject represents the source of a security request it represents a user or system that is trying to be authenticated. The point of authentication is to assign principals to a subject. Principals are identities that represent the result of a successful authorization. As we have seen, when the system user authenticates successfully, the subject representing this user is assigned a principal recording the fact that he is in the Administrators group, and another recording that he is a WebLogic user with the name system. Therefore, a subject is a standard container for authentication information, including principals. A client can use a subject to query its identity and other attributes. Figure 17-2 illustrates this client authentication process.

Figure 17-2. The client authentication process

The Authentication Provider adheres to the standard JAAS framework by structuring the authentication sequence on top of a number of configurable JAAS LoginModules. LoginModules are critical components of an Authentication Provider, as they are responsible for authenticating users within a security realm and populating the subject with the required principals (existing users and groups).

WebLogic demands that you have at least one authentication provider configured in your security realm.

17.4.1.1 Principal Validation Providers

Once a (possibly remote) client has established trust with WebLogic, the authenticated subject is retained on the client between server invocations. The Principal Validation Provider ensures that no hanky-panky has taken place with the subject's principals at any time between these invocations. It does this by signing and verifying the authenticity of the principals held by the subject. Once the principals have been validated, they can be used by an Authorization Provider for access control checks or by the Role Mapping Provider for role-mapping decisions. A security realm must define a Principal Validation Provider for each Authentication Provider.

17.4.1.2 Identity Assertion Providers

Identity Assertion Providers help secure access to the entry points of a WebLogic deployment. Instead of using usernames and passwords, an external client may use tokens to establish trust with a WebLogic Server. The Identity Assertion Provider verifies a token and, if successful, maps it to a valid WebLogic user. Once the token is mapped to a valid user, an Authentication Provider can then generate the principals for the user. This mechanism is called perimeter authentication, so you can consider an Identity Assertion Provider a special type of Authentication Provider. The key point here is that an external agent is responsible for authenticating the user, and then for conveying the user data to WebLogic.

As a side effect, perimeter authentication also enables single sign-on. For instance, an Identity Assertion Provider could supply an X.509 digital certificate as an identity token, and these credentials then could be used across multiple systems. WebLogic supports Identity Assertion Providers that can handle different token types (X.509, IIOP-CSIv2). Alternatively, you can create an Identity Assertion Provider that supports custom token types (e.g. Kerberos tickets). An Identity Assertion Provider can have multiple active token types. However, a token type can be active only in a single provider. Of course, a security realm may support multiple Identity Assertion Providers, though none is required. Figure 17-3 illustrates perimeter authentication.

Figure 17-3. Identity assertion during perimeter authentication

17.4.2 The Default Authentication Providers

WebLogic supports authentication based on username-password combinations, authentication using digital certificates transmitted either directly to WebLogic or via an HTTP server, and perimeter-based authentication based on security tokens. WebLogic lets you use the Authentication Providers described next.

Default Authenticator

This is WebLogic's default Authentication Provider, which relies on the embedded LDAP server to persist all security information.

Realm Adapter Authentication Provider

This provides backward compatibility with user and group information held in old WebLogic 6.x realms.

Default Identity Asserter

This is WebLogic's default Identity Assertion Provider, which verifies the authenticity of X.509 and IIOP-CSIv2 tokens and maps them to valid WebLogic users.

LDAP Authentication Providers

These providers use external LDAP stores to persist all security information about users and groups. WebLogic lets you configure Authenticators that can access various LDAP stores, including Open LDAP, Sun's iPlanet, Microsoft's Active Directory, and Novell NDS.

In addition, you may assign custom-built Authenticators and Identity Asserters to the security realm.

In order to access the Authentication Providers assigned to a realm, select the Authentication node from the left pane of the Administration Console. The right pane then lets you select one of the configured Authenticators, or configure a new Authenticator.

A security realm can have a sequence of Authentication Providers (and hence JAAS LoginModules) working in unison. Each Authentication Provider has a JAAS control flag setting that determines how the overall login sequence behaves with respect to that particular Authentication Provider. This is no different from how you configure multiple LoginModules within a J2SE application. To order the Authentication Providers within a security realm, select the Authentication node from the left pane and choose the Re-order the Configured Authentication Providers option. The control flag of each authentication provider can take the following values:

REQUIRED

This option is the default setting for any Authentication Provider. A required Authentication Provider is always invoked, irrespective of the control flag settings on other providers. The overall authentication cannot succeed if any REQUIRED provider fails. Thus, REQUIRED providers are always invoked, and overall authentication fails if any one of them fails.

REQUISITE

This option also requires the Authentication Provider to succeed during the login sequence. However, all of the REQUISITE providers need not be invoked for the overall authentication to succeed. If a REQUISITE provider succeeds, the authentication proceeds as normal to other providers in the sequence. However, if it fails, the overall authentication cannot succeed, and control is immediately passed back to the application once all REQUIRED providers in the login sequence have been invoked.

SUFFICIENT

This option does not require the Authentication Provider to succeed during the login sequence. If a SUFFICIENT provider does succeed, the overall authentication proceeds to ensure that only the remaining REQUIRED providers in the login sequence are executed. However, if it fails, the overall authentication proceeds as normal to the other providers in the login sequence.

OPTIONAL

This option does not require the Authentication Provider to succeed during the login sequence. Regardless of whether an OPTIONAL provider succeeds, the authentication proceeds to other providers that have been configured as part of the login sequence.

When multiple LoginModules are used to authenticate a user, the authentication occurs in two phases. During the first phase, the modules are asked to attempt to authenticate the user. Only if the modules pass this phase is the second phase invoked. During the second phase, each module commits the login and assigns the relevant principals to the subject. The control flags influence how this two-phase commit occurs. Thus, for the overall authentication to succeed, the following rules must be met:

• All REQUIRED modules must be invoked, and each must successfully validate the user.
• Any REQUISITE module that gets invoked must successfully validate the user.
• If a SUFFICIENT module successfully validates the user, the overall success depends on the success of all REQUIRED modules, and any REQUISITE modules invoked before the SUFFICIENT module.
• If the login sequence consists only of OPTIONAL modules, at least one module must successfully validate the user.

Though you can write your own Authenticators, WebLogic's default implementation of the SSPIs comes with a number of built-in authenticators that you can use. Let's look at these authenticators in more detail.

17.4.2.1 The Default Authenticator

The Default Authenticator authenticates against the embedded LDAP repository. It provides the notion of a user and group and stores user and group information in its own repository, allowing you to manipulate this information. The only configurable option provided by this Authenticator is the Minimum Password Length setting. By default, all WebLogic users must specify a password that is at least eight characters in length; the password length is validated when the user is created. When you log on to the Administration Server using the console or through a JNDI context, it is generally this authenticator that validates the username and passwords you supply. Of course, the control flag will determine exactly which providers are called.

17.4.2.2 Configuring an LDAP authenticator

WebLogic also lets you configure an Authentication Provider that can use existing external LDAP directories such as iPlanet LDAP, Active Directory, Open LDAP, and Novell NDS. In fact, WebLogic's LDAP Authenticators can interface with any LDAP v3-compliant directory servers. In this section, we look at how you can set up an iPlanet Authenticator for your security realm. Other LDAP Authenticators can be configured along the same lines. By using one of the LDAP Authenticators, you can configure WebLogic to recognize users and groups defined in the LDAP repositories and authenticate against this information.

First, select the Authentication node under the realm from the left frame of the Administration Console. If you're using the default security realm myrealm, then the node will be under Security/Realms/myrealm/Providers. Then, select the "Configure a new iPlanet Authenticator" option, either by right-clicking the node or from the right frame itself. Now under the General tab on the right, you'll see the overall details of the new Authenticator. Choose a name for the Authenticator and make sure that the value of the JAAS Control Flag is Required, and then hit the Create button.

Now select the iPlanet LDAP tab, and enter the values for the host, port, and principal as they apply to your LDAP server. Here, the principal refers to the distinguished name (DN) of the LDAP user that WebLogic will use to connect to the LDAP Server. Typically, you'll use the DN associated with some administrative user account on the LDAP server. For iPlanet LDAP, this is usually uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot. If the LDAP server is listening on an SSL port, tick the SSL Enabled option and ensure that you've specified the SSL port. Now hit the Apply button to save changes to the form. Next, change the Credential attribute for the LDAP Principal. In the new screen, you must enter the password that will be used to authenticate the LDAP user defined in the Principal attribute.

Now, select the Users tab and make sure the fields in this form match the configuration of your LDAP repository. In most cases, you will need to modify only the value of the User Base DN attribute to ou=people, o=mydomain.com. This attribute defines the base DN of the branch within the LDAP tree that holds the actual users. Table 17-3 lists the other configuration settings under the Users tab.

WebLogic populates these fields with sensible default values, so in most cases you won't have to alter them. Hit the Apply button and move on to the Groups tab. Again, you need to ensure the settings accurately reflect the structure of your LDAP repository. In most cases, you will need to modify only the Group Base DN setting to (say) ou=groups, o=mydomain.com. Table 17-4 lists the other configuration settings available under the Groups tab.

These settings are pretty straightforward, and they have the same semantics as the attributes under the Users tab, just applied to groups.

The Membership tab determines how group members are stored and located in the LDAP directory. WebLogic specifies default values for all fields in the form. Table 17-5 lists two important attributes under the Membership tab.

Unlike the other authentication providers, the iPlanet provider also supports dynamic groups for which there are additional options.

Now that you have configured the LDAP Authenticator, you are almost ready to reboot the Administration Server. However, you need to ensure that the server's boot identity (i.e., the WebLogic user account used to start the server) corresponds to an LDAP user with the necessary Admin privileges. This means you need to use the iPlanet Console (or any management tool specific to the LDAP server) and complete the following steps:

1. Create an Administrators group in the LDAP repository and place the LDAP user, which is associated with WebLogic's boot identity, in this group.
2. If you are unable to create an Administrators group, create a new group in the LDAP Repository say, MyAdministrators. Make the LDAP user, which is associated with WebLogic's boot identity, a member of the MyAdministrators group. Then using WebLogic's Administration Console, assign the MyAdministrators group to the default global role Admin.

By doing this, you guarantee that WebLogic's boot identity has the required Admin privileges. The next time you restart the server, go into the Administration Console and remove the Default Authenticator from the list of Authentication Providers. Once you've applied these changes, restart the server hopefully, you should be able to boot without any authentication errors and set up your WebLogic domain to use the LDAP repository for its user and group information base.

17.4.2.3 The Default Identity Asserter

The Default Identity Asserter supports perimeter authentication using either X.509 certificates or IIOP CORBA Common Secure Interoperability Version 2 (CSIv2) tokens. A good example of perimeter authentication is when you configure a web application to use CLIENT-CERT authentication. In this case, WebLogic can perform identity assertion based on values from request headers and cookies. If the header name or cookie name matches the active token type for the provider, the value is passed to the provider.

This provider requires you to configure the following attributes:

User Name Mapper Class Name

This attribute specifies the name of a Java class that maps the X.509 certificates or X.501 DNS to WebLogic users, according to some scheme. The User Name Mapping class must implement the weblogic.security.providers.authentication.UserNameMapper interface, and also must be available in WebLogic's CLASSPATH during startup.

Trusted Client Principals

This attribute specifies a list of client principals that may rely on CSIv2 identity assertion. You can use the wildcard character (*) to indicate that all client principals are trusted. If a client principal isn't included in this list, the CSIv2 identity assertion fails and access is denied.

Note that Identity Assertion Providers do not verify proof material. A user can forge a CSIv2 token, for instance, and assume a false identity. Because WebLogic cannot trust such tokens, the Trusted Client Principals setting offers a way to restrict the set of client principals that can use identity assertion. We saw a good example of using X.509 certificates as perimeter authentication in the previous chapter, where we also supplied a custom username mapper class for mapping digital certificates to WebLogic users. When using two-way SSL and X.509 certificates for identity assertion, the SSL protocol ensures that the certificate is not forged. So, the Trusted Client Principals setting applies only to CSIv2 identity tokens.

WebLogic 8.1 comes with a default username mapper that you can enable from the Details tab. This is a general username mapper that can be configured to extract a username from a given attribute of the subject DN field in a certificate. So, for example, if the client's certificate has an email attribute (E), then you can set the Default User Name Mapper Attribute Type to E. You also can specify a delimiter, in which case WebLogic will use that part of the attribute up to but not including the delimiter. For instance, if you need to extract a username from the email attribute, you will want to use the delimiter @. Other attribute types that can be used are the C, CN, L, O, OU, S, and ST types. If you need anything more complex than this, you will have to create your own username mapper class. See Example 17-2 later in this chapter to learn how you can write a custom username mapper.

17.4.3 Authorization Providers

Authorization is synonymous with access control it determines whether a subject has access to a resource. Whenever an application requests an operation on a protected resource, the resource container that receives the request calls the WebLogic Security framework to determine whether the user is authorized to access the resource. In making this call, any relevant request parameters, such as the subject making the request, are passed to the framework. A few things need to happen before an access decision can be made, as illustrated in Figure 17-4.

Figure 17-4. The authorization process

First, the configured Role Mapping Providers are invoked. These providers use the request parameters to determine a set of roles that are valid for the subject. After this, the Authorization Providers are asked to decide whether access should be allowed. The Adjudication Provider has the final say in the matter. It looks at the different access decisions returned by the Authorization Providers and reconciles any potential conflicts. The Adjudication Provider generates a final verdict based on these individual access decisions.

A realm may include one or more Authorization Providers. For instance, you could define Authorization Providers that separately control access to JNDI branches, web applications, JMS connection factories, and more.

17.4.3.1 The Default Authorization Provider

WebLogic's Authorization Provider performs the aforementioned tasks by using a policy-based authorization engine. This means that WebLogic's resources are protected via security policies assigned at deployment time. Earlier, in Section 17.3, we looked at how your security policy statements can help protect server-side resources.

Security policies may be assigned manually through the Administration Console, or automatically via the role settings specified in deployment descriptors. The Default Authorizer lets you specify whether the authorizer will store policies that are created when EJBs and web applications are deployed. The Policy Deployment Enabled option indicates whether the provider will evaluate security policies while EJBs and web applications are being deployed. By default, this setting is enabled. This option is quite similar to the Role Deployment Enabled flag in the Role Mapping Provider.

17.4.4 Role Mapping Providers

A Role Mapping Provider determines dynamically at call time the set of roles that are valid for a particular subject when it tries to access a protected resource. An Authorization Provider can then use this information to determine whether a user is allowed access to the resource by evaluating the policy and role information.

The role information is generally based on the role settings defined in J2EE and WebLogic-specific deployment descriptors, the requested operation on the resource, and any custom business logic. You can configure these roles at deployment time, either using the deployment descriptors or via the Administration Console. Because the Authorization Provider makes calls to the Role Mapping Provider just before calculating an authorization decision, and because the role binding occurs dynamically, this gives you the ideal opportunity to embed your own logic for role allocation into a custom provider.

A security realm can define one or more Role Mapping Providers. You could configure a Role Mapping Provider that handles role associations for resources bound to the JNDI tree, or another that handles role associations for web applications.

17.4.4.1 The Default Role Mapper

Given a protected resource and a user, WebLogic's default Role Mapping Provider will determine all the roles that are valid for that user for the resource using the role information stored in its repository. In order to configure the Default Role Mapper, select the Default Role Mapper node from under the Role Mapping node in the left pane of the Administration Console.

The Default Role Mapper has one configuration setting only: the Role Deployment Enabled option. This indicates whether the provider stores roles that are created while deploying a web application or EJB. This setting is similar to the Ignore Security Data in Deployment Descriptors setting that we encountered earlier, except that it is specific to role information. If the Role Deployment Enabled option is set, WebLogic automatically creates roles based on security data in the deployment descriptors and stores them in the embedded LDAP server. This means that if you subsequently ignore the security data in the deployment descriptors, the deployment descriptors won't be processed the next time the EJB or web application is deployed. By default, the Role Deployment Enabled setting is enabled, and you need at least one role mapper with this setting enabled in order to deploy web applications and EJBs.

17.4.5 Adjudication Providers

A subject may access a protected resource in a way that requires multiple Authorization Providers to decide whether the subject has access to the protected resource. Each Authorization Provider may pass one of the following access decisions: PERMIT, ABSTAIN, or DENY. The Adjudication Provider needs to arbitrate between potentially conflicting decisions made by the different Authorization Providers involved. Typically, the Adjudication Provider resolves potential authorization conflicts among the Authorization Providers by carefully weighing the access decisions of each provider.

Thus, you must define an Adjudication Provider if the security realm supports multiple Authorization Providers. Clearly, a security realm may have only a single Adjudication Provider!

17.4.5.1 The Default Adjudicator

In order to configure the Default Adjudicator, select the Default Adjudicator node from under the Adjudication node in the left frame of the Administration Console. Here you can adjust the Requires Unanimous Permit setting, which determines the basis on which the Adjudicator grants access to a resource when multiple Authorization Providers are concerned.

If this setting is enabled, the Adjudicator grants access to the resource only if all participating Authorization Providers return a result of PERMIT. That is, the decision must be a unanimous PERMIT decision. If any provider returns a DENY or ABSTAIN, the overall decision must be to refuse access.

If the setting is disabled, the Adjudicator grants access to the resource only if no Authorization Provider returns a DENY. This means that the Adjudicator will grant access to the resource even though a unanimous decision could not be reached. So long as all Authorization Providers vote to PERMIT or ABSTAIN, the subject will be allowed to access the resource. Of course, at least one Authorization Provider must vote to PERMIT access to the resource.

17.4.6 Credential Mapping Providers

When a WebLogic user needs to access some external systems, the credentials of the user need to be mapped to valid credentials on the external system. Only then can a subject already authenticated by WebLogic log into the external system. A Credential Mapping Provider is responsible for associating users authenticated by WebLogic to appropriate credentials in an external system. Typically, the Credential Mapping Provider is invoked by WebLogic on behalf of another component in particular, the container that hosts a resource adapter that needs to connect to a remote resource.

A Credential Mapping Provider can handle different kinds of user credentials e.g., a username-password combination, a digital certificate, and more. For instance, you could implement a credential map between WebLogic users and credentials of valid users on a remote legacy DBMS. This could be the username-password combination of a valid user on the remote system who is authorized to perform the necessary operations. You can define these credential mappings either in the deployment descriptors or via the Administration Console. A security realm must define at least one Credential Mapping Provider. If you've defined multiple providers, WebLogic queries all providers and returns a list of credentials that may be associated with the WebLogic user.

17.4.6.1 The Default Credential Mapper

WebLogic's Credential Mapper associates WebLogic users to appropriate credentials in an external system when a user makes use of a resource adapter. So, the Credential Mapping Provider holds a map of WebLogic users and groups to external identities that can be used to authenticate to a remote system. A good example of this is the use of J2EE connectors. Here you typically need to map a WebLogic user to a remote user that has access to the target EIS. Chapter 7 shows how to configure credential maps for deployed J2EE connectors.

In order to configure the provider itself select the Default Credential Mapper node from under Providers/Credential Mapping in your security realm. The Default Credential Mapper provides only one configuration setting, the Credential Mapping Deployment Enabled option, which indicates whether the provider processes the credential maps from the descriptor files of a resource adapter when it is deployed. By default, the Credential Mapping Deployment Enabled flag is set to true. Like the other Deployment Enabled settings, if you disable this setting, the credential maps specified in the deployment descriptor for the resource adapter won't overwrite the credential maps you may have created via the Administration Console.

17.4.7 Auditing Providers

Auditing is another important feature of WebLogic's security framework. Nonrepudiation requires that you maintain a log of security events that provides an electronic trace of how the data has been accessed. WebLogic's Auditing Provider can be configured to log information about security requests and their outcomes. Usually, the Auditing Provider is invoked by WebLogic's Auditor on behalf of other security providers, both before and after a security operation has been executed. In this way, the Auditor is able to capture detailed information about any security requests and responses.

Typically, the Auditing Provider will decide whether to audit the security request based on several criteria. For instance, you could configure a security level for the Auditing Provider that automatically filters out audit requests that do not reach the desired security level. An Auditing Provider also supports channels that can record the information to a variety of sinks, such as an LDAP store, database table, or plain file. WebLogic's Auditor can interact with multiple Auditing Providers. However, you may choose not to define any Auditing Provider for a security realm.

17.4.7.1 The Default Auditor

By default, there are no Auditing Providers configured for a security realm. In order to configure a new Auditing Provider, expand the Auditing node from the left frame of the Administration Console and then choose the "Configure a new Default Auditor" option. In the new screen, assign a severity level for the audit log and hit the Create button.

The severity level determines the kind of events that are logged by WebLogic's Default Auditor. The lower the severity level, the more verbose the auditing. The severity level can be chosen from the following (in increasing order of verbosity): FAILURE, SUCCESS, ERROR, WARNING, and INFORMATION. For example, a severity level of FAILURE ensures that the Auditor logs only security requests that have failed (e.g., failed authentication), while a severity level of INFORMATION ensures that the Auditor logs all authentication activity. The default severity level is ERROR.

The audit information is written to the mydomainmyserverDefaultAuditRecorder.log file, where mydomain is the name of the WebLogic domain. For example, if an authenticated user attempts to dip into a connection pool and is denied access, the Default Auditor logs the following information:

#### Audit Record Begin <05-Sep-02 22:24:46> << <>, application=, module=, resourceType=ConnectionPool, resource=MyPool, action=reserve>>> Audit Record End ####

17.4.8 The Embedded LDAP Server

Any implementation of the SSPIs requires some kind of security provider database that can act as a repository for the domain's security data. WebLogic relies on an embedded LDAP server to persist all of its information about users, groups, policies, roles, and user credentials. The embedded LDAP server is accessible to all of WebLogic's security providers that need to store and manipulate such data: the Authentication, Authorization, Role Mapping, and Credential Mapping Providers. In the default setup, the Administration Server holds a master LDAP repository, and this repository is then replicated to all Managed Servers. Any changes made by WebLogic's providers are sent to the master LDAP server, which then sends the appropriate changes to each replicated server. Managed Servers in the domain are synchronized as soon as the data is changed on the Administration Server's LDAP repository. There is, however, a small window between the write to the Administration Server and the replication due to network traffic.

To configure the embedded LDAP server, select your domain from the left frame of the Administration Console. Choose the View Domain-Wide Security Settings[3] option and select the Configuration/Embedded LDAP tab. Table 17-6 lists the various settings that can be configured from the Embedded LDAP tab.

[3] WebLogic 7.0 users should just choose the Security/Embedded LDAP tab after selecting the domain node.

Note how the LDAP server can be configured to back itself up. The backup files are written to a directory called mydomainservernameldapackup and can be used to replace those files in the ldapfiles directory.

17.4.8.1 External access to the LDAP server

You can use your favorite LDAP browser to gain access to WebLogic's embedded LDAP server. This may be useful for integration purposes, or perhaps more usefully as providing a way of importing and exporting user data. Before accessing the server, you need to set up its security credential. Select the Embedded LDAP tab as described in the previous section. Then select the Credential option and enter a credential (password) for the LDAP server. WebLogic will use this password to authenticate any LDAP clients.

Now start up your favorite LDAP browser and point it to the following URL:

ldap://hostname:port/dc=mydomain

Here, mydomain refers to the name of the WebLogic domain. The LDAP server isn't set up for anonymous access, so you must specify the username cn=Admin. For the password, you need to supply the same credentials you configured earlier for WebLogic's embedded LDAP server. You then can browse the LDAP data, which includes information about the users, groups, security roles, policy statements, and more.

Some LDAP browsers also let you import and export the LDAP data in the LDIF format. This provides you with an easy way to migrate some data, such as the information on users and groups located under the DNs ou=people,ou=myrealm,dc=mydomain and ou=groups,ou=myrealm,dc=mydomain, respectively. Once again, myrealm refers to the name of the security realm, while mydomain refers to the name of the WebLogic domain. Experienced administrators can further restrict access to the embedded LDAP server. Because WebLogic's LDAP server also supports the IETF LDAP Access Control Model, you can implement fine-grained access to the LDAP server if the need arises.

In WebLogic 8.1, many security providers also permit the export and import of their data. You can find this facility on the Migration tab of the Authentication, Authorization, Credential Mapper, and Role Mapper Providers.