1
- # Generic Organisation-wide Authentication Security Service
1
+ # GSSundheit
2
2
3
3
## What's that?
4
4
@@ -10,12 +10,28 @@ transparently.
10
10
11
11
[ GSSAPI ] : https://en.wikipedia.org/wiki/GSS-API
12
12
13
+
13
14
## How does it work?
14
15
15
- A ` goatssed ` deamon runs on the trusted server (as an unprivileged user), and
16
- listens to a well-known UNIX socket (say, ` /var/run/goatsse .sock ` ).
16
+ A ` gssundheit ` deamon runs on the trusted server (as an unprivileged user), and
17
+ listens to a well-known UNIX socket (say, ` /var/run/gssundheit .sock ` ).
17
18
18
19
When a user connects to the socket, the deamon authenticates them using
19
20
` SO_PEERCRED ` (basically, asking the kernel for which UID is at the other end
20
- of the socket) and sends a signed ticket containing the uid (or username?),
21
- the origin server and the current time.
21
+ of the socket) and sends a signed authentication ticket with auxiliary
22
+ metadata used to support GSSAPI features (such as channel bindings).
23
+
24
+
25
+ ## Goals
26
+
27
+ 1 . The two primary goals are simplicity and security:
28
+ GSSundheit should be simple to use and simple to audit.
29
+
30
+ 2 . The main usecase for GSSundheit is through a SASL authentication service,
31
+ like [ auth] ( https://github.com/whawty/auth ) , but GSSAPI is a generic API
32
+ and any other kind of service may leverage it.
33
+
34
+ 3 . Some optional features of GSSAPI are considered especially desireable:
35
+ - [ ] channel binding, see [ RFC 5056] .
36
+
37
+ [ RFC 5056 ] : https://tools.ietf.org/html/rfc5056
0 commit comments