Wiki source code of Configuring org.clazzes.login.sql 1.2+
Last modified by christoph_lechleitner@iteg_at on 2013-08-03 10.48:38
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | = {{id name="Configuringorg.clazzes.login.sql1.2+-Configurationofsql-login-service1.2andhigher"/}}Configuration of sql-login-service 1.2 and higher = | ||
| 2 | |||
| 3 | The SQL login service may be configured using the OSGi configuration PID {{code language="none"}}org.clazzes.login.sql{{/code}} using the configuration values shown in the table below. | ||
| 4 | |||
| 5 | Beginning with the version 1.1.0 (released 2013-02-13), all query strings default to the database structure used by the upcoming [[doc:LOGIN.SDS (SQL Directory Service).WebHome]] 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. | ||
| 6 | |||
| 7 | 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. | ||
| 8 | |||
| 9 | == {{id name="Configuringorg.clazzes.login.sql1.2+-Globalconfigurationdirectives"/}}Global configuration directives == | ||
| 10 | |||
| 11 | |=((( | ||
| 12 | (% class="tablesorter-header-inner" %) | ||
| 13 | ((( | ||
| 14 | Key | ||
| 15 | ))) | ||
| 16 | )))|=((( | ||
| 17 | (% class="tablesorter-header-inner" %) | ||
| 18 | ((( | ||
| 19 | Description | ||
| 20 | ))) | ||
| 21 | ))) | ||
| 22 | |((( | ||
| 23 | {{code language="none"}} | ||
| 24 | defaultDomain | ||
| 25 | {{/code}} | ||
| 26 | )))|((( | ||
| 27 | Optional. Defaults to an empty string. | ||
| 28 | ))) | ||
| 29 | |||
| 30 | == {{id name="Configuringorg.clazzes.login.sql1.2+-Per-Domainconfigurationdirectives"/}}Per-Domain configuration directives == | ||
| 31 | |||
| 32 | Starting with version 1.2.0 sql-login-service supports multiple authentication domains, and therefore began to introduce authentication domain in the names of configuration keys. | ||
| 33 | |||
| 34 | The current approach presumes that one database usually provides authentication data for one authentication domain. Support for databases maintaining multiple authentication domains (in one database) might be added in the future (see [[LOGIN-11>>url:https://jira.clazzes.org/browse/LOGIN-11||shape="rect"]]), but I do not believe multi-domain-databases even exist outside the LDAP/ADS world. | ||
| 35 | |||
| 36 | Version 1.3.2 reflects the changed table names of [[SDS>>doc:LOGIN.SDS (SQL Directory Service).WebHome]]' first release version 1.0.0, which started to use {{code language="none"}}SDS_{{/code}} prefixes for all table names, to make it easier to live in App's databases. | ||
| 37 | |||
| 38 | (% class="wiki-content" %) | ||
| 39 | ((( | ||
| 40 | |||
| 41 | |||
| 42 | |=((( | ||
| 43 | (% class="tablesorter-header-inner" %) | ||
| 44 | ((( | ||
| 45 | Key | ||
| 46 | ))) | ||
| 47 | )))|=((( | ||
| 48 | (% class="tablesorter-header-inner" %) | ||
| 49 | ((( | ||
| 50 | Description | ||
| 51 | ))) | ||
| 52 | ))) | ||
| 53 | |((( | ||
| 54 | {{code language="none"}} | ||
| 55 | domain.<domain>.dataSourceName | ||
| 56 | {{/code}} | ||
| 57 | )))|((( | ||
| 58 | Required. Introduced with 1.2.0. | ||
| 59 | |||
| 60 | Name of the [[JDBC-Provider>>doc:UTIL.Multi-DataSource pooling with JDBC-Provider.WebHome]]'s DataSource that provides access to the database containing the authentication data for this authentication domain. | ||
| 61 | |||
| 62 | Example: {{code language="none"}}domain.MYAUTHDOMAIN.dataSourceName = MYDATASOURCE{{/code}} | ||
| 63 | ))) | ||
| 64 | |((( | ||
| 65 | {{code language="none"}} | ||
| 66 | domain.<domain>.deactivateUserStatement | ||
| 67 | {{/code}} | ||
| 68 | )))|((( | ||
| 69 | Required non-empty for //deactivateUser// feature. | ||
| 70 | |||
| 71 | SQL template for a prepared statement to deactivate a user. | ||
| 72 | |||
| 73 | Default, appropriate for SDS' tables: | ||
| 74 | {{code language="none"}}UPDATE SDS_USERS SET PASSWORD='{disabled}' WHERE USERID=?{{/code}} | ||
| 75 | ))) | ||
| 76 | |((( | ||
| 77 | {{code language="none"}} | ||
| 78 | domain.<domain>.groupsByUserIdQuery | ||
| 79 | {{/code}} | ||
| 80 | )))|((( | ||
| 81 | Required non-empty for //getGroups// feature. | ||
| 82 | |||
| 83 | 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. | ||
| 84 | |||
| 85 | Default, appropriate for SDS' tables: | ||
| 86 | {{code language="none"}}SELECT g.GROUPID, g.GROUPNAME FROM SDS_GROUPS AS g, SDS_USERS AS u, SDS_GROUPMEMBERSHIPS AS m WHERE u.USERID='?' AND m.USER_ID = u.ID AND g.ID = m.GROUP_ID{{/code}} | ||
| 87 | ))) | ||
| 88 | |((( | ||
| 89 | {{code language="none"}} | ||
| 90 | domain.<domain>.defaultPasswordAlgorithm | ||
| 91 | {{/code}} | ||
| 92 | )))|((( | ||
| 93 | Optional. Defaults to {{code language="none"}}crypt{{/code}} | ||
| 94 | |||
| 95 | Values supported so far: {{code language="none"}}crypt{{/code}}, {{code language="none"}}ssha1{{/code}}, {{code language="none"}}plain{{/code}}. | ||
| 96 | |||
| 97 | Password fields may contain: | ||
| 98 | |||
| 99 | * the password encrypted using the default password algorithm, or | ||
| 100 | * a LDAP style algorithm prefix and the password encrypted with the algorithm specified in the prefix. Example: {{code language="none"}}{PLAIN}badPassword{{/code}} | ||
| 101 | ))) | ||
| 102 | |((( | ||
| 103 | {{code language="none"}} | ||
| 104 | domain.<domain>.setUserPasswordStatement | ||
| 105 | {{/code}} | ||
| 106 | )))|((( | ||
| 107 | Required non-empty for //changePassword// feature. | ||
| 108 | |||
| 109 | SQL template for a prepared statement to set a new password for the user. | ||
| 110 | |||
| 111 | Default, appropriate for SDS' tables: | ||
| 112 | {{code language="none"}}UPDATE SDS_USERS SET PASSWORD=? WHERE USERID=?{{/code}} | ||
| 113 | ))) | ||
| 114 | |((( | ||
| 115 | {{code language="none"}} | ||
| 116 | domain.<domain>.userByUserIdQuery | ||
| 117 | {{/code}} | ||
| 118 | )))|((( | ||
| 119 | SQL template for a prepared statement to query userId, encrypted password, pretty name and e-mail address of a user specified by a userId. | ||
| 120 | If the pretty name is not part of the database, reuse the userId field. | ||
| 121 | If the e-mail address is not part of the database, use a constant like '' or null. | ||
| 122 | |||
| 123 | Example: | ||
| 124 | {{code language="none"}}SELECT USERID, PASSWORD, USERNAME, EMAIL FROM SDS_USERS WHERE USERID=?{{/code}} | ||
| 125 | ))) | ||
| 126 | |((( | ||
| 127 | {{code language="none"}} | ||
| 128 | domain.<domain>.usersByGroupIdQuery | ||
| 129 | {{/code}} | ||
| 130 | )))|((( | ||
| 131 | Required non-empty for //getGroupMembers// feature. | ||
| 132 | |||
| 133 | 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. | ||
| 134 | |||
| 135 | Example: | ||
| 136 | {{code language="none"}}SELECT u.USERID, u.USERNAME, u.EMAIL FROM SDS_GROUPS AS g, SDS_USERS AS u, SDS_GROUPMEMBERSHIPS AS m WHERE g.GROUPID=? AND m.GROUP_ID = g.ID AND u.ID = m.USER_ID{{/code}} | ||
| 137 | ))) | ||
| 138 | ))) |