Tuesday, September 25, 2007

WebLogic Security: Configuring the Database Authentication Providers (SQL, Custom, DBMS)

I have gotten a lot of WebLogic security related questions offline as a result of my last blog post. A couple of people have asked for more details behind the WebLogic SQL Authenticator (a database authentication provider) that I mentioned. This blog entry will give deep background into your options when it comes to authenticating users from a database repository. I will finish by explaining how to configure the SQL Authenticator.

NOTE: this blog entry was originally posted September 25th, 2007 on my previous blogging system (dev2dev.bea.com).

First, a bit of terminology. When looking in the WebLogic Server documentation for a database authentication provider you will find at least a few names:

We all love choice, but what's up with all these names? Are they all the same thing, or does WLS provide multiple provider implementations?

In short, WebLogic does provide multiple database authentication provider implementations. This blog entry will sort out specifically what providers are available to you when authenticating from a database. We will look inside the WebLogic providers to understand what features are supported by which provider. After we have that covered, I will describe how to configure a SQL Authenticator provider in the WLS Console and how to provision the database.

Peter's Best Practice: Use a Database Backed Authentication Provider!

Before we dive into the details, I want to take a moment to congratulate you on reading more about this topic. I have worked at BEA many years, and I have been involved in many customer production escalations. When it comes to Authentication repositories, my experience tells me that you are safest performance-wise with a database backed authentication store. While customers have certainly been successful with other types of authentication repositories, if you want to minimize risk the database approach trumps all others. A database backed repository has few moving parts, and the query necessary to authenticate a user is a simple SELECT. So if you want my opinion, I say go with a database when you have the option.

The Official Flavors of WebLogic Database Authentication Providers

Back to the topic at hand - what are the WebLogic database authentication providers? The official documentation source, edocs.bea.com, will get us started. The docs explain what is provided for you:

Weblogic Security Providers

A set of Database Management System (DBMS) authentication providers that access user, password, group, and group membership information stored in databases for authentication purposes. Optionally, WebLogic Server can be used to manage the user, password, group, and group membership information. The DBMS Authentication providers are the upgrade path from the RDBMS security realm. The following DBMS Authentication providers are available:

  • SQL Authentication provider - A manageable authentication provider that supports the listing and editing of user, password, group, and group membership information.
  • Read-only SQL Authentication provider - An authentication provider that supports authentication of users in a database and the listing of the contents of the database through the WebLogic Server Administration Console. The authentication provider requires a specific set of SQL statements so it might not meet all customer needs.
  • Custom DBMS Authentication provider - A run-time authentication provider that only supports authentication. This provider require customer-written code that handles querying the database to obtain authentication information.This authentication provider is a flexible alternative that allows customer to adapt a DBMS Authentication provider to meet their special database needs.

The documentation is reflected by the WebLogic Console, which provides the following dropdown of authentication providers to choose from. Notice that the three database authentication provider types appear.


While the above descriptions provide some information about the difference between these providers, we can do better. Because you are a developer, you probably want the inside story. Today is your lucky day!

Inside the WebLogic Database Authentication Providers

To get the inside story let's head straight for the source - the authentication provider configuration files. You will find them here:

  • BEA_HOME/WL_HOME/server/lib/mbeantypes/cssWlSecurityProviders.jar

If you open up this JAR, you will find 4 files of interest: DBMSAuthenticator.xml, CustomDBMSAuthenticator.xml, ReadOnlySQLAuthenticator.xml, and SQLAuthenticator.xml. Three of those map directly to the official authentication provider implementations, so those are obviously their configuration files. The fourth, DBMSAuthenticator - what is that? If you look into the XML files, you find that DBMSAuthenticator is the base class for the rest of the providers. By looking at the Extends attribute on the MBeanType element, you can derive the class hieararchy of the providers, shown below.


Now that you understand how the providers are related, how do you know which one you want? WLS/CSS authentication providers have two components - the JAAS code that actually performs the authentication at runtime, and then a set of management "mbeans" that the provider chooses to implement. Every management feature that a provider can support is surfaced as an mbean interface. The key to understanding what a provider can do for you is to look at the mbean interfaces that it implements. Each interface is optional, meaning a provider may choose what features it can support.

Here is the list of mbeans for authentication providers which provide the manageability around users and groups:

SSPI MBean Quick Reference

Mapping out our providers into a table and the mbeans they implement shows the vast difference in manageability. You will want to select a provider based on your requirements for managing users and groups from WLS.


Using the CustomDBMSAuthenticator

This provider is obviously not for use in situations when manageability from WLS is important. It offers no management support. What it does offer is a lowest common denominator approach to integrating a database user repository. Employ this provider when you need to surface just authentication capabilities to WLS, and nothing else. You simply need to implement a plugin that answers the most basic of questions.

Configuring the SQL Authenticator

You are more likely to be using the Read-only SQL Authentication provider or the most powerful SQL Authentication provider. These providers give you manageability from the WLS Console (and WLP Console if using WLP). They are easy to instantiate - the UI surfaces the options you need to configure. I won't go into all the options, but it is important to see that you can change the SQL for each operation if you have a custom schema. The SQL for these providers is designed to be modified to allow you to retrofit a custom database schema. But you can also use the default schema if you are provisioning a brand new user repository (see below for the schema).


After configuring the provider, any deltas versus the defaults will be persisted into config.xml. You can see below, I updated the Datasource of course (this is required) but I also made an arbitrary change to the Create Group SQL. See how it wrote the update into config.xml.

<sec:authentication-provider xsi:type="wls:sql-authenticatorType">
INSERT INTO GROUPS VALUES ( 'arbitrary change' , ? )

The Default Schema DDL for the SQL Authenticator

You can define whatever schema you want to store users and groups when using the SQL Authenticators. But if you are starting fresh, why not just use the default schema and the default settings on the provider. I would highly recommend this approach.

It doesn't look like we officially document the default database schema so let me show you what it is. I list the Oracle DDL below, but you can find the official DDL for your database vendor in the following location in the WLS 10 install (and a similar location for other versions):

  • BEA_HOME/wlserver_10.0/common/p13n/db/DB_VENDOR/p13n9_create_tables.sql


A Few Details for WebLogic Portal Customers

This thread got started because I was discussing in my last blog how WLP 9.2+ by default uses the WebLogic SQL Authenticator. You can, of course, add more authentication providers and remove the SQL Authenticator if you like. When installing WLP, the installer (or you can use the createdb script) will lay down the default SQL Authenticator schema into the WLP schema. Therefore, by default, WLP uses just a single schema for both authentication and Portal operations. This is the most convenient option, but you can change this by switching out the configured datasource.

More Information

For further reading, I suggest these links:

Add to Technorati Favorites

Comments from the original blog:

  • Great article! I was able to successfully help my client configure one for their needs. Thanks again.

    Posted by: sghattu on November 11, 2007 at 6:57 PM

  • I just got a question offline that I will record here - the developer was having trouble creating an Ant build script for building a custom Atn provider.

    My answer:

    When building providers, I have always used the Sample SSPI download from dev2dev CodeShare. It contains a working build script so all of this is taken care of for you.

    SSPI Code Sample

    Posted by: plaird on October 19, 2007 at 10:21 AM

  • Hi Peter, Interesting post but I would like to get more details on your SQLAuthenticator console configuration screenshot. Could you provide me more details on the DataSource name you use. I'm running into troubles with that part! I've tried to provide a configured JDBC data source name but this does not work as the DS is not yet initialized when the security is initialized (not able to start the console anymore). I've tried to provide a Data Source Factory name also without any success!! (Can start the console, but error in the log saying: Connection Pool not usable) Any idea? I'm using Oracle 10g thin jdbc driver and WebLogic server 9.2 Thanks in advance Daniel

    Posted by: ni2corp on September 25, 2007 at 11:43 PM


Phong said...

I am using the SQL Authenticator in conjunction with the standard Web form based validation
using j_security_check.

I have it working if the password stored in the database is plaintext.

But I am trying to get it to work in the case where the password stored in the database is SHA encoded hex.

I got it working for Tomcat but having difficulties with weblogic. I am usingweblogic 9.2.

Any suggestions how to configure SQL Authenticator to compare SHA encoded passwords?

AjAiN said...

Hi Laird,

I want to know is that sql authenticator is the right approach to create/validate users ? As in case of huge applications there would be thousands of users and it may burden the application sever as users will get created on application server as well.

Or i should go for custom authentication which is done directly by database.

Thanks in Advance!!!

Peter Laird said...


Yes SQL Authenticator can be used to create users for a web site (having users self-register). However, be careful about this, as it can be used by bots to create millions of accounts in your system. Use a CAPTCHA solution to help reduce this problem.


afreen said...

Hi Laird,

I want to know is that possible to
use the oracle database schema user and password for authentication and therefore security for like webservices, privileges, etc...

Core said...

Hi Peter. I have a problem. We need to integrate CAS with Weblogic. I dont know if you can help me with some idea:

We use some Oracle products (Webcenter, SSXA, IRM, UBR, UCM, SOA BPM 11g, WC_COlaboration, etc).

We need to connect these applications with other external applications using CAS (SSO).

We think the solution is change the Authentication Provider in Oracle Weblogic Security Realms config.

But when we was reading the options in authentication provider menu, does not appear any option for CAS:


WebLogic Server offers the following types of Authentication providers:

The WebLogic Authentication provider accesses user and group information in WebLogic Server’s embedded LDAP server.
LDAP Authentication providers access external LDAP stores. You can use an LDAP Authentication provider to access any LDAP server. WebLogic Server provides LDAP Authentication providers already configured for Open LDAP, Sun iPlanet, Microsoft Active Directory and Novell NDS LDAP servers.
RDBMS Authentication providers access external relational databases. WebLogic Server provides three RDBMS Authentication providers: SQL Authenticator, Read-only SQL Authenticator, and Custom RDBMS Authenticator.
The WebLogic Identity Assertion provider validates X.509 and IIOP-CSIv2 tokens and optionally can use a user name mapper to map that token to a user in a WebLogic Server security realm.
The SAML Authentication provider, which authenticates users based on Security Assertion Markup Language 1.1 (SAML) assertions.
The Negotiate Identity Assertion provider, which uses Simple and Protected Negotiate (SPNEGO) tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users.
The SAML Identity Assertion provider, which acts as a consumer of SAML security assertions. This enables WebLogic Server to act as a SAML destination site and supports using SAML for single sign-on.

In addition, you can use:

Custom (non-WebLogic) Authentication providers, which offer different types of authentication technologies.
Custom (non-WebLogic) Identity Assertion providers, which support different types of tokens.


We think that we need to implement a new Authentication Provider. Is that correct?
Or any other idea?


Anonymous said...


Unfortunately CAS does not support SAML, which is a big bummer. So yes, you should be looking to implement a CAS authentication provider that queries CAS directly using their client APIs.


moltto said...

Hello Peter,

I trying to download the SSPI samples, but https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=S224 isnt available.

You know where i could get it?


Shahzad Ahmed Khan said...

Hi Laird,
I have configure SQLAuthentication successfully. Users and groups are posting in database. I have configured datasource for web logic and provide that data source in provider configuration. But i have trouble while starting weblogic console. As data source is not yet initialized while web logic tries to initialize security. CAn you guide me how i can resolve this issue.
Here is my stack trace i am using weblogic12c.


at weblogic.security.providers.authentication.DBMSAuthenticatorDelegateImpl.getInstance(DBMSAuthenticatorDelegateImpl.java:459)

at weblogic.security.providers.authentication.DBMSSQLAuthenticationProviderImpl.initialize(DBMSSQLAuthenticationProviderImpl.java:55)

Truncated. see log file for complete stacktrace

Unknown said...

Hi sir,
I have problem for weblogic user authentication by external database when password is stored in hash mode.
I described it here https://community.oracle.com/message/12991518
Can you help me?

L@m said...

Hi Laird,

I wanted to know if we can configure Weblogic security such as below:

USERS will be either returned via LDAP or SAML2 authentication where as GROUPS should come from Database.

Kindly throw some lights.