Security - How To.

We currently have two authentication mechanisms to choose from: * PropertiesLoginModule (a basic text file based login that looks up users and groups from the specified properties files) * SQLLoginModule (database based login that looks up users and groups in a database through SQL queries)

To make your program authenticate itself to the server, simply construct your InitialContext with the standard javax.naming.Context properties for user/pass info, which is:

Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
props.setProperty(Context.PROVIDER_URL, "ejbd://localhost:4201");
props.setProperty(Context.SECURITY_PRINCIPAL, "someuser");
props.setProperty(Context.SECURITY_CREDENTIALS, "thepass");
props.setProperty("openejb.authentication.realmName", "PropertiesLogin");
// optional
InitialContext ctx = new InitialContext(props);

That will get you logged in and all your calls from that context should execute as you.

${openejb.base}/conf/login.config is a standard JAAS config file. Here, you can configure any number of security realms to authenticate against. To specify which of the realms you want to authenticate against, you can set the openejb.authentication.realmName property to any of the configured realm names in login.config. If you don't speficy a realm name, the default (currently PropertiesLogin) is used. For examples and more information on JAAS configuration, see the JAAS Reference Guide .


Supported options:

UsersFilename of the properties file that contains the users and their passwords*yes*
GroupsFilename of the properties file that contains the groups and their member lists*yes*

UsersFile and GroupsFile are read in on every login, so +you can update them+ on a running system and those users will "show up" immediately +without the need for a restart+ of any kind.


You can either use a data source or configure the JDBC URL through which the user/group lookups will be made.

If you use a DataSource, you must specify its JNDI name with the dataSourceName option.

If you use JDBC directly, you have to specify at least the JDBC URL of the database. The driver should be autodetected (provided the appropriate jar is on your classpath), but if that fails for some reason, you can force a specific driver using the jdbcDriver option. For more information on JDBC URLs, see the JDBC Guide

The userSelect query must return a two-column list of user names (column 1) and passwords (column 2). This query should normally return a single row, which can be achieved by the use of a query parameter placeholder "?". Any such placeholders in both queries will be filled in with the username that the client is trying to log in with. The groupSelect query must return a two-column list of user names and their groups (or "roles" in the EJB world).

Supported options:

dataSourceNamethe name of a data source*yes* (alternative 1)
jdbcURLa standard JDBC URL*yes* (alternative 2)
jdbcDriverthe fully qualified class name of the database driverno
jdbcUserthe user name for accessing the databaseno
jdbcPasswordthe password for accessing the databaseno
userSelectthe SQL query that returns a list of users and their passwords*yes*
groupSelectthe SQL query that returns a list of users and groups (roles)*yes*
digestthe name of the digest algorithm (e.g. "MD5" or "SHA") for digest authenticationno
encodingthe digest encoding, can be "hex" or "base64"no


There are four-five different plug points where you could customize the functionality. From largest to smallest: - The SecurityService interface: As before all security work (authentication and authorization) is behind this interface, only the methods on it have been updated. If you want to do something really "out there" or need total control, this is where you go. Plugging in your own SecurityService should really be a last resort. We still have our "do nothing" SecurityService implementation just as before, but it is no longer the default. +You can add a new SecurityService impl by creating a service-jar.xml and packing it in your jar+. You can configure OpenEJB to use a different SecurityService via the openejb.xml.