feat: add global viewer role and global token support

[sap-yuan]

• Add 'viewer' role (level 15) to OPA admin policy
• Allow viewer role GET-only access to all resources
• Add global_token database table (migration 00045)
• Add encode_global_token() in token.py
• Support 'global' token type in ibflask.py normalize_token()
• Add global token CRUD API endpoints under /admin/global-tokens
• Update OPA projects policy for global token read access

[liuwei08]

Overall the feature direction is sound and the OPA test coverage is a good sign. However there are several issues that need to be addressed before merging:

Must fix:

• Audit log silently drops failed requests (4xx/5xx) — limits security observability
• Confirm DELETE /user/global-tokens/{id} handler enforces user_id ownership

Should fix:

• viewer role level 15 is higher than user 10 — verify no unintended privilege escalation via level comparisons
• Hardcoded role: viewer makes scope_push column dead code — clarify or remove
• Split 00045 + 00046 migrations into one atomic DDL

Suggestions:

• Add token expiration support (expires_at)
• Add a retention policy for global_token_access_log
• Move the infrabox/local-dev/ tooling into a separate PR

[liuwei08]

[Security] Audit log silently drops failed requests

Skipping 4xx/5xx responses means the audit log cannot be used to detect permission probing or brute-force attempts. Successful-only logs are misleading for security auditors.

Consider logging at least 401 and 403 responses, or removing this filter entirely and logging all requests regardless of status code:

# Before: silently skip errors
if response.status_code >= 400:
    return response

# After: log everything, including failures
# (or at minimum: if response.status_code in (401, 403): log and return)

[liuwei08]

[Design] Hardcoded viewer role ignores scope_push

The DB schema stores scope_push per token, but here the role is always hardcoded to 'viewer' regardless of the token's actual scope_push value. This means even if a global token has scope_push=True, it will always be treated as read-only.

Is this intentional? If so, the scope_push column in the global_token table is dead code and should be removed. If not, the role assignment needs to reflect the actual scope:

token['user'] = {
    'id': r['user_id'],
    'role': 'viewer',  # always viewer regardless of scope_push — is this intended?
}

[liuwei08]

[Logic] viewer role level (15) is higher than user (10) — verify comparison direction

Assigning viewer level 15 (above user 10) is counterintuitive for a read-only role. If any policy uses user_roles[...] >= some_threshold to grant access, viewer will inadvertently pass checks that a regular user would not.

Please confirm that all policy rules relying on role level comparisons behave correctly with viewer = 15. If viewer is intended to be the least-privileged role, consider assigning it a level below user, e.g. 5.

[liuwei08]

[Security] OPA policy for DELETE does not enforce ownership

The OPA rule allows any logged-in user to DELETE any token by path parameter alone, with no user_id ownership check at the policy level. The actual ownership enforcement must happen entirely in the handler.

Please verify that UserGlobalToken.delete() in global_tokens.py always includes AND user_id = %s in its SQL query. If the handler ever skips that check, any user could revoke another user's token. A defence-in-depth approach would add an ownership assertion to this OPA rule as well.

[liuwei08]

[Migration] Consider merging 00045 and 00046 into a single migration

00045.sql creates global_token without user_id, and 00046.sql immediately ALTER TABLEs it to add user_id. If 00046.sql fails during deployment, the DB is left with an ownerless global_token table that has no foreign key constraint — any token inserted between the two migrations would have no owner.

Suggested fix: consolidate both into a single migration that creates the table with all final columns, including user_id uuid REFERENCES "user"(id) ON DELETE CASCADE NOT NULL.

[liuwei08]

[Ops] No retention policy for global_token_access_log

The access log table has no TTL, partition, or cleanup job. On a busy instance this table will grow indefinitely. Consider either:

• A scheduled job (e.g. DELETE FROM global_token_access_log WHERE accessed_at < NOW() - INTERVAL '90 days')
• Table partitioning by accessed_at
• Or at minimum, documenting that operators are responsible for periodic pruning

[liuwei08]

[Design] No token expiration support

Global tokens are permanent once created — they remain valid until explicitly deleted. For long-lived viewer tokens this is a security risk (e.g. if a user leaves the organization).

Consider adding an optional expires_at TIMESTAMP column and checking it in validate_global_token():

if r['expires_at'] and r['expires_at'] < datetime.utcnow():
    logger.warning('global token expired')
    return None

[liuwei08]

[Scope] Local dev stack is unrelated to feat/global-viewer-role

The infrabox/local-dev/ directory (Makefile, docker-compose, seed.sql, README) is a standalone developer tooling addition that has no functional dependency on the global viewer role feature. Bundling it here makes the PR harder to review and will complicate bisecting if either change introduces a regression.

Please consider splitting this into a separate PR.

[liuwei08]

All previous "Must Fix" and "Should Fix" items have been addressed:

• ✅ Audit log now records all responses (including 4xx/5xx)
• ✅ DELETE handler enforces user_id ownership via SQL (AND user_id = %s)
• ✅ viewer role level corrected to 5 (below user at 10)
• ✅ Migrations 00045 + 00046 consolidated into a single atomic DDL
• ✅ expires_at token expiration implemented in schema and validation logic
• ✅ infrabox/local-dev/ tooling split into a separate PR

Two minor items remain as acceptable follow-ups:

• scope_push is still stored but not yet enforced (intent documented in comment — fine for now)
• global_token_access_log pruning relies on operator runbook rather than automation

One additional note for a future PR: the normalize_token() fallthrough return token for unknown token types is a minor security hardening opportunity — consider returning None instead.