cmd | ||
internal | ||
varlink | ||
COPYING | ||
default.nix | ||
Dockerfile | ||
go.mod | ||
go.sum | ||
module.nix | ||
README.md | ||
shell.nix |
Authentricity
A Lightweight Distributed Authentication System
Authentricity is a lightweight authenticaton system for distributed environments. Users and groups are stored internally in the systemd JSON user and group record formats
Theoretically the storage backends are pluggable, but presently only Hashicorp Consul is supported.
This project is very much a work in progress
Components
authentricity-hostagent
The hostagent should run on every machine for which you wish to use Authentricity for Unix logins. This component implements the systemd User/Group Varlink API to support user and group lookups.
It is intended to be deployed as a systemd service. See module.nix, which can be used to deploy this on NixOS for details
For both performance and resilience resaons, user information is cached locally:
- Information less than 60s old is considered up-to-date and Consul is not re-queried for it, speeding up user information requests and reducing Consul load, and
- In cases where Consul is unable to service requests, then the cache will be considered valid indefinitely
A future version may limit the amount of time locally cached information is considered valid.
TODO: Provide raw systemd unit files
authentricity-webui
This implements
- A login system, and single-domain shared cookie SSO system
- A portal which lets users add & remove SSH keys, change their password, etc, and
- A UI which lets users explore other users and groups, and which lets admins manage users and groups
- A UI which lets admins manipulate users and groups
This can be deployed as either
- A systemd service (see module.nix), or
- A container
TODO: Provide raw systemd unit files TODO: Provide example Kubernetes manifests/Kustomize chart?
authentricity-admin
Command line administation tool (performing direct database accesses)
Future Components
- Radius server
- Likely minimal feature set at first (PAP, no EAP, etc)
- TACACS+ server
- For networking appliances
- Separate cookie used for the Web UI from the auth proxy
- We can then domain scope the Web UI cookie down to just the UI itself, protecting better against Cookie theft attacks
- We can use asymmetric crypto for the domain-wide cookie and distribute the public keys to auth proxies via Consul
- JWT/OAuth 2.0/OpenID Connect issuer
- Integration of tokens into the Unix auth flow
- Return something like a Kerberos TGT that can be exchanged for service JWTs?
- Minimal authentication proxy without the Web UI?