FarragoAuthentication
From Eigenpedia
Contents |
Introduction
Farrago is capable of authenticating JDBC connection requests in two different ways:
- (before v0.9.2, as well as after): via a pluggable JAAS login module
- (starting from v0.9.2): via password hashes stored in the catalog (one-way encryption)
Typically, a deployment will use one or the other of these (or neither), although nothing prevents both from being used at once (and JAAS itself allows for stacked configurations as well).
(Note that php/.net/odbc ultimately use a JDBC connection as well, so whatever applies to JDBC applies to them as well.)
Passwords in the Catalog
Catalog-based passwords are set by executing the following form of the CREATE USER statement:
CREATE [ OR REPLACE ] USER user-name IDENTIFIED BY 'password';
To disable catalog-based authentication for a user, omit the IDENTIFIED BY clause:
CREATE [ OR REPLACE ] USER user-name;
Note that CREATE OR REPLACE can be used to change a password (or to unset one by omitting the IDENTIFIED BY clause). An empty-string password is treated the same as if no password was set.
An older form of the CREATE USER statement is now deprecated but remains in effect for backward-compatibility; it does not set a password (i.e. the AUTHORIZATION clause is simply ignored):
CREATE USER user-name AUTHORIZATION 'unused'
The user record in the catalog stores a SHA-256 digest of the password (using the java.security.MessageDigest implementation built into Java). The digest is computed by converting the plaintext Unicode string to UTF-16LE byte representation, hashing these bytes, and then converting the result back to a string via base64-encoding; this cyphertext string is what gets stored in the catalog.
-- Ngoodman 23:15, 19 October 2009 (EDT) Is it possible to make this a UDX instead? Add a system parameter with a default of UDX name "hash_sha256" but it can be changed to any simple hasing mechanism. This also simplifies the hasing out of the code and into UDXes.
--Jvs 18:22, 20 October 2009 (EDT): After discussion with Nick, we agreed that it would be more appropriate to skip this and leave extensibility to the JAAS route
-- Ngoodman 23:15, 19 October 2009 (EDT) Begin Comment Consider a little scope creep. Store the password in the catalog with the encryption method, a space, and then the string. The SHA-256 could look like "encrypted asidjf9023jrjasdf0jasf09j2f0j3902jf" when stored in the catalog. When authenticating the pseudo code becomes:
if ( string_from_user.startsWith("encrypted ")
compare directly
else
hash_sha256(string_from_user) and compare
This would allow for a future extension to the front end JDBC driver to encrypt on its side and send over and the server would simply "skip" the hashing part of its job (pass through). -- Ngoodman 23:15, 19 October 2009 (EDT) End Comment
--Jvs 21:36, 21 October 2009 (EDT): Instead of tacking the algorithn name on as a string prefix, we decided to store it as a separate attribute in the catalog. For now, we won't actually support anything but SHA-256, but this will make it easier to support others (and unencrypted) in the future.
When a password is supplied during session authentication, it is encrypted via the same process and the result is compared against the one in the catalog. There is currently no provision for salt, nor is there any client-side encryption to prevent password plaintext from being transmitted over the wire for remote connections.
Special Account
The sa account (created as part of catalog initialization) initially has no password set. If JAAS authentication is not being used, securing a server involves setting a password for this account via CREATE OR REPLACE USER.
Catalog Migration
User accounts migrated from pre-0.9.2 catalog versions will have no passwords set.
JAAS configuration
A login module configuration can be set up by creating a file ${FARRAGO_HOME}/plugin/jaas.conf. See JAAS docs for format and examples of this file. If this file exists when the net.sf.farrago.db.FarragoDatabase constructor is called, then system property java.security.auth.login.config is set to reference it. If this file does not exist, then JAAS-based authentication is disabled for the lifetime of the FarragoDatabase object. Method FarragoDatabase.isJaasAuthenticationEnabled() can be used to check.
If we want to define an authentication config in some other way than through a config file, it can be done by subclassing javax.security.auth.login.Configuration.
Mock login module for testing
The default for a developer build is to use a mock module which allows all logins without checking passwords, except for certain predefined prohibited username/password combinations used for unit-testing authentication itself (see unitsql/ddl/auth.sql). The mock is defined in class net.sf.farrago.test.FarragoMockLoginModule. The createCatalog target in the build creates the corresponding plugin/jaas.conf file unless it already exists. (See ant target "createJaasConfig".)
Predefined user/password combinations allowed by FarragoMockLoginModule:
- user: MockLoginModuleTestUser pass: secret
Farrago does not currently support installation of an interactive callback handler, although that might be useful for embeddings of Farrago into a larger application or app server (as opposed to a standalone daemon).
