Recent changes to Confluent_auth

Confluent_auth modified by Guang Cheng Li

Guang Cheng Li — Mon, 04 Aug 2014 02:53:54 -0000

--- v4
+++ v5
@@ -1,3 +1,5 @@
+[[include ref=Design_Warning]]
+
 Confluent Authentication model
 ---------------------------------
 This will be a developer toned document for now, going into more detail

Confluent_auth modified by Jarrod Johnson

Jarrod Johnson — Fri, 01 Aug 2014 13:36:33 -0000

Confluent_auth modified by Jarrod Johnson

Jarrod Johnson — Fri, 01 Aug 2014 13:36:20 -0000

Confluent_Auth modified by Jarrod Johnson

Jarrod Johnson — Wed, 16 Jul 2014 18:54:16 -0000

--- v1
+++ v2
@@ -25,3 +25,13 @@
 1.If client is either root or the owner of the process, they are allowed in.
 2.Otherwise, the username and groups are checked against known users/groups
 3.If 1 and 2 find no matches, revert to generic passphrase mechanism common with TLS socket.
+
+TLS Socket
+-----------------------------------------
+1. If client certificate is provided and verified, then subjectaltname is used if present, else subject to identify user.  If certificate does not work, fail.
+2. If no client certificate provided, go to generic passphrase mechanism as in unix socket.
+
+HTTP
+----------------------------------------
+1. If and only if over a unix socket, consider evaluating client certificate passed in headers
+2. Go to generic passphrase mechanism

Confluent_Auth modified by Jarrod Johnson

Jarrod Johnson — Tue, 15 Jul 2014 21:15:57 -0000

Confluent Authentication model

This will be a developer toned document for now, going into more detail
than most any user will care to think about.

Confluent does/will offer a number of authentication schemes:
Passphrases in its configuration stores:
-PBKDF transformed passphrase
-Users need not exist in anything outside the service (e.g. /etc/passwd) if not appropriatePAM configuration
-If /etc/pam.d/confluent exists, the above passphrase backend is totally ignored in favor of PAM
-Users and/or groups still must exist in the cfg to be authorized
Certificates
-For TLS direct client to be supported
-Might not be supported for HTTPConsole access tokens
-Allowing a client service to authenticate and request a token which is bound to a particular console
*System authentication
-Unix domain socket uses the kernel attested user/password values to correlate to groups

To be clear about priorities, the various services are described:

UNIX Socket

1.If client is either root or the owner of the process, they are allowed in.
2.Otherwise, the username and groups are checked against known users/groups
3.If 1 and 2 find no matches, revert to generic passphrase mechanism common with TLS socket.