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.
3.0 KiB
3.0 KiB
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.