Configuring org.clazzes.login.sql 1.0 to 1.1

Owned by Christoph Lechleitner
Last updated: 2013-07-15

Configuration of sql-login-service 1.0 or 1.1

The SQL login service may be configured using the OSGi configuration PID org.clazzes.login.sql using the configuration values shown in the table below.

Beginning with the version 1.1.0 (released 2013-02-13), all query strings default to the database structure used by the upcoming SDS (SQL Directory Service) bundle. When using another database structure that does not allow some of the queries, it is important set those configuration values to empty strings; deleting them will not help because default values would kick in right away.

Results of list queries (group memberships, group members) are sorted naturally in the Java layer, so there is no need to use ORDER BY clauses. ORDER BY clauses often provoke temporary tables and filesort, which is quite expensive for queries used quite often.

Application configuration

 

Key
Description
deactivateUserStatement

Required non-empty for deactivateUser feature.

SQL template for a prepared statement to deactivate a user.

Default, appropriate for SDS' tables:
UPDATE USERS SET PASSWORD='{disabled}' WHERE USERID=?

defaultDomain

Optional. Defaults to an empty string.

If set to an empty string, the domain parameter of request queries does not get checked but is filled in in returned principals.

If set to a non-empty string, requests for other domains are refused.

Support for databases maintaining multiple authentication domains might be added in the future, but I do not believe multi-domain setups even exist outside the LDAP/ADS world.

groupsByUserIdQuery

Required non-empty for getGroups feature.

SQL template for a prepared statement to query the group IDs and group names of the groups of which the user specified by a userId is a member.

Default, appropriate for SDS' tables:
SELECT g.GROUPID, g.GROUPNAME FROM GROUPS AS g, USERS AS u, GROUPMEMBERSHIPS AS m WHERE u.USERID='?' AND m.USER_ID = u.ID AND g.ID = m.GROUP_ID

defaultPasswordAlgorithm

Optional. Defaults to crypt

Values supported so far: crypt, ssha1, plain.

Password fields may contain:

  • the password encrypted using the default password algorithm, or
  • a LDAP style algorithm prefix and the password encrypted with the algorithm specified in the prefix. Example: {PLAIN}badPassword
setUserPasswordStatement

Required non-empty for changePassword feature.

SQL template for a prepared statement to set a new password for the user.

Default, appropriate for SDS' tables:
UPDATE USERS SET PASSWORD=? WHERE USERID=?

userByUserIdQuery

SQL template for a prepared statement to query userId, encrypted password, pretty name and e-mail address of a user specified by a userId.
If the pretty name is not part of the database, reuse the userId field.
If the e-mail address is not part of the database, use a constant like '' or null.

Example:
SELECT USERID, PASSWORD, USERNAME, EMAIL FROM USERS WHERE USERID=?

usersByGroupIdQuery

Required non-empty for getGroupMembers feature.

SQL template for a prepared statement to query the user IDs, user names and e-mail-addresses of the members of the group specified by a groupId.

Example:
SELECT u.USERID, u.USERNAME, u.EMAIL FROM GROUPS AS g, USERS AS u, GROUPMEMBERSHIPS AS m WHERE g.GROUPID=? AND m.GROUP_ID = g.ID AND u.ID = m.USER_ID

Database access configuration

These becomes totally obsolete with version 1.2.

Key
Description

jdbcPassword

Should be self explanatory (wink)

jdbcUrlFor examples look at our JDBC Snippets
jdbcUserShould be self explanatory (wink)
validationQueryFor proposals look at our JDBC Snippets