[tac_plus] Dynamic authentication plugins via shared libraries?

[Steve Kemp]

>   OK I'll tidy, re-test, and document the code, and submit a patch.

  Comments on this initial stab are welcome.    Once we agree
 the documentation is adequate I'll submit the actual code.

diff --unified --recursive tacacs+-F4.0.4.26.orig/tac_plus.conf.5.in tacacs+-F4.0.4.26.forked/tac_plus.conf.5.in
--- tacacs+-F4.0.4.26.orig/tac_plus.conf.5.in	2012-06-07 00:21:50.000000000 +0100
+++ tacacs+-F4.0.4.26.forked/tac_plus.conf.5.in	2012-08-21 21:18:00.000000000 +0100
@@ -370,12 +370,21 @@
 example, before a <user> can be a specified as a member of a <group>,
 the <group> has to be defined.
 .\"
+
+.TP
+.B load_plugin <filename>
+This loads a shared library which is assumed to export the single function
+.sp
+int plugin_authenticate( char *username, char *passwd, char *args );
+.sp
+If this function returns 1 the login is considered a success.
+
 .TP
 .B password_spec
 There are five authentication mechanisms available: no password, cleartext,
 DES, PAM, a file in
 .BR passwd(5)
-format, and skey.
+format, skey, and via an external plugin.
 .sp
 .nf
     file <filename>
@@ -384,6 +393,7 @@
     PAM
     skey
     nopassword
+    plugin [plugin arguments]
 .fi
 .sp
 skey is an OTP (One Time Password) facility.  The daemon must be built
@@ -401,6 +411,9 @@
 .sp
 Note: some cases of <password_spec> do not accept all of these mechanisms.
 .\"
+.sp
+plugin usage delegates the authentication to a single method exported via
+the shared library loaded via <load_plugin>
 .TP
 .B permission
 Specifies that some match (for example a <service> or <cmd-match>) is
diff --unified --recursive tacacs+-F4.0.4.26.orig/users_guide.in tacacs+-F4.0.4.26.forked/users_guide.in
--- tacacs+-F4.0.4.26.orig/users_guide.in	2011-05-27 23:11:57.000000000 +0100
+++ tacacs+-F4.0.4.26.forked/users_guide.in	2012-08-21 21:11:26.000000000 +0100
@@ -353,7 +353,7 @@
 daemon to the NAS. This is a security issue if the TACACS+ key is ever
 compromised.
 
-There are 4 ways to authenticate a user for login.
+There are 5 ways to authenticate a user for login.
 
 1). You can include a DES (or cleartext) password for a user or for a
 group that s/he is a member of, viz:
@@ -433,6 +433,30 @@
 be that for each authentiction that is attempted, the password will appear
 to be wrong whether it was typed correctly or not.
 
+5). Authentication via a tac_plus-specific plugin
+
+tac_plus supports the use of plugins for authentication purposes.  These
+plugins are implemented as shared libraries which export a single function
+invoked to test a username & password pair.
+
+Writing a tac_plus plugin is considerably more straight-forward than writing
+a PAM plugin, and offers a comparible level of flexibility.
+
+A sample configuration might look like this:
+
+    load_plugin = /usr/lib/day_of_week.so
+
+    user = bob {
+       login = plugin Mon-Fri
+    }
+
+    user = chris {
+       login = plugin
+    }
+
+Currently only a single plugin may be loaded, but this might be extended
+in the future.
+
 
 RECURSIVE PASSWORD LOOKUPS
 ---------------------------


Steve

--