Game Warden Secure Configuration Guide

This document outlines the mandatory application-level configurations and shared responsibilities required for software operating within the Game Warden DevSecOps platform.

To ensure transparency and compliance, this guide is publicly available on the 2F Platform Help Center and is formally included in the Certification package.

Important

Top-level administrative accounts are defined throughout this guide as:

Tenant Application Owners: Individuals with ultimate authority over the application's configuration, deployment, and security posture.
Tenant Administrators: Individuals authorized to configure application-level access, assign roles, and manage integrations.

1 - Identity & authentication (AuthN) management

Game Warden centralizes identity management to ensure all users access the system through highly secure, verifiable channels.

Control	Description
Centralized authentication	Your application must not handle local user authentication or maintain local user databases. Game Warden's centralized identity service, Keycloak, manages all authentication using supported federated protocols.
No embedded credentials	Your application code and static storage must not contain unencrypted static authenticators, such as hardcoded passwords, API keys, or tokens.
Hardware-based MFA enforcement	The platform mandates phishing-resistant, hardware-based Multi-Factor Authentication (MFA) for all user access.

2 - Application-level authorization (AuthZ)

While Game Warden handles authentication, your application enforces who can see and do what once inside.

Control	Description
JWT validation	Upon successful login, the platform injects a signed JSON Web Token (JWT) into the request. Your application back end must extract this JWT and cryptographically verify its signature using the public keys from Keycloak's endpoint.
Claim-based access control	Your application must parse the JWT claims to enforce granular Role-Based (RBAC) or Attribute-Based Access Control (ABAC).
Multi-tenancy isolation	The platform does not natively enforce tenant isolation at the data layer; your application must use JWT group claims to segment users and data by tenant.
Prohibition of shared accounts	Every user must be uniquely identified. Game Warden prohibits the use of generic, shared, or group application accounts.

3 - Session & account lifecycle management

Configure your application to respect strict session limits and prevent unauthorized access from unattended workstations.

Control	Description
Idle timeouts	Your application must enforce idle session timeouts of 30 minute sessions. When the session times out, the application must reciprocate the logout, invalidate the session, and obscure the screen.
Concurrent sessions	Your application must support the platform's strict limits on concurrent sessions, allowing up to three (3) active sessions for privileged users and two (2) for non-privileged users.
Automated account deactivation	Users who do not actively authenticate for 30 days are automatically deactivated.
Emergency deprovisioning	Maintain internal procedures that disable application access for terminated personnel within one (1) hour of their departure.

4 - Network boundaries & data flow constraints

Game Warden enforces a strict zero-trust network architecture. Configure your application to operate within a "deny-by-default" network environment.

Control	Description
Approved external connections	Your application cannot route data to arbitrary external URLs. All required external endpoints must be formally submitted, reviewed, and recorded in the Approved Integration Registry before deployment.
Preventing data spillage	Application administrators must ensure that sensitive data is never routed, exported, or transmitted to unauthorized external systems or lower-security environments.
Secure token storage	Frontend developers must store JWTs securely in memory and avoid `localStorage` or `sessionStorage` to mitigate Cross-Site Scripting risks.

5 - Cryptography & security telemetry

Control	Description
FIPS 140-validated cryptography	Game Warden encrypts all data at rest and in transit by default. If your application uses any custom cryptographic modules or self-managed encryption for data, it must use FIPS 140-validated cryptography.
Audit logging	Configure your application to generate and forward immutable application-level security logs (covering authentication events, privilege escalations, and data access) directly to the Game Warden Security Information and Event Management (SIEM).

6 - Enhanced configuration & auditing capabilities

To ensure long-term configuration management and compliance auditing, Game Warden provides the following enhanced capabilities for top-level administrative and privileged accounts:

Capability	Description
Secure defaults	Game Warden provisions the platform and its settings with secure-by-default network, encryption, and container policies upon initial deployment.
Export and API capabilities (Coming Soon)	Customers can view, adjust, and export their current security settings and configurations via an API in a machine-readable format.
Configuration comparison (Coming Soon)	Customers and third-party tools can use exported machine-readable data to automatically compare their current application state against Game Warden's recommended secure defaults.