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* option and select the Configuration/Embedded LDAP tab. Table 17-6 lists the various settings that can be configured from the Embedded LDAP tab.
* WebLogic 7.0 users should just choose the Security/Embedded LDAP tab after selecting the domain node.
Table 17-6. Configuring the embedded LDAP server
|Credential||This setting specifies a password that allows you to connect to the LDAP server.|
|Backup Hour/Minute||This setting determines the hour/minute when the backups are supposed to occur.|
|Backup Copies||This setting determines the number of backup copies of the LDAP data that should be made.|
|Cache Enabled||This option indicates whether caching is enabled for the LDAP server.|
|Cache Size||This setting determines the size of the cache used by the LDAP server.|
|Cache TTL||This setting determines the duration for which items are held in the cache.|
|Replica Refresh||By default, changes are sent periodically to the Managed Servers. If you've made a number of changes while a Managed Server has been down, then sending a large number of changes may be expensive. To optimize this, enabling this parameter ensures all of the replicated data will be refreshed as a whole at boot time.|
|Master First||In extreme cases, you can enable this flag so that any Managed Server must contact the master LDAP server instead of its local LDAP server.|
Note how the LDAP server can be configured to back itself up. The backup files are written to a directory called mydomain\servername\ldap\backup and can be used to replace those files in the ldapfiles directory.
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:
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
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.
Configuring Trust Between Two Domains
Two or more WebLogic domains can be configured so that they trust each other. When you've set up trust between two different WebLogic domains, you enable authenticated WebLogic users in one domain to access protected resources in another domain. For instance, an authenticated user in one domain may invoke a protected web service or an EJB in another domain without requiring any additional authentication. Let's say that we have two WebLogic domains, A and B. Trust between the domains means that the subject's principals in one domain—say, A— are accepted by the other domain, B (and vice versa) and are treated as if they were local principals of domain B. The Authorization Providers within domain B remain unaware of the fact that the subject's principals belong to domain A.
Two WebLogic domains will trust each other only if they both have the same Credential attribute. The Credential attribute represents a string value that is assigned to a domain and then is used to sign principals that belong to subjects created in that domain. Ordinarily, if you haven't explicitly set the domain credential, it is assigned a random value when the Administration Server is first booted. All Managed Servers in the domain subsequently import this credential when they are booted as well. In order to set the Credential attribute for a WebLogic domain, select your domain from the left pane of the Administration Console, choose the View Domain-Wide Security Settings* option, and select the Configuration/Advanced tab. If two domains share the same Credential attribute value, the signatures of the principals will match and be recognized by both domains. Thus, in order to establish trust between several domains, you need to simply ensure they are assigned the same value for the Credential attribute.
JAAS Authentication in a Client
We already have seen many examples of how a Java client authenticates itself to WebLogic Server. In most cases, the client submits a username-password combination as its credentials when setting up the JNDI context:
Hashtable env = new Hashtable( ); env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); env.put(Context.PROVIDER_URL, "t3://10.0.10.10:7001"); env.put(Context.SECURITY_PRINCIPAL, "system"); env.put(Context.SECURITY_CREDENTIALS, "12341234"); Context ctx = new InitialContext(env); // use the JNDI context as "system" user ...
WebLogic also lets you build Java clients that can use the more standard approach to authentication using JAAS. Even though JAAS authentication is somewhat more long-winded than traditional JNDI-based authentication, your clients will be more portable. Because of the pluggable nature of the JAAS framework, it should enable you to benefit from future changes to the authentication technology without changes to the client code.
Anatomy of a JAAS Client
A JAAS client involves the interplay among a number of classes and interfaces, as shown in Figure 17-5. Let's examine how these different objects interact during JAAS-style authentication:
- This represents the goal of the authentication sequence. Once a client has been authenticated, it obtains a Subject instance that is populated with all of the principals that map to the client.
- This is responsible for populating the
Subjectwith its principals. Its allimportant
login( )method delivers an authenticated
Subjectback to the client. To construct a LoginContext instance, you need to supply objects of two subsidiary classes: a
- This is responsible for retrieving the username and password of the client being
authenticated. In the case of a Swing-based application, the
CallBackHandlerinstance could conceivably pop up a dialog box requesting the data from the end user. In fact, the
CallBackHandlerinstance is invoked by the
This is any entity capable of authenticating the user's credentials. A separate JAAS configuration file settles how the
LoginModuleis implemented. In general, you can implement your own login modules. However, WebLogic also provides you with a convenient
LoginModulethat can authenticate the client via the supplied username and password against a WebLogic instance whose URL is also supplied. On successful authentication, the
LoginModulepopulates the subject with its principals. Using this authenticated subject, the JAAS client can now perform one or more privileged actions.
Figure 17-5. Typical interaction when authenticating a JAAS client
- Any class that implements the
PrivilegedActioninterface encapsulates the code that a Java client can run within the security context defined by the populated
weblogic.security.Security.runAs( )method allows the client to associate a
Subjectwith the current thread, before invoking the privileged action under this security context.