Sunday, January 28, 2007

LDAP Authentication with Apache Derby (Java DB)

It has come to my attention that there is not a really good tutorial on how to use Apache Derby and LDAP without combining a lot of different sources. Hopefully this will simplify the work for everyone wanting to use LDAP authentication with Apache Derby.

Assumptions:


Procedures:

Global:

If you want to have the configuration set on a global level add the following to a file called derby.properties in the installation directory. You will need to modify it to match your environment.

derby.connection.requireAuthentication=true
derby.authentication.provider=LDAP
derby.authentication.server=ldap://localhost:389
derby.authentication.ldap.searchBase=ou=people,dc=bluelotusholdings,dc=com
derby.database.defaultAccessMode=fullAccess

Database:

You can set the database properties on a database basis. This is accomplished by setting the parameters (database properties) in the database using SQL. The script is located below. This must be modified to accommodate your environment. Place the jndi and ldap files in the directory containing the database (see below). The database in my example is called ldaptest.




/* Apache Derby 10.x */


/*
* This file is used to set the database-wide LDAP configuration. Rebooting the service is
* required for the changes to take effect.
*/

/* Set the authentication provider to LDAP */


CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.provider',
'LDAP')

/* Set the LDAP server */

CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.server',
'banyan:389')

/* Set the BaseDN to search */

CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.authentication.ldap.searchBase',
'ou=people,dc=bluelotusholdings,dc=com')

/* Create a cached entry for a user */

CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
'derby.user.jyeary',
'uid=jyeary,ou=people,dc=bluelotusholdings,dc=com')
Once you have executed the script above, you will need to restart the database. I used my Aqua Studio application to connect to the database.


All Done!

Notes:

  • If LDAP is not available you can not connect to the database.

The Problem of Offline Web Applications - Technology Choices

I have been trying to develop a new application for doing timesheets. We currently use a system which was developed using MS Access and MS Excel combined with access to an Oracle database and a local hsqldb. Needless to say it is messy solution. It was something that was started by a wonderful field engineer that works for my company. As these kinds of projects take on a life of their own, the problems of updating them and ensuring that everyone is using the latest version come up.

Here are some of the issues:
  • Non-object oriented (OO) design
  • No source control
  • No version control
  • No defect management
  • No mechanism to control enhancements
  • MS Access and Excel are binary applications, so there is no clear way to implement source control
  • No clear interfaces
  • Client interaction directly with Oracle
  • On/Off line modes are user controlled
  • Can not move database back end without updating all clients
So I am examining some ideas to make the timesheet application a better design. There are really two options to consider: a web based application, and a standalone Web Start application.

The web based application I have in mind could take form using either a completely server side version using JSF. The other option is to use an embedded database like Java DB in a browser, and submit the final results to a application server. The latter does not have a clearly defined method of updating the application. The idea is based on the demo of Java DB called Java DB-in-a-Browser Demo

The demo is impressive from a number of ways. It shows how to use Java DB, AJAX, Live Connect technology (been around since the days of Netscape and Java integration), applet technologies, and simple HTML. It is truly an enlightening demonstration.

The alternative is to create a rich Swing based application using Java Web Start. These technologies have really matured and combined with the Sun Java System Application Server make a great tool set for any Java developer. The application client using being dispensed from the application server solves a number of problems including simplification of the client. A majority of the business methods are implemented on the server. This leaves the presentation and validation to the client. This combined with Java DB packs a potent punch. It also solves two problems mentioned above: offine use with a mechanism for interaction when a network connection is detected (automatic), and removal of direct interaction with database.

You may believe that I am inclined to use the Swing application client, but I really am impressed with JSF. JSF does require online access to work which may hamper its implementation.

Some technologies to consider:


Here are some interesting articles in the same genre:

Popular Posts