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, 've got basic username and password login which can be done with either the org.apache.openejb.client.LocalInitialContextFactory or org.apache.openejb.client.RemoteInitialContextFactory. You simply construct your InitialContext with the standard javax.naming.Context properties for user/pass info, which is:
| Code Block |
|---|
Properties props = new Properties();
props.setProperty(Context.SECURITY_PRINCIPAL, "someuser");
props.setProperty(Context.SECURITY_CREDENTIALS, "thepass");
props.setProperty("openejb.authentication.realmName", "PropertiesLogin"); // optional
InitialContext ctx = new InitialContext(props);
ctx.lookup(...);
|
That will get you logged in and all your calls from that context should execute as you.
There are three new security related files:
${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.
PropertiesLoginModule
Supported options:
Option | Description | Required |
|---|---|---|
UsersFile | name of the properties file that contains the users and their passwords | yes |
GroupsFile | name of the properties file that contains the groups and their member lists | yes |
UsersFile and GroupsFile are read in on every login,
login.config: is a JAAS config file which configures our PropertiesLoginModule as the login module to be used for authenticating clients. We don't have any other kind of login modules yet, but that would be nice to support.
users.properties and groups.properties are for configuring users and groups using a properties file approach which is somewhat unix-like in nature. These are used by the PropertiesLoginModule and 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.
SQLLoginModule
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:
Option | Description | Required |
|---|---|---|
dataSourceName | the name of a data source | yes (alternative 1) |
jdbcURL | a standard JDBC URL | yes (alternative 2) |
jdbcDriver | the fully qualified class name of the database driver | no |
jdbcUser | the user name for accessing the database | no |
jdbcPassword | the password for accessing the database | no |
userSelect | the SQL query that returns a list of users and their passwords | yes |
groupSelect | the SQL query that returns a list of users and groups (roles) | yes |
digest | the name of the digest algorithm (e.g. "MD5" or "SHA") for digest authentication | no |
encoding | the digest encoding, can be "hex" or "base64" | no |
PLUG POINTS
There are four-five different plug points where you could customize the functionality. From largest to smallest:
...
- JAAS LoginModule. You can setup a different JAAS LoginModule to do all your authentication by simply editing the conf/login.config file which is a plain JAAS config file. At the moment we only support username/password based login modules. At some point it would be nice to support any kind of input for a JAAS LoginModule, but username/password at least covers the majority. It actually is possible to support any LoginModule, but you would have to supply your clients with your own way to authenticate to it and write a strategy for telling the OpenEJB client what data to send to the server with each invocation request. See the JAAS LoginModule Developer's Guide for more information.
- Client IdentityResolver. This is the just mentioned interface you would have to implement to supply the OpenEJB client with alternate data to send to the server with each invocation request. If you're plugging in a new version of this it is likely that you may also want to plugin in your own SecurityService implementation. Reason being, the object returned from IdentiyResolve.getIdentity() is sent across the wire and straight in to the
SecurityService.associate(Object) method.