Simple distributed authentication system
Go to file
2024-05-30 16:04:54 +01:00
cmd Initial WIP import 2022-07-11 21:49:26 +00:00
internal webui: fix portal redirect when using webauthn 2024-05-30 16:04:54 +01:00
varlink Initial WIP import 2022-07-11 21:49:26 +00:00
COPYING Initial WIP import 2022-07-11 21:49:26 +00:00
default.nix authz: add ability to require specific group 2023-03-08 14:32:46 +00:00
Dockerfile Dockerize, readme update 2023-07-10 02:10:04 +02:00
go.mod Dockerize, readme update 2023-07-10 02:10:04 +02:00
go.sum webAuthn: Add initial support 2023-03-08 13:32:26 +00:00
module.nix webAuthn: Add initial support 2023-03-08 13:32:26 +00:00
README.md Dockerize, readme update 2023-07-10 02:10:04 +02:00
shell.nix Initial WIP import 2022-07-11 21:49:26 +00:00

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

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?