This file is deprecated, and only partially valid.
These are plans for how this module should be built.
The actual aim of this module is to identify user, not to authorise her
(authorization is "implicit").
This module looks at a connection's parameters (source port/source IP/timestamp)
(these are enough to identify quite stricly the connection) and performs SQL
requests to a database containing the attached UID, if any.
As an option, an LDAP request can then be performed, to convert the UID into an
actual username.
Provided directives :
AuthNufwAuthoritative On/Off Prevent other authentication modules from authenticating
the user if this fails
AuthNufwEnabled On/Off Set to off to disable use of this module for
some ressources.
AuthNufwTimeWindow integer default : 1 second. Specifies the time window
a connection will be considered to match. Increase on laggy
networks, be aware the higher this value, the
most probable attacks get. Using NTP is obviously not an option
when using this module.
AuthNufwSQLHost IP or name defaults to localhost
AuthNufwSQLPort port nb defaults to 5432 or 3306
AuthNufwSQLDatabase database name defaults to ??
AuthNufwSQLUser database user defaults to ??
AUthNufwSQLPassword database password
AUthNufwSQLSSL* SSL encryption options will be added later.
------------------------------------------------------------------------
exported functions :
1 create_auth_nufw_dir_config -> apache function to create config for a dir
there is no special merge, overriding is what we
want.
2 create_auth_nufw_config -> ???
3 auth_nufw_cmds -> the command table, describing above directives
4 auth_nufw_identify_user -> find out whom a connection comes from, from the
SQL database.
5 auth_nufw_dummy_auth -> dummy function, auth is actually checked in
auth_nufw_identify_user. Probably this function
can vanish actually..
6 auth_nufw_child_init -> what to do when a child spawns
7 auth_nufw_child_exit -> what to do when a child dies
------------------------------------------------------------------------
subtasks:
1
2
4 a/ check if child already has an open database conn
b/ if not, connect
b1/ if it fails, log an error message and return
b2/ success
c/ build request, taking time into account
d/ perform request
e/ is there zero or one result?
e1/ if not, log some critical message (and return)
e2/ yes
f/ is there zero result?
f1/ yes -> no identification, return
f2/ no -> identification success, fill in the user field (and others?)
5 if needed, set the user as authenticated
6 init a database link (or grab one from the pool ?)
if this fails, log an error
7 close the database link (or hand it back into the pool)
