Extending the functionality of the WebLogic Server Admin Console provides you with the ability to incorporate the management of your custom application into one central location.

We'll look at what is involved in modifying a Custom Security Provider available on dev2dev by adding MBean attributes to manage the TxDataSource, DatabaseUser, DatabaseUserPassword, DatabaseDriver, and DatabaseURL that are currently hard coded into the custom security provider MBean.

There are two ways to extend the console: one is to have the WebLogic Server console attempt to render a details screen based on custom MBean attributes added to the DbSampleAuthenticator.xml file used to create the MBean. The second is to create a web app containing the class file and JSPs that the console will display when the custom security provider MBean is invoked. I'll discuss both in detail.

Adding Simple Data Types
First, let's look at just adding custom attributes that represent simple data types to the DbSampleAuthenticator xml file and see how to gain access to these values when we want to access the database, both during initialization of WebLogic Server when a datasource is not yet available and afterwards when users are being authenticated when accessing secured resources.

I'll start by adding onto an example found at http://dev2dev/codelibrary/code/sec_rdbms.jsp. The first thing is to add the attributes to the MBean so we can access them through either the command line with weblogic.Admin, or JMX code in a JavaBean or a JSP.

In the DbSampleAuthenticator.xml file, add the following writeable String attributes:

• DatabaseUser
• DatabaseUserPassword
• DatabaseURL
• DatabaseJDBCDriver
• DataSourceName

Name = "DatabaseUser"
Type = "java.lang.String"
Writeable = "true"
Default = ""scott""/>

Once you have added the attributes, you can run ant against the build.xml found in the root directory. Many things happen in this build.xml and it may be worth your while to examine this file more closely as MBeans are created, jar'd, and copied to the $WL_HOME/server/lib/mbeantypes directory. If WebLogic Server is already running, it must be restarted for the custom MBeans to be recognized. Once WebLogic Server is running, you should see a screen similar to that in Figure 1, a new Custom Security Authenticator in the console named DbSampleAuthenticator. (Note: this is WebLogic Server 8.1.) When you select DbSampleAuthenticator, you should see a screen similar to that in Figure 2.

After the DbSampleAuthenticator has been created and you select the Details tab, you should see Figure 3.

If you look at the Java code generated for DbSampleAuthenticatorMBean, you'll see the getters and setters for the various attributes you added.

(How exactly do we access these new MBean Attributes? To better understand how the MBeanMaker works, refer to Developing Security Providers for Weblogic Server [http://edocs/wls/docs81/dvspisec/ design.html#1171038]).

How Do We Pass This MBean Around?
There is, of course, more than one way to access these new attributes. The first is via a JMX call, covered later; and the second is through the Security Provider's LoginModule. The first file to examine and change is DbSampleAuthenticationProviderImpl.java, which is called in the WebLogic Server initialization.

public void initialize(ProviderMBean providermbean,
SecurityServices securityservices)

We'll modify the AppConfigurationEntry getConfiguration, called here by public AppConfigurationEntry getLoginModuleConfiguration(). A configuration options map is passed to the LoginModule, a perfect place to add our new MBean so the attributes can be accessed later on. This is all we need to do to pass the MBean to the LoginModule's initialize method. Now I'll look at how to access the attributes.

Accessing the MBean's Attributes
The implementation of the LoginModule will be changed to retrieve the ProviderMBean passed in the Map argument. (see http://edocs/wls/docs81/dvspisec/atn.html#1153042 Implement the JAAS LoginModule Interface). From there, I'll pass the MBean attributes to the method responsible for authenticating the user (see Listings 1 and 2).

That's it to get the MBean attributes! To see how these are used, look at DbSampleAuthenticatorDatabase.java, where we use the driver, userid, password, and URL to get a database connection when WebLogic Server initializes when JNDI is not set up and the JDBC datasource cannot be accessed.

Extending the Console so the Custom Page is Displayed
Now the fun begins; what do we need to accomplish this feat? Not too much, actually. You'll need a Web app with some default values in the web.xml file and a class that is called to return the JSP page the console will use to render in place of the default details page (see Listing 4). In this example, the JSP must be able to look up the Security MBean via JMX and set the attributes so that the LoginModule can still access them later on. You may ask, do I need a custom Web app for each custom security provider? No, this single Web app with the Java class can handle every security provider and is called each time a user is authenticated; it's up to this class to determine which Security MBean is called and either return null, or there is no JSP page to render; or return the JSP page for the console to display. You could have one Authentication provider with a custom JSP page and another with the default console pages.

That's all we need to do to determine which MBean is called when you click on the custom or any other security provider, this class is called and you can either override the default generated page or return your own.

Now when you click on the DbSampleAuthenticator link, Figure 4 should be displayed.

Creating the JSP
I used the console extension taglib to make the format more consistent with the other default WLS Console pages. I also cheated a little to make this example simple to follow in that I used the same JSP for my form action as I did to render my form. This can definitely be optimized but it will suffice for the purpose of this example.
1.   Get the current attribute values so you can display the values on the form
2.   Show the form and add a submit button 3.   Process the form values and set the MBean attributes

Get the Attributes
In my JSP, I created a small method that I call to populate a HashMap that I use later on to set the default values for my form (see Listing 4; due to space limitations, Listings 4-6 can be found online at www.syscon.com/weblogic/sourcec.cfm). It's fairly easy to get the MBean and to retrieve the current attribute values.

Set the Attributes
This was as straightforward as getting the attributes. You must still get the MBean object, but now you create a new attribute based on the Attribute Name and the new value entered from the form, and then set the attribute. Listing 5 loops through all of the form elements passed in the POST operation and sets those that match the attribute names we want to set.

The last thing to note is that since the JSP instantiates the MBean, you will need to import the MBean class, DbSampleAuthenticatorMBean, which means that the class examples.db.security.providers.authentication. DbSampleAuthenticatorMBean must be in the web-app/WEB-INF/classes directory.

To set the MBeans from the command line, use Listing 6.

Conclusion
In this article I tried to demonstrate how to extend the console for Custom Security Providers by adding new MBean attributes and the code needed to access them. There are two ways to extend the functionality of the console for a custom security provider. You can simply add writeable attributes to the SecurityProvider.xml file and, rebuild the Security Provider jar file and the WebLogic Server Console will attempt to render the screen as a details page. Or, you can write your own Web application with a console extension class and custom JSP files for the console to use.

Acknowledgment
I want to thank Chris Chiodo of the WebLogic Server OA&M team for finding answers to some obtuse questions I had as I developed these examples.

Even though this example makes use of a TxDataSource, we [BEA] do not support the use of WLS resources by security providers. Any operation which goes through a WLS protected resource, such as a connection pool, is prohibited. You can and should directly access the database via JDBC.