# Security & Auth Refinement — Design

**Date**: 2026-03-16
**Component**: Security & Auth (`docs/requirements/Component-Security.md`)
**Status**: Approved

## Problem

The Security & Auth doc defined roles and LDAP mapping but lacked specification for the authentication mechanism (previously stated Kerberos/NTLM, changed to direct LDAP bind), session management, token format, idle timeout, LDAP failure handling, and load balancer compatibility.

## Decisions

### Authentication Mechanism
- **Direct LDAP bind** with username/password. No Windows Integrated Authentication (Kerberos/NTLM).
- User provides credentials in a login form. App validates against LDAP/AD and retrieves group memberships.
- No local credential store or caching.

### Session Management — JWT
- **JWT with shared symmetric signing key** (HMAC-SHA256). Both central nodes use the same key from configuration.
- **Claims**: user display name, username, roles, permitted site IDs (for site-scoped Deployment). All authorization from token claims — no per-request database lookup.
- **Load balancer compatible** — no server-side session state, no sticky sessions needed.

### Token Lifecycle
- **15-minute JWT expiry with sliding refresh**. On refresh, app re-queries LDAP for current group memberships and reissues token with updated claims. Roles never more than 15 minutes stale.
- **30-minute idle timeout** (configurable). If no requests within the idle window, user must re-login.
- Active users stay logged in indefinitely via sliding refresh.

### LDAP Failure Handling
- **Fail closed for new logins** — can't authenticate without LDAP.
- **Grace period for active sessions** — valid JWTs continue to work with current roles. Token refresh skipped until LDAP recovers. Avoids disrupting active work during brief outages.

### Signing Key
- **Shared symmetric key** (HMAC-SHA256) in configuration. Both nodes are trusted issuers. Asymmetric keys rejected as unnecessary complexity for a two-node trusted cluster.

## Affected Documents

| Document | Change |
|----------|--------|
| `docs/requirements/Component-Security.md` | Replaced Windows Integrated Auth with direct LDAP bind. Added Session Management, Token Lifecycle, Load Balancer Compatibility, and LDAP Connection Failure sections. |
| `docs/requirements/HighLevelReqs.md` | Updated authentication description (Section 9.1) to reflect username/password with JWT. |

## Alternatives Considered

- **Windows Integrated Authentication (Kerberos/NTLM)**: Rejected by user — app authenticates directly against LDAP/AD.
- **Server-side sessions with cookie**: Rejected — doesn't work with load balancer without sticky sessions or shared session store.
- **Asymmetric JWT signing (RSA/ECDSA)**: Rejected — both nodes are trusted issuers, no third-party validation needed.
- **Two-token pattern (access + refresh)**: Rejected — sliding single JWT with short expiry is simpler and achieves the same goal.
- **No idle timeout (rely on JWT expiry)**: Rejected — user wanted explicit idle timeout separate from token refresh cycle.
- **Fail closed for active sessions on LDAP outage**: Rejected — would disrupt engineers mid-deployment during brief LDAP outages.
- **Credentials cached for LDAP outage resilience**: Rejected — adds local credential store complexity; correct behavior is to deny new logins when identity can't be verified.
- **Per-request role lookup from database**: Rejected — unnecessary DB query on every request when roles refresh every 15 minutes via LDAP.
