Step Eight — Roles, Signed Tokens, Rate Limits, and Per‑Plugin Policy

We give your phone gateway a principled constitution: who may read what, how often, and for how long. Still read‑only. Still transparent. Now rigorously governed.

---

✅ Fresh artifacts

• solveforce_phone_eight.py — Download
  SHA‑256: 325e62915f4acdb44125fa33b1ad6536603072bf28ab43db2fff007fabf71091
• Policy example — Download
  SHA‑256: c8dd96af59fc1160e6296dc2d94d342401fad5f078ff1852309525e17aaf4d3f

Keeps everything from Steps 1–7 (UI, SSE, JSONL export, dynamic plugins, schemas, metrics, bearer/mTLS). Adds RBAC, signed tokens, rate limiting, and per‑plugin allowlists with SSE filtering.

---

What’s new (clean, enforceable)

Signed tokens give you time‑boxed, role‑scoped credentials without a database.

429 responses include Retry-After.

Metrics include solveforce_rate_limited_total.

5) Per‑plugin allowlists + SSE filtering

• Define who can see which plugin:
  • JSON file: --policy-file solveforce_policy_example.json
  • Or inline: --allow-plugin snmp_basic:netops,admin (repeatable)
• If a plugin isn’t listed, default rule applies: anyone with reader (or admin) can read it.
• SSE is filtered: clients only receive events for plugins they’re allowed to read.

Policy is conservative, composable, and visible via GET /policies. Clients can introspect themselves at GET /whoami.

---

Termux (Android) — secure launch recipes

A) Roles + static token + policy (HTTP)

python solveforce_phone_eight.py \
  --host 0.0.0.0 --port 8080 --poll 5 \
  --plugins-dir ~/solveforce/plugins \
  --history-size 512 --strict-schema \
  --auth-mode protected \
  --auth-token READER1:reader \
  --auth-token NETOPS:reader,netops \
  --policy-file /sdcard/solveforce/solveforce_policy_example.json \
  --allow-admin --admin-token ADMIN123

Open http://PHONE_IP:8080/ui → paste a token.
Check identity: /whoami • See allowed plugins: /policies.

B) TLS + signed tokens (mints on demand)

# (from Step Seven)
openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout server.key -out server.crt -subj "/CN=phone.local"

python solveforce_phone_eight.py \
  --host 0.0.0.0 --port 8443 \
  --tls-cert server.crt --tls-key server.key \
  --auth-mode strict \
  --signing-secret "CHANGE_ME_LONG_RANDOM" \
  --policy-file /sdcard/solveforce/solveforce_policy_example.json

Mint a token (CLI):

python solveforce_phone_eight.py --signing-secret "CHANGE_ME_LONG_RANDOM" \
  --mint-token "sub=ron roles=reader,metrics dur=7200"

Use it in the UI (saved to localStorage) or with curl:

curl -H "Authorization: Bearer S1...." https://PHONE_IP:8443/read?plugin=battery

C) mTLS + signed tokens + rate limit

python solveforce_phone_eight.py \
  --host 0.0.0.0 --port 8443 \
  --tls-cert server.crt --tls-key server.key \
  --tls-ca ca.crt --mtls-require \
  --auth-mode strict \
  --signing-secret "CHANGE_ME_LONG_RANDOM" \
  --rate-window-seconds 60 --rate-max 90 --rate-sse-max 6 \
  --policy-file /sdcard/solveforce/solveforce_policy_example.json

---

New endpoints

• GET /whoami → { subject, roles, token_type, signed?, allowed_plugins[] }
• GET /policies → current plugin allowlist (resolved)
• GET /admin/mint → mint signed tokens (admin only; requires --signing-secret)
• (Everything from prior steps remains; /events now respects plugin policy per client.)

---

Policy example (the included JSON)

{
  "plugin_roles": {
    "battery": ["reader", "ops", "admin"],
    "net": ["reader", "netops", "admin"],
    "snmp_basic": ["netops", "admin"],
    "http_json": ["reader", "integrations", "admin"]
  },
  "role_aliases": {
    "ops": ["reader"],
    "netops": ["reader"]
  }
}

• reader can see battery, net, http_json.
• snmp_basic is reserved for netops or admin.
• ops and netops alias back to reader for convenience.

---

WordPress — Step Eight section (drop‑in)

Step Eight — Roles, Tokens, Limits, Policy

• RBACreader (data endpoints), metrics (prom), admin (admin routes), plus your own roles.
• Signed tokensS1 HMAC tokens with sub/roles/iat/exp (--signing-secret). Mint via CLI or /admin/mint.
• Static tokens with roles--auth-token TOKEN:role1,role2.
• Rate limitingsliding window per IP/token (--rate-window-seconds, --rate-max, --rate-sse-max).
• Per‑plugin policy--policy-file JSON or --allow-plugin name:role,role. Unlisted plugins default to reader.
• SSE privacyevent stream filtered to authorized plugins.
• Introspection/whoami and /policies.
• PhilosophyIdentity at the edge, minimal moving parts, explicit contracts. Read‑only always.

---

Integrity (publish these)

sha256sum solveforce_phone_eight.py
# 325e62915f4acdb44125fa33b1ad6536603072bf28ab43db2fff007fabf71091

sha256sum solveforce_policy_example.json
# c8dd96af59fc1160e6296dc2d94d342401fad5f078ff1852309525e17aaf4d3f

---

Where we can go for Step Nine

• Per‑plugin sampling & backoffadaptive read schedules, caps per plugin.
• Rate limit policies per role and per route.
• Audit log (JSONL) for auth decisions, policy hits, and rate‑limit drops.
• Signed token “aud” and per‑plugin grants inside the token.
• Optional Ed25519 tokens(deterministic signatures, stdlib hashlib w/ ed25519 if available or pure‑python).

If this constitution reads right, we’ll keep building the common law—one clear power at a time.

---

Step Nine — Adaptive cadence, policy‑driven throttles, and an honest trail – SolveForce Communications

---

Key terms in plain language

Open a term for a concise explanation of language used on this page.

🛡️Cybersecurity

The practices and controls used to protect identities, devices, networks, applications, and data from unauthorized access, disruption, or manipulation.

🚫Zero Trust

A security model that does not automatically trust a user or device because of its location. Access is continuously verified and limited to what is necessary.

🧭SASE

Secure Access Service Edge combines networking and security capabilities in a cloud-delivered architecture so users and locations can receive consistent policy wherever they connect.

🪪Identity and Access Management (IAM)

The systems and policies that determine who a user is, what resources they may access, and how that access is authenticated and reviewed.

✅Multi-Factor Authentication (MFA)

A login control requiring more than one form of verification, such as a password plus an authenticator app, security key, or biometric factor.

🔍MDR / XDR

Security services and tools that monitor activity, investigate suspicious behavior, and help contain threats. MDR is managed detection and response; XDR correlates signals across multiple security layers.