kyle/mcias

Files

Kyle Isom 7c79d00514 Sync docs: ARCHITECTURE, PROJECT, PROJECT_PLAN

- ARCHITECTURE.md §12: add mciasdb, mciasgrpcctl, internal/grpcserver,
  proto/, and gen/ to the directory structure diagram
- ARCHITECTURE.md §17: replace buf generate references with protoc;
  the implementation uses protoc + protoc-gen-go + protoc-gen-go-grpc
  invoked via go generate ./... (proto/generate.go)
- PROJECT_PLAN.md §7.1: replace buf.yaml/buf.gen.yaml acceptance
  criteria with the protoc-based go:generate approach actually used
- PROJECT_PLAN.md §7.6: clarify that gen/ is committed to the repo
  (not gitignored); only the binary /mciasgrpcctl is excluded
- PROJECT.md: replace scrypt with Argon2id (the actual algorithm);
  remove the redundant Argon2 suggestion line

2026-03-11 14:44:08 -07:00

2.8 KiB

Raw Blame History

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 should be two 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.

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.

2.8 KiB Raw Blame History