Using External Security Stores

WebLogic Server can also use external security stores for storing security data. In this section, we will look at a few of the most common external stores used with WebLogic Server. We focus primarily on using these external stores for authentication data because that is by far the most common usage, since most authorization is still done using J2EE deployment descriptor security, third-party application security products, or custom code in the application. As we will see later in the Setting Up WebLogic Application Security section, WebLogic Server is now offering its own application security functionality to provide parametric, policy-based authorization that can be configured outside of the application code or deployment descriptors. We expect that upcoming versions of WebLogic Server will continue to build in more functionality over time.

Managing External LDAP Authentication

LDAP servers have become the de facto standard for managing corporate user information. Current versions of WebLogic Server support using both its embedded LDAP server as well as several of the more popular commercial LDAP servers on the market today. Supporting different LDAP servers generally means that WebLogic Server has built-in knowledge of the default schemas used by these servers and can make them easy to configure. Just because WebLogic Server does not support a particular LDAP server out of the box, it does not mean you cannot use it. Typically, it is possible to make it work; you just need to customize the authentication provider configuration to match the LDAP schema and server information.

The new security framework has a series of built-in LDAP authentication providers. These options include support for iPlanet (and SunOne), ActiveDirectory, OpenLDAP, and Novell LDAP Servers. Each authentication provider is specialized for the default or standard schemas used by that LDAP server. You can easily create and configure them via the console.

In some cases, the default or standard schema that is configurable via the console may not give you enough fine-grained control over the LDAP queries. If you find yourself in this situation, you may need to write your own custom authentication provider or use one of the older LDAPRealm implementations .

Two versions of the LDAPRealm were written for the old security realm APIs. The first version of the LDAPRealm ( LDAPRealmv1 ) uses Sun s LDAP-JNDI plug-in, whereas the second version ( LDAPRealmv2 ) uses the Mozilla LDAP Java library. If your LDAP schema is complex enough to have led you to look at one of the older LDAPRealms to handle it, then it is very likely that LDAPRealmv1 may not be versatile enough for your needs.

LDAPRealmv2 is more versatile than LDAPRealmv1 , but it is also more complex. The LDAPRealmv2 is configured as a custom realm, in the realm adapter s authentication provider, using weblogic.security.ldaprealmv2.LDAPRealm as the realm class. One important limitation of the older LDAPRealms is that the new security framework s LDAP authentication providers will follow referrals and handle dynamic groups, whereas the older LDAPRealms will not.

Note  

While the older LDAPRealmv2 realm gives you much more granular control, it will not follow referrals or handle dynamic groups. If either of these is important, you will need to use one of the new LDAP providers.

The realm adapter LDAPRealmv2 configuration for the typical LDAP server is this:

 user.dn.1=ou=people, o=engin, dc=bigrez, dc=com; user.dn.2=ou=Security, ou=Groups, o=engin, dc=bigrez, dc=com; user.filter=(&(cn=%u)(objectclass=person)) group.dn.1=ou=groups, o=engin, dc=bigrez, dc=com; group.dn.2=ou=Security, ou=People, o=engin, dc=bigrez, dc=com; group.filter.1=(&(cn=%g)(objectclass=groupofnames)); group.filter.2=(&(cn=%g)(objectclass=group)); membership.filter=(&(member=%M)(objectclass=groupofnames)); membership.search=true; 

For the ActiveDirectory LDAP server, the typical configuration is this:

 user.dn=cn=Users, DC=dcName, DC=bigrez, DC=com user.scope=subtree group.dn=cn=Users, DC=dcName, DC=bigrez, DC=com group.filter=(&(cn=%g)(objectclass=group)) membership.filter=(&(member=%M)(objectclass=group)) 

ActiveDirectory has some interesting differences that we need to mention. If the sAMAccountName is different from the DN, you should use this:

 user.filter=(&(sAMAccountName=%u)(objectclass=user)               (objectcategory=person)) membership.search=true 

If the sAMAccountName is the same as the CN portion of the DN, you need to use this:

 user.filter=(&(CN=%u)(objectclass=user)(objectcategory=person)) membership.search=false 

If you disable a user in Active Directory, WebLogic Server will still successfully authenticate that user by default. In order to get WebLogic Server to recognize that the user s account has been disabled, you need to modify the user.filter . To return only the accounts that do not have the UF_ACCOUNTDISABLE bit set, use this:

 user.filter=(&(sAMAccountName=%u)              (&(objectclass=user)(objectcategory=person)                (!(userAccountControl:1.2.840.113556.1.4.803:=2))               )) 

Using the WebLogic Console, you can map the preceding configuration information to the new LDAP providers by simply providing the information in the appropriate fields. As we mentioned before, just because your LDAP server vendor is not listed, it does not mean you cannot use it with WebLogic Server. Consulting your LDAP administrator and finding the best match to your schema is the best way to create a specialized LDAP authentication provider.

You can configure your LDAP provider to one or more user.dn entries, as shown in the ActiveDirectory and typical LDAP server configurations, respectively. Another important option that we have illustrated in the typical LDAP configuration is the use of a single filter for all user.dn entries, but specific filters for each group.dn . Using this, you can point the WebLogic Server at very specific spots in the LDAP directory tree. The more specific the tree is, the smaller the search will be, which means better performance.

In a typical LDAP schema, a group will list the DN of only the users that are its members . WebLogic Server needs to determine the user s ID. Most of the time, this user ID is part of the User object s DN, so WebLogic Server can determine the user ID by simply looking at the DN of the users in the Group object. However, if the user ID is not part of the User object s DN and can be found only in an attribute of the User object itself, a secondary search using the User object s DN to locate the User object and retrieve the appropriate attribute will be required. You can use the membership.search property to configure this secondary search. This property exists in WebLogic Server 8.1 and was added in WebLogic Server 6.1 Service Pack 4 and WebLogic Server 7.0 Service Pack 2.

For most applications, it will be very important to optimize the performance of your LDAP-based authentication and group membership queries. You should try to tune your WebLogic Server LDAP configuration filters to be as specific as possible. Another critical step in enhancing your performance is to have your LDAP server index all of the attributes that you will use as search keys in your LDAPRealm search filters. Failing to index these attributes will typically cause performance problems as the number of objects in your LDAP server grows because the LDAP server is forced to perform linear searches. In earlier versions of WebLogic Server, a CachingRealm was provided to cache the authentication and group membership information. Starting in WebLogic Server 7.0, each LDAP connection caches its own LDAP searches and results. The only drawback to this new approach is that caching is per connection, rather than per WebLogic Server, which can result in higher cache miss ratios.

Best Practice  

Always tune your WebLogic Server LDAP configuration filters to be as specific as possible. Indexing LDAP attributes that are used as search keys is critical for achieving good performance with LDAP servers that contain more than a handful of objects.

Setting Up UNIX-Based Authentication

WebLogic Server comes with a custom realm, based on the old security realm APIs, that supports authentication via Pluggable Authentication Modules (PAM). Because it was written using the old realm APIs, you must run in compatibility mode to use it with newer versions of WebLogic Server. This realm, known as the UnixRealm , uses Java Native Interface (JNI) to make native calls to the local operating system for authentication and group membership information. Therefore, it can be very particular to set up.

The UnixRealm runs only on Solaris and Linux and uses a small native program called wlauth . The wlauth program must run as root, so you must set it up with the chown root wlauth and chmod +xs wlauth commands. You also need to set up the PAM configuration file. For Solaris, add these lines to your /etc/pam.conf file:

 wlauth auth required      /usr/lib/security/pam_unix.so.1  wlauth password required  /usr/lib/security/pam_unix.so.1  wlauth account required   /usr/lib/security/pam_unix.so.1 

For Linux, create a file called /etc/pam.d/wlauth and add:

 #%PAM-1.0 auth required     /lib/security/pam_pwdb.so shadow account required  /lib/security/pam_pwdb.so 

If you do not use a shadow password file, remove the word shadow from the end of the first line.

Setting Up Windows Domain Authentication

WebLogic Server also comes with a custom realm, based on the old security realm APIs, that supports native Windows domain authentication. This realm, known as the NTRealm , is useful with Windows domains that are not set up to use ActiveDirectory. Whenever possible, you should always use ActiveDirectory instead of the NTRealm because it is far less fragile and gives you more granular control.

Best Practice  

Wherever possible, use ActiveDirectory authentication instead of native Windows domain authentication for production environments.

The NTRealm is set up with a single argument, the hostname of the primary domain controller ”not the domain name . You can run the NTRealm on either the primary domain controller or any member of that domain. You can also run the NTRealm on any machine that is a member of a domain and wants to use a second, mutually trusted, domain for authentication. Doing this requires you to set up an explicit mutual trust relationship between the two domains. What you cannot do is use a stand-alone machine that is not part of a domain to authenticate to a Windows domain.

To run the NTRealm s native library, WebLogic Server will need to run as a specific Windows user that has some specific Windows privileges:

• Act as part of the operating system

• Create a token object

• Replace a process-level token

Note that all versions of Windows require a reboot for any privileges to take effect.

To update the privileges on Windows NT, use the User Manager program, which can be found under the Administrative Tools program group, to do the following steps:

1. Select the User Rights menu option from the Policies menu. Select the Show Advanced User Rights checkbox in the lower-left corner.

2. Grant the previously mentioned privileges to the user who will run the WebLogic Server.

3. Reboot the machine.

To update the privileges on Windows2000 and XP, use the Local Security Policy program, which can be found under the Administrative Tools program group, to do the following steps. Note that if you do not have an Administrative Tools program group, you may need to use the Taskbar & Start Menu option under the Windows Start Menu s Settings option to make the Administrative Tools program group visible:

1. In the left-hand folder view, select the Local Policies- > User Rights Assignment folder.

2. For each privilege listed previously, add the user that will run WebLogic Server to the list of users with these privileges.

3. Reboot the machine.

Another important configuration concern applies when trying to run WebLogic Server using the NTRealm as a Windows service. The problem is that the native calls the authentication library makes (Net*Enum) are disabled by the RestrictAnonymous setting on the primary domain controller. Because the LocalSystem user has limited access to network resources, the service will fail to start because the authentication calls made during server startup will fail. To start the WebLogic Server service as a user other than LocalSystem , you will need to use the SRVANY service to run the startWebLogic.cmd script. The SRVANY service comes with the Microsoft Windows Resource Kit, which is downloadable from the Microsoft Web site. The only issue with the SRVANY service is that it knows only how to start the WebLogic Server instance; the only way to shut down the instance properly will be to use the WebLogic Console or the weblogic.Admin SHUTDOWN command.

An excellent troubleshooting tool is built into the NTRealm itself. This tool will perform a complete functional sweep of the NTRealm configuration and will tell you immediately whether your configuration will work. To invoke this tool, use the following syntax, where the username and password are for the user that will be running WebLogic Server:

 java weblogic.security.ntrealm.NTRealm <username> <password> <hostname> 

The hostname is optional, as the native library can determine the domain to which your machine belongs. The first line of output will tell you if the authentication succeeded, as shown here for username bauersc .

auth?bauersc .     This means authentication worked for user bauersc .

auth?null .     This means it did not authenticate properly.

The remaining output of the unit test utility will enumerate all the users and groups available to it.

Custom Authentication Providers

In addition to using built-in external authentication providers, you can also write your own. There are several source code examples that you can use to get started. As we mentioned previously, the BEA developer s Web site contains an example authentication provider (http://dev2dev.bea.com/direct/SampleSecurityProviders.zip). Another source code example that you can use as a starting point for developing a realm for the old security realm APIs is the RDBMSRealm , which shipped with previous versions of the server in the samples/examples/security/rdbmsrealm directory. Of course, we strongly encourage you to write any custom providers to the new security framework to give your application access to all of the new features and improvements in the new WebLogic Security Service.

At this point, we need to warn you about trying to use these examples as your production providers. These two source code examples are meant to help you understand how to build your own custom providers ”they are not designed to be production-ready implementations. At a minimum, you should make certain performance and fault-tolerance enhancements before trying to use them in a production environment.

Warning  

The example security providers are meant as learning tools to help you understand how to interface with the WebLogic Server security service. These examples lack performance optimizations and fault-tolerance features required in any production-ready security provider.