# Security

> Public capability-level reference. Exact deployment values and time-sensitive audit evidence are maintained separately and verified for each customer response.

## 🔐 TLS Configuration and Cipher Suites

TLS 1.2+ enforced. Cipher suites (Nginx): ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-CHACHA20-POLY1305. Forward secrecy enabled.

## 🔐 Encryption of Internal Communication

**Kubernetes Deployments:**
Service mesh (Istio/Linkerd) enables mTLS between pods. Modern cipher suites (AES-GCM, TLS 1.2+). Self-signed certs, auto-rotated. Helm charts support customer-managed mesh configuration.

**Database/Backend:**
TLS supported (MySQL: RSA 2048+, Redis/MongoDB: TLS or private networking).

**External Endpoints:**
Trusted CA certs (ZeroSSL or enterprise CA).

## 💾 Data-at-Rest Encryption on Clients

**Platform-dependent:**
- **Android:** App sandboxing. OS-level encryption (version/settings dependent). External storage not encrypted by app.
- **Windows:** No app-level encryption. Requires OS encryption (BitLocker/EFS).
- **BrightSign/LG/Samsung:** Platform sandboxing. Files inaccessible without app execution.

Customers requiring encryption: Enforce OS-level or hardware encryption.

## 🔐 Data-at-Rest Encryption on Servers

Encryption-at-rest via infrastructure/storage provider (cloud-managed services or encrypted volumes).

## 🔒 Password Policy, Brute Force Protection, and Session Security

### Password Policy

**Cloud:** Global policy (OWASP/NIST aligned).
**On-prem/Private:** Customizable (length, complexity, character requirements, allow/disallow spaces, weak credential detection).

Passwords: bcrypt-hashed with per-password salt. Plaintext never stored or logged. MFA/passkeys prioritized over rotation policies.

### Brute Force Detection

Configurable IP-based and username-based thresholds provide lockout or throttling. Exact deployment values are restricted operational configuration and must be verified before use in a customer response.

### Session Handling

OAuth2 tokens. Timeout not directly configurable. Expiry: "Remember Me" extends refresh token lifespan. Forced revocation: Deletes all refresh tokens, immediately invalidates access across devices.

## 🛡️ System Hardening Standards

Containerized deployments use trusted upstream images (Alpine, Debian, OpenJDK). Regular scanning. No CIS hardening by default. Customers can apply infrastructure-level hardening.

## 🌐 IP Filtering Capabilities

Not built-in for cloud multi-tenant. Private/on-prem: Customer implements via firewall, reverse proxy, or ingress policies.

## 🛡️ Security Audits, Vulnerability Scanning, and Certifications

**Compliance Program:**
Wallboard has completed a SOC 2 Type II examination, and the final independent report has been issued. The report is available to customers under NDA. Controls remain under continuous monitoring through Sprinto.

**Ongoing:**
CVE scanning, code reviews, MFA enforcement, OWASP protection, dependency scanning.

**Penetration Testing:**
Annual penetration testing by independent third-party firms. Reports available under NDA.

### Customer-Initiated Audits

Supported in private/on-prem under mutual agreement.

## 🔑 Federated Authentication Methods

Per-tenant SAML 2.0. Each tenant configures own IdP.

### ✅ SAML 2.0 (Native Implementation - Version 2.1+)

**Implementation:** Native SP (replaces Keycloak). Per-tenant via Custom Domain. SP/IdP-initiated flows. Requires Custom Domain + DNS.

**IdP Config:** Presets (Microsoft, Custom). Metadata URL auto-fetch or manual entry.

**Certificates:**
- IdP: Manual/auto-refresh. Current+previous rotation. SHA1 rejection configurable (default: reject).
- SP: Auto-generated RSA 2048 certificate with controlled rotation and previous-key continuity. Private key never exposed.

**User Provisioning:** First-login account creation configurable. Role/team/UI profile mapping + defaults apply, with SCIM precedence: SCIM + User provisioning suppress SAML role mapping; team mapping suppressed only when Group sync is not Disabled. Name/UI profile updates stay independent. SAML cannot create/elevate Super administrator.

**Security:** Encrypted assertions, replay protection, signature validation (Response and/or Assertion, defense in depth: validates both when present), XXE protection, bounded clock-skew handling, and multi-tenant isolation.

**Legacy:** Keycloak deprecated 2.1+, supported existing. LDAP via Keycloak only.

### ✅ OpenID Connect (Public Login – Limited Use)

**Purpose:** Microsoft/Google login for existing accounts (not enterprise SSO).

**Flow:**
- Microsoft: Explicit linking required
- Google: Email-match direct access

**Native (2.1+):** No Keycloak. System Admin configures Client IDs. Public client flow. OAuth app registration required.

**Limitation:** Enterprise SSO uses SAML 2.0.

### ⚠️ LDAP (Legacy via Keycloak)

Deprecated 2.1+. Keycloak required. Not recommended. Use native SAML.

### 🚫 ADFS / Kerberos / Radius

Not natively supported. ADFS via SAML 2.0.

## 🔐 Authentication Methods and Access Controls

**Login Methods (2.1+):**
1. Username + Password
2. SAML SSO (see Federated Auth)
3. OIDC (Google/Microsoft, existing accounts only)
4. Magic Code (passwordless email OTP, 6-digit, short-lived, 2FA still required)

**Restrictions:** Per-user config. SSO-created users SSO-only. Admin enforcement per-tenant/user.

**2FA Enforcement:** TOTP required for all methods when enabled.

### SCIM Provisioning

Account lifecycle only - not a login method. Business/Enterprise; **Settings > Custom Domain > SCIM Provisioning**; Admin/Super admin. Users sign in via separately configured SSO; SCIM does not replace SAML auth or SAML first-login creation.

Customer-scoped Bearer Tokens (admin-managed): shown once, secret hashed. **Rotate** immediately revokes old token; **Revoke** stops that token. Disabling SCIM stops provisioning access without deleting accounts or stored tokens. Cannot assign Super administrator.

Deactivation retains account, revokes tokens, blocks issue/refresh. Reactivation does not clear independent user/customer restrictions. Deletion removes the account. No auto-adopt of manual/SAML accounts; email not renameable via SCIM - coordinate onboarding to avoid existing-email conflicts.

### AI Agent Access (MCP)

Administrators control MCP access at customer and user level. Customer settings define whether MCP is allowed and the defaults for regular users. User settings define whether that user can use MCP and expose three permission controls: Read, Create/Update, and Delete. The backend evaluates Create and Update separately by HTTP method, but the administration UI configures them together.

The customer default is MCP enabled; regular-user defaults are Read and Create/Update enabled with Delete disabled. Wallboard Super Administrators (`ADMIN`) start with MCP fully disabled, while customer Administrators (`OWNER`) follow the customer defaults. Existing role and team authorization still applies to MCP requests; user interface profiles do not grant or restrict MCP access.

MCP permission checks are enforced by the gateway/backend on actual MCP-originated requests, not only by UI visibility. Permission changes may take up to 5 minutes to apply.

---

## 🔑 OAuth 2.0 Implementation (Version 2.1+)

**Flows:**
- PKCE Authorization Code (Wallboard frontend)
- Authorization Code (backend, client secret)
- Password Grant (backward compat, "Service Account" toggle: OFF new users, ON existing)
- Client Credentials: Not implemented. Use Password Grant for service accounts.

**Endpoints:** /oauth/authorize, /oauth/login, /oauth/token

**OAuth Clients:**
- Super Admin: Global clients (any user)
- Customer Admin: Customer-scoped (customer users only)
- Public toggle: ON = no secret, PKCE required. OFF = has secret, auth code flow.

---

### 🧑‍💼 Privileged Access Controls (Version 2.1+)

**Read-Only Mode:** Admin/Super Admin can be read-only. Full visibility, no modification. Super Admin in read-only: Cannot escalate.

**Write Sessions:**

**Trusted Admin (default existing):** Login → Write access. Full privileges immediately.

**Non-Trusted Admin (default new):** Login → Read-only. TOTP re-auth for 30min write session. After expiry: TOTP again.

**Security:** 2FA required for write access. Token theft protection (no write without TOTP). Time-limited privilege escalation.

**Use Cases:** Trusted = experienced admins. Non-trusted = sales, support, contractors.

### 🔐 Multi-Factor Authentication (MFA)

**Implementation:** TOTP (Google Authenticator, Authy). All accounts. Required for all login methods when enabled.

**Three-Level Enforcement (2.1+):**

1. **System-Level:** Force super admins (default ON cloud, OFF on-prem configurable)
2. **Tenant-Level:** Customer Admin forces entire tenant (overrides user-level)
3. **User-Level:** Admin forces specific user (ignored if tenant-level forced)

**Enforcement:** Users blocked until configured. Sensitive operations require TOTP re-auth.

**Admin Tools:** Filter users by 2FA status.

**Protected Operations:** Login, user create/edit, customer delete, password change, 2FA toggle, privilege changes, system settings.

---

## 🤖 reCAPTCHA Protection (Version 2.1+)

**Hybrid v2+v3:** System Admin configures both. v3 is score-based, with a challenge-based v2 fallback when required.

**Config Flexibility:** Only v3, only v2, both (v3→v2 fallback), neither.

**Implementation:** Backend validates with Google (not just frontend).

**Protected Operations:** Login (/oauth/login), sensitive ops (user/customer CRUD, password, 2FA, privileges, settings).

---

## 🔒 Browser Session Security & Security Emails (Version 2.1+)

**Refresh-Token Binding:** Admin UI generates a stable random browser identifier and binds it to refresh tokens; a mismatched identifier rejects refresh. This is not a hardware or browser-characteristics fingerprint.

**New-Browser Recognition:** A separate secure browser marker identifies a previously seen browser context. A new browser/profile or cleared site data can trigger recognition as new; an IP change alone normally does not.

**Immediate Emails:** Users are notified after a successful password/TOTP login from a new browser context, password change, or 2FA enable/disable. Emails include event time and IP, browser/device details for new logins, and the acting Administrator when another user made the security change.

**Weekly 2FA Follow-Up:** Monday 09:00 server time. Users who have not completed required 2FA receive reminders. When **Settings > Preferences > Security > Force two-factor authentication** is enabled, customer Administrators receive adoption counts, compliance rate, and affected users. A configured system recipient receives a report when Super Administrators lack 2FA. Individual enforcement is **Settings > Users > Force to set two-factor authentication**.

**Boundaries:** No notification preferences or device-history UI. Failed logins do not generate these emails. New-browser email coverage is confirmed for password/TOTP authentication.

---

## ⚠️ Legacy UI Deprecation Impact (Version 2.1+)

**Background:** Old UI (pre-1.12) + New UI (1.12+) both until 2.1.

**Breaking Changes:** Admin UI unavailable (auto-redirect). reCAPTCHA/2FA ops cannot execute. Example: Cannot create/edit/delete users. WHY: Version 2.1 security features (OAuth 2.0 PKCE, enhanced reCAPTCHA) break old UI architecture.

**User Impact:** Forced new UI for admin/sensitive ops. Common friction. Notifications sent. Common complaints: "site broken", "can't login".

**Support Note:** "I can't delete users" → "2.1 requires new UI for security ops"

---

## 📄 Logging, Tenant Visibility, and Forwarding Options

**System Logs:** Grafana stack — Loki (log aggregation), Mimir (metrics), Grafana Alloy (collector). Accessible only to infrastructure operators (not exposed via the Wallboard management UI).

**Tenant Logs:** TimescaleDB audit table. Per-tenant via UI. Timestamps, user IDs, actions (content edits, login attempts, user management), metadata. Security events (login, password, MFA) tracked.

**Logs UI:** UI label is **Logs** under **Settings > Logs** and **Administrator > Logs**. Shows product activity rows with timestamp, log level, message, and related context where available. Filtering, CSV export, and message copy help troubleshoot tenant-visible activity.

**Audit Detail:** Entity-change logging captures relevant product changes and masks sensitive values where applicable. Do not assume non-visible internal classifications are user-facing fields.

**AI/Data Diagnostics:** AI datasource and Web scraper runs can appear in tenant-scoped Logs where available. Use these for product-level troubleshooting, not infrastructure log access.

**Device Diagnostics:** **Download device logs** and **Debug mode** are device troubleshooting tools. Device logs are separate from product activity logs.

### 🔄 Log Forwarding

Private/on-prem: Customer implements (Filebeat, Fluent Bit, syslog+TLS, HTTPS-based pull). No built-in syslog/SFTP in cloud.

### 🔐 Integrity and Access

Logs in transit: TLS/HTTPS. System logs: Infrastructure operator access only (Grafana dashboard, not exposed in Wallboard UI). Tenant logs: Isolated per customer, no cross-customer access, accessible via Wallboard management UI.