Kyle Isom
a80242ae3e
- Introduced `web/templates/` for HTMX-fragmented pages (`dashboard`, `accounts`, `account_detail`, `error_fragment`, etc.). - Implemented UI routes for account CRUD, audit log display, and login/logout with CSRF protection. - Added `internal/ui/` package for handlers, CSRF manager, session validation, and token issuance. - Updated documentation to include new UI features and templates directory structure. - Security: Double-submit CSRF cookies, constant-time HMAC validation, login password/Argon2id re-verification at all steps to prevent bypass.
74 lines
3.0 KiB
Markdown
74 lines
3.0 KiB
Markdown
# MCIAS
|
|
|
|
We are building a single-signon and IAM system for personal projects.
|
|
|
|
## Background
|
|
|
|
The Metacircular Identity and Access System (MCIAS) provides standard
|
|
tools for user and access management among metacircular and wntrmute
|
|
systems.
|
|
|
|
In particular, the target audience is a single developer building
|
|
personal apps. It should be easy to use MCIAS to facilitate onboarding
|
|
friends onto these personal apps.
|
|
|
|
MCIAS is a foundational security and identity system. As such, the
|
|
highest priorities are for security, robustness, and correctness.
|
|
Performance is secondary, and can be tuned later.
|
|
|
|
## Specifications
|
|
|
|
+ Applications should be able to either do an interactive login, using a
|
|
username/password (and potentially a TOTP), or present a token.
|
|
+ Applications should be able to renew the token, which would nominally
|
|
expire after some period (defaulting to maybe 30 days).
|
|
+ There are two kinds of users: human and system accounts.
|
|
+ System accounts can only present a token; they have a single token
|
|
associated with that account at a time.
|
|
+ User accounts have roles associated with them.
|
|
+ Users with the admin role can issue tokens for any app, or users with
|
|
the role named the same as a service account can issue tokens for that
|
|
service account.
|
|
+ Admin users can also revoke tokens for a service account.
|
|
+ Service accounts (and users with the a role named the same as the
|
|
service account) can also retrieve Postgres database credentials for
|
|
the service account.
|
|
+ Human accounts should eventually support FIDO logins and Yubikey auth,
|
|
but the first pass only needs username, password, and optional TOTP.
|
|
|
|
## Technical details
|
|
|
|
+ User passwords will be stored using Argon2id (PHC format), meeting
|
|
OWASP 2023 recommended parameters (time=3, memory=64 MiB, threads=4).
|
|
+ The service account tokens and user/password authentication can be
|
|
used to obtain a JWT, if that is appropriate.
|
|
+ All authentication events should be logged.
|
|
+ This service should use the packages contained in
|
|
git.wntrmute.dev/kyle/goutils for logging etc.
|
|
+ The database should be sqlite.
|
|
+ Modern cryptography should be used. Preference should be given to
|
|
Ed25519 as the public algorithm for signatures, for example.
|
|
|
|
## Interfaces
|
|
|
|
+ The primary interface will be an REST API over HTTPS. TLS security is
|
|
critical for this.
|
|
+ We will also need to build client libraries in several languages
|
|
later on.
|
|
+ There are four command line tools associated with MCIAS:
|
|
+ mciassrv is the authentication server.
|
|
+ mciasctl is the tool for admins to create and manage accounts, issue
|
|
or revoke tokens, and manage postgres database credentials.
|
|
+ mciasdb is the offline database maintenance tool for break-glass
|
|
recovery, bootstrap, and direct SQLite operations.
|
|
+ mciasgrpcctl is the gRPC admin CLI companion (mirrors mciasctl
|
|
over gRPC).
|
|
|
|
## Notes
|
|
|
|
+ We need an explicit security model.
|
|
+ This is a system for small, personal services. Manual user lifecycle
|
|
managment is acceptable and expected. Federation is an explicit
|
|
nongoal.
|
|
+ Strong testing is a requirement.
|