Covering J2EE Security and WebLogic Topics

WebLogic Embedded LDAP Logging

I recently wrote about WebLogic’s Embedded LDAP server and gave some details and tricks that you might find useful. What I didn’t cover was the logging capabilities of the embedded LDAP server. I’m going to rectify that oversight with this post. I also added the content below to the original post called “WebLogic Embedded LDAP.”

Embedded LDAP has log files for debug output and access events. The location and name of these files is set in the <domain_dir>/myserver/ldap/conf/vde.props file. Among other settings, in that file you will find

vde.logfile=log/EmbeddedLDAP.log
vde.accesslogfile=log/EmbeddedLDAPAccess.log

where vde.logfile points to the debug log and vde.accesslogfile points to the access log. You can change these entries if you’d like, but you’ll find the default log files in the <domain_dir>/myserver/ldap/log directory.

Now, if you check your domain for these files, you’ll find that they are there but that perhaps there’s nothing in them. The reason is that they are only written to under certain conditions.

The access log file is only written to when the access is from an external client. A WebLogic server calling its own embedded LDAP does not count. If you use an LDAP browser to view the contents of the embedded LDAP, for example, all accesses from the browser will be logged in the access log as you’d expect.

The debug log file is only written to when certain debug flags are set. To enable debug output, add the following stanza to the server element in config.xml:

<serverdebug DebugEmbeddedLDAP="true"
             DebugEmbeddedLDAPLogToConsole="true"
             DebugEmbeddedLDAPLogLevel="9"
             Name="myserver"/>

The DebugEmbeddedLDAP element toggles LDAP debugging. When toggled on, the output goes to the log file defined in vde.props. The DebugEmbeddedLDAPLogToConsole optionally sends the same output to WebLogic’s standard out. Finally, DebugEmbeddedLDAPLogLevel sets the level of the events to log. The possible level values are:

  • 0 = errors only
  • 5 = normal
  • 7 = verbose
  • 9 = very verbose

You’ll need to change the Name attribute if your WebLogic server name is not “myserver.” After adding the debug flags to config.xml you’ll have to restart WebLogic for the changes to take effect.

How useful are these log files?

The access log can be very useful when you have external clients accessing embedded LDAP. The logging is just like what you’d find in an iPlanet LDAP server access log. On the other hand, the debug log file is not very useful at all. But for those exceedingly rare times when you need log output from embedded LDAP, it’s nice to know that you can get it.

Free Download: Consolidated Browser

In a recent post I mentioned RSS and the free newsletter as alternatives to manually checking to see if this site has been updated. Today, I’d like to offer you something I’ve been using for a while to monitor sites that don’t have RSS feeds. I call it the Consolidated Browser.

The Consolidated Browser is nothing more than an HTML page that you store on your computer and load in your browser. You configure it to point to your sites of interest. All it does is display those sites in a stack of iframes in your browser window. There are quicklinks to each site’s iframe and the entire collection refreshes at a configurable interval. All you need to do is slide the outer scrollbar to see if anything has changed on the sites.

Configuration is easy. Edit the file and change the following section to point to your favorite sites:

// MODIFY THIS
sites[0] = “monduke.com”;
sites[1] = “www.jroller.com/page/whoami”;
sites[2] = “www.cnn.com”;
// MODIFY THIS

You can have as many sites as you wish. Simply increase the index number by one for each new site.

The entire page of entries is refreshed every ten minutes by default. To change the interval (in seconds), change 600 in the following line:

<meta http-equiv=”refresh” content=”600″>

That’s all there is to it. It’s cheesy but effective. I like to keep my Consolidated Browser in a Firefox tab for easy access. Throw it on a web server and you can quickly check your sites wherever you go.

You’re free to modify and distribute the file however you’d like. Please let me know if you make any improvements. You don’t have to, of course, but I’d love to hear your ideas.

Right click here and choose Save Link As to download the Consolidated Browser.

WebLogic Embedded LDAP

Nestled snugly inside each and every instance of WebLogic Server is an embedded LDAP server, humming away and providing storage for the security realm. Even though it’s so central to WLS, the embedded LDAP very rarely makes its presence known. This article will describe what the embedded LDAP does and how you can leverage it.

The Beginning

Beginnings. Every story has one. This one starts out with a company (recently acquired by Oracle) named Octet String. BEA integrated Octet String’s embeddable Virtual Directory Engine (VDE) as part of WebLogic 7. This is why you sometimes see “octetstring” in the package names given in stack traces and files named vde*.* in the WebLogic directories. It doesn’t seem that the embedded VDE was used to its full potential given this Octet String blurb about it:

Real-time Access to Multiple Data Stores Powered by VDE

Regardless, I don’t know whether Octet String or BEA maintains the code base in WLS now, but Octet String was bought by Oracle in November 2005. Oops!

A Daily Dose o’ LDAP

A default WLS domain uses embedded LDAP to manage users, groups, roles, and security policies. In fact, most of the security providers prefixed with the word “Default” use the embedded LDAP as their database. So, unless you’ve set up other providers, working with user and group data in the WLS console is all backed by the embedded LDAP. Additionally, the security policies you define in your deployment descriptors and via the console are stored there, too.

Managing Embedded LDAP

For all practical purposes, the embedded LDAP is just another LDAP server. As a result, you can do the following things:

  • Make backups
  • Configure replication
  • Configure caching
  • Export/import data
  • Set access control
  • Browse the directory with an external LDAP viewer

All of these details are covered in BEA’s Managing the Embedded LDAP Server document so I won’t go into these items here. What I will talk about next is a few tips and tricks that I’ve learned over time.

Keep an Eye on Your Cache

By default, embedded LDAP caches data for 60 seconds. I’ve been burned by this cache more times than I’d care to admit. I guess I’m a slow learner.

What can happen is you make a change to the data, try your application expecting it to use that data, and then wonder why it didn’t. That’s the bite of the cache. You could temporarily disable caching or lower your cache TTL while you’re manipulating the data to minimize this problem.

Lok’d Out

Occasionally you might have difficulty starting the server due to an error message like this:

…myserver\ldap\ldapfiles\EmbeddedLDAP.lok (The process cannot access the file because it is being used by another process)

The EmbeddedLDAP.lok file ensures that only one WebLogic server can access an embedded LDAP instance. Double-check to make sure that the WLS instance is not already running. One easy way to do this is to try to pull up the WLS console in a browser. If it comes up, the server is running, of course. If it’s not, try deleting the EmbeddedLDAP.lok file.

Scheming Minds

By default, modifying the embedded LDAP’s schema is not possible. That makes sense since you don’t want to inadvertently break something in the security realm. However, with a minor configuration change you can make limited adjustments to the schema.

Edit the <domain_dir>\myserver\ldap\conf\vde.prop file and change vde.schemacheck to 0. Upon restarting the WebLogic server, you can now make some changes to the schema but to nowhere near the degree to which you can modify external LDAP directories.

In general, though, you probably don’t want to make any schema changes to embedded LDAP but it’s good to know that you can.

Logging

Embedded LDAP has log files for debug output and access events. The location and name of these files is set in the <domain_dir>/myserver/ldap/conf/vde.props file. Among other settings, in that file you will find

vde.logfile=log/EmbeddedLDAP.log
vde.accesslogfile=log/EmbeddedLDAPAccess.log

where vde.logfile points to the debug log and vde.accesslogfile points to the access log. You can change these entries if you’d like, but you’ll find the default log files in the <domain_dir>/myserver/ldap/log directory.

Now, if you check your domain for these files, you’ll find that they are there but that perhaps there’s nothing in them. The reason is that they are only written to under certain conditions.

The access log file is only written to when the access is from an external client. A WebLogic server calling its own embedded LDAP does not count. If you use an LDAP browser to view the contents of the embedded LDAP, for example, all accesses from the browser will be logged in the access log as you’d expect.

The debug log file is only written to when certain debug flags are set. To enable debug output, add the following stanza to the server element in config.xml:

<serverdebug DebugEmbeddedLDAP="true"
             DebugEmbeddedLDAPLogToConsole="true"
             DebugEmbeddedLDAPLogLevel="9"
             Name="myserver"/>

The DebugEmbeddedLDAP element toggles LDAP debugging. When toggled on, the output goes to the log file defined in vde.props. The DebugEmbeddedLDAPLogToConsole optionally sends the same output to WebLogic’s standard out. Finally, DebugEmbeddedLDAPLogLevel sets the level of the events to log. The possible level values are:

  • 0 = errors only
  • 5 = normal
  • 7 = verbose
  • 9 = very verbose

You’ll need to change the Name attribute if your WebLogic server name is not “myserver.” After adding the debug flags to config.xml you’ll have to restart WebLogic for the changes to take effect.

How useful are these log files?

The access log can be very useful when you have external clients accessing embedded LDAP. The logging is just like what you’d find in an iPlanet LDAP server access log. On the other hand, the debug log file is not very useful at all. But for those exceedingly rare times when you need log output from embedded LDAP, it’s nice to know that you can get it.

Tales from the Crypt

I know you’re dying to know which encryption algorithm is used to secure the passwords in embedded LDAP. Maybe not, but I’ll tell you anyway. It’s SHA-1 with a 32 bit salt and 1,000 iterations. Don’t you feel better just knowing that? 😉

Converting Unbelievers

Some people don’t realize the power of the plug-and-play nature of the WebLogic security framework. Here’s a simple test you can do that demonstrates getting user information from an external data source. The only thing you need for this test is a WebLogic installation.

You need two WLS domains. One domain is your baseline domain. The second domain will simulate an external LDAP server that the first domain will use for access control. Build the domains and make sure that they have unique ports. I recommend setting the “LDAP” domain port to 389 (if you can) to drive home the point that this domain is simulating an LDAP server.

NOTE: The latest Firefox (1.5.0.1) won’t let you navigate to a web app on port 389. Upon trying to do so, it says: “This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.” Yes, 389 is the standard LDAP port but this is annoying. If you are using FireFox, use a port other than 389.

After starting your domains, add a user to the LDAP domain and then add this user to the Administrators group. Change the embedded LDAP password as specified in the Managing the Embedded LDAP Server document. You’ll need this password in a moment.

In the baseline domain, we want to configure the security framework to use the external LDAP server. To do this, we’ll add a new authentication provider that points to the LDAP domain.

In the WLS Console for the baseline domain, navigate to and click the authentication node in the Security section. On the right hand side, click on the Configure a new iPlanet Authenticator link. Set the Control Flag to Sufficient and click Create.

On the iPlanet LDAP tab, set the Principal to “cn=Admin” (without the quotes) and the two Credential fields to the password you specified for the embedded LDAP credential in the LDAP domain. Click Apply.

This paragraph assumes that your LDAP domain is named “LDAP.” If it’s not, substitute your LDAP domain name for “LDAP.” On the Users tab, set the User Base DN to ou=people,ou=myrealm,dc=LDAP and click Apply. Then, on the Groups tab, set the Group Base DN to ou=groups,ou=myrealm,dc=LDAP and click Apply.

Finally, click on the DefaultAuthenticator node, set the Control Flag field to Sufficient, and click Apply. If it’s left at Required, you won’t be able to authenticate with the user defined in the LDAP domain since the user is required to be in the baseline’s embedded LDAP. Can’t have that…

Changes to the security realm configuration require a server restart so do that now. Restart the LDAP domain, too. When both servers start, access the baseline domain’s Console application, but log in using the username and password of the user you created in the LDAP domain. If everything is configured correctly, you should gain access.

(Interestingly, you can have a look at the users in the baseline domain via the Console. You’ll see a list of all the users in the security realm broken out by data source. That way, you know which users are in your embedded LDAP and which ones are in the external LDAP. You can do the same thing for groups.)

What we’ve done with this little experiment is to demonstrate how easy it is to externalize your user and group data with the WebLogic security framework. The embedded LDAP server in the LDAP domain served as an external data store for the baseline domain’s security realm. I find that humorous for some reason. :-)

An even simpler (yet very freaky!) experiment would be to just use the baseline domain. Set the LDAP credential and iPlanet authenticator as mentioned above but for the baseline domain. When you set the iPlanet authenticator, point it to the baseline server. The iPlanet authenticator is thus pointing to the server in which it’s running. Finally, remove the DefaultAuthenticator and DefaultAuthorizer and then restart the server.

I haven’t actually tried this one but it’s an interesting thought experiment, at least.

Production Usage

While I haven’t seen any official stance on this from BEA, I’ve heard more than once that the embedded LDAP shouldn’t be used for production. Instead, use an external LDAP or other data store for your users and groups.

Wrap-Up

I hope you found this brief tour of embedded LDAP useful. I’ve shown some ways in which you can leverage embedded LDAP and described a quick experiment for configuring the WebLogic security framework to use an external LDAP server.

Steve’s PKI Overview

Steve Nakhla posted a good PKI overview with the promise of more detail to come. He also introduced his open source CA server effort, Odyssi CA.

WebLogic Security Framework Overview

I’ve mentioned the WebLogic security framework in the following posts:

However, the discussion detail was either from low earth orbit or zoomed in on a particular plugin, neither of which suitably covered the framework. Since I plan on talking more about the security framework, now is probably a pretty good time to have a look at it as a whole to see how it can meet your needs for application security.

The WebLogic security framework was introduced in WebLogic 7 and continues relatively unchanged in WebLogic 9. The framework provides a modular, plugin-based approach to handling the typical needs of application security. This modularity enables third-party providers and developers alike to create custom plugins for functions such as authentication or authorization. I’ll talk more about plugins in later.

Security Aspects of the J2EE Specification

The security framework is WebLogic’s implementation of the security aspects of the J2EE specification. As a result, it provides container-managed security features for your applications. This is significant because you may not have to write any security code in your application. Instead, you declaratively define security constraints on your resources (such as web pages or EJBs) in XML files and then let WebLogic intercept user requests to ensure that the user is authorized for access.

The container-managed security notion is from the J2EE spec, but the security framework allows for flexible configurations that don’t break the spec. That’s important because it leaves you breathing room for implementing custom security functionality while continuing to work within the confines of the spec.

Adhering to the J2EE specification buys you several things. They are:

  • Standard declarative security definitions for protecting resources
  • Standard programmatic access to the name of the authenticated user
  • Standard programmatic access for checking a user’s roles

Because these things are standard, an application you write today that uses these techniques will run unchanged on JBoss, WebSphere, WebLogic, or whichever application server or servlet engine you care to mention assuming that it adheres to the J2EE spec.

The programmatic security access methods for web applications are:

  • HttpServletRequest.isUserInRole(roleName)
  • HttpServletRequest.getRemoteUser()

and the programmatic security access methods for EJBs are:

  • EJBContext.getCallerPrincipal()
  • EJBContext.isCallerInRole(roleName)

Of course, these calls only work from within servlets (which includes JSPs) or EJBs, respectively. POJOs need not apply. However, WebLogic provides a proprietary way to get the user anywhere within the thread of a request. You can do this by calling weblogic.security.Security.getCurrentSubject(). You may also find weblogic.security.SubjectUtils.isUserInGroup(subject, group) useful. Just keep in mind that these two tricks are proprietary and won’t work in other servers.

You can find more information on declarative and programmatic security at http://e-docs.bea.com/wls/docs81/security/index.html.

The Framework

The discussion so far has been mostly about how the WebLogic security framework implements the security part of the J2EE spec. Now we can turn our attention to the actual components of the framework that make it all possible.

As I mentioned before, the security framework consists of a group of plugins which handle the various aspects of security. I purposefully used the term “plugin” to drive home the point that the framework is a pluggable solution. However, BEA refers to these components as Security Service Providers so I’ll use the term “provider” for the rest of this post.

WebLogic 8.1 comes with the following provider types:

  • Authentication
  • Identity Assertion
  • Role Mapping
  • Authorization
  • Adjudication
  • Credential Mapping
  • Auditing

Authentication providers are responsible for verifying the user’s identity. For example, an authenticator could authenticate based upon a username and password. You can have more than one authenticator at a time. You can also control both the order in which authenticators are accessed and the behavior of the authentication process with multiple authenticators by using the JAAS control flags (OPTIONAL, SUFFICIENT, REQUIRED, and REQUISITE).

Identity assertion providers are closely related to authenticators but they authenticate a user based upon a perimeter token that was attached to the request. For example, an X.509 certificate or a SAML token are examples of perimeter tokens. The significance here is that the user was authenticated by a different system and the token is a by-product of that authentication. Thus, the user is authenticated indirectly. You can have multiple identity asserters as long as each one handles a different token type.

Role mapping providers associate roles to the authenticated user. These roles can be dynamic based on the username, group, or time. You can have multiple role mappers.

Authorization providers grant or deny access to a resource by comparing the user’s roles with the resource’s security constraints. You can have multiple authorizers. Each authorizer can vote PERMIT, DENY, or ABSTAIN. Making a final authorization decision is left to an adjudicator.

Adjudication providers consider the votes of the authorizers in making a final authorization decision. For example, the adjudicator might be set to require all authorizers to vote PERMIT before access is granted. Or, one PERMIT vote and two DENY votes might be sufficient for granting access. It’s all up to the adjudicator, of which there can only be one. Otherwise, you’d need an adjudicator adjudicator. 😉

Credential mapping providers are for mapping an authenticated user to credentials suitable for accessing a back-end system via a Resource Adapter.

Audit providers allow for logging of security events managed by the other providers. You can have multiple auditors and you can set the severity level of events to log.

All of these providers are configured in a security realm within a domain. The realm also includes users and groups. These are the users and groups accessed by the providers defined in that realm. You can have multiple realms defined in the domain but only one realm can be active at a time. Changing the active realm requires a server restart.

The default realm configured in a WebLogic domain contains a group of providers that act against the embedded LDAP running within WebLogic. While it’s not suitable for production use, this LDAP server contains the WebLogic administrator user, standard roles, and standard groups out of the box.

Along with the default providers, BEA includes many other authentication providers such as Active Directory, SPNEGO, and a host of miscellaneous LDAP authenticators. WebLogic 9 introduces several more providers such as the DBMS providers. In fact, WebLogic 9 even introduces a new provider type: the Certificate Lookup and Validation provider. I haven’t tried it yet but this new provider type looks like a welcome addition.

I’ve painted a rosy picture of the security framework so far, and for the most part it does a great job. However, it does have some weaknesses:

  • Auditing has been a little weak–not in the output of the auditor but rather the control of it. It looks like WebLogic 9 has fixed some of this.
  • Since the security realm configuration is specific to a domain, all applications running in that domain have to use the same configuration of authenticators, authorizers, etc. Essentially, all providers, users, and groups must be suitable across all deployed applications.
  • Being able to configure multiple realms even though only one can be active is something of a tease. I haven’t thought through the implications of this, but wouldn’t it be great if you could specify that an application uses a particular realm? (Update: Now you can. Thanks, Matthias!)

Conclusion

The WebLogic security framework is a flexible, plugin-based mechanism for handling application security requirements. It implements the security aspects of the J2EE spec which allows for container-managed declarative and programmatic security. Finally, if the included providers aren’t sufficient for your purposes, you can create your own or buy third-party providers.

 

Bookmark this page on del.icio.us