Skip to content

Access Control in Game Warden for FedRAMP Deployment

For applications deployed within the Game Warden FedRAMP High authorization boundary, access control operates under a shared responsibility model. Game Warden provides a baseline set of administrator privileges and manages network-level access. You are responsible for managing access within your application — including database accounts and application-level roles — in strict adherence to FedRAMP High baseline controls.

Keycloak and Federated Single Sign-On

Game Warden manages platform access through Keycloak, a centralized identity service federated with FedRAMP High-authorized Identity Providers (IdPs) such as Platform One (P1), Login.gov, and Okta. This allows users to authenticate using existing government-issued credentials (CAC or PIV card) for Single Sign-On (SSO) across all Game Warden services.

A user's Game Warden account is automatically provisioned on their first successful login through an approved IdP. Account creation is automatic, but you must still grant each user the appropriate permissions and application access before they can use your application.

For applications deployed within the Game Warden FedRAMP authorization boundary, the following authentication rules apply:

  • Mandatory Keycloak Integration: Your application must integrate with and authenticate exclusively through Keycloak using a supported protocol such as OpenID Connect (OIDC) or SAML.
  • No Local Authentication: Your application must not implement or rely on local user authentication mechanisms. Hardcoded credentials, API keys, or tokens embedded in application code or static storage are strictly prohibited.
  • System Use Notification (Consent Banner): During the Keycloak authentication process, users encounter a mandatory U.S. Government System Use Notification banner. Users must explicitly acknowledge this banner before Keycloak grants them access to your application.
  • IdP Approval: P1 SSO is a standard integration. Any other external or customer-managed IdP requires prior formal approval from Second Front to ensure it meets FedRAMP High standards.

Default access behavior and application-level control

Once a user successfully authenticates through Keycloak and your approved IdP, they gain access to the platform. Game Warden does not automatically restrict user access to specific features, data, or views within your application based on their roles or affiliation. By default, any user with a valid session token who knows your application's environment URL can access your application unless you implement explicit restrictions.

To comply with FedRAMP High requirements, you are responsible for implementing robust authorization at the application layer. Parse the Keycloak-provided JSON Web Token (JWT) to build and enforce role-based (RBAC) or attribute-based (ABAC) access controls directly into your application architecture.

Your application must strictly enforce the following FedRAMP requirements:

  • Principle of Least Privilege: Grant users and processes only the minimum permissions necessary to accomplish their assigned tasks. Explicitly prevent non-privileged users from executing privileged functions within your application.
  • Separation of Duties (SoD): Divide critical functions among different individuals or roles. No single user should have the permissions necessary to execute a critical or sensitive process end-to-end without a second approver or checkpoint.
  • Prohibition of Shared Accounts: Every user must be individually authenticated and uniquely identified. Generic, shared, or group application accounts (e.g., a shared "admin" login) are strictly prohibited unless there is a documented, formally justified organizational need that has been approved.
  • Periodic Access Reviews: You must periodically review application-level accounts to validate the continued need for access. Review privileged accounts at least quarterly and non-privileged accounts at least annually.

How JWT authorization works

Game Warden automates OIDC authentication by injecting a signed JWT into the Authorization header as traffic enters the cluster. The Authservice handles this process and replaces any client-provided headers to prevent tampering. Because injection happens at the cluster boundary, the browser-side frontend cannot see the header directly. Implement a /api/whoami endpoint to pass necessary claims to the UI.

Your application is responsible for:

  1. Receiving the JWT via the injected Authorization: Bearer header.
  2. Validating the JWT signature and expiration using a trusted public key. If you prefer the Authservice to handle validation and token expiration, contact your Second Front representative to request this setup.
  3. Extracting claims (e.g., user roles, groups) to build role-based or attribute-based access controls.
  4. Applying authorization logic to control access and ensure users can only reach appropriate views or APIs.
  5. Enforcing session expiration and re-authentication policies.

Best practices for secure access

Because the JWT is injected at the cluster boundary, the frontend does not need to store sensitive tokens in localStorage or sessionStorage. This significantly reduces your application's exposure to Cross-Site Scripting (XSS) attacks.

Follow these access control best practices to protect your application and its users:

  • Hide protected routes and UI elements on the frontend unless the user holds the correct role or claim. Gating navigation improves user experience and reduces accidental exposure.
  • Independently validate the JWT on the backend (critical). Verify the token's signature against Keycloak's public keys to confirm it has not been tampered with after entering the cluster.
  • Enforce claim-based authorization in your business logic. Use JWT fields such as roles, groups, and email to implement fine-grained RBAC or ABAC access control as a second layer of protection beyond what the platform provides.
  • Validate and sanitize all user-submitted data. Platform-level authentication does not protect against application-level vulnerabilities such as SQL injection or XSS.
  • Log application-specific events to supplement Game Warden's platform logs. Track actions such as resource access and internal authorization failures to maintain full traceability.

Game Warden uses Istio in conjunction with Keycloak to apply network-layer authorization policies. This allows you to restrict access to services based on JWT claims such as groups, enabling granular access control that complements your in-application logic.

Application-level monitoring and auditing

Second Front's Security Operations Center (SOC) monitors accounts and atypical activity at the platform and infrastructure layers. You are responsible for auditing your application layer, which includes:

  • Auditing account creation, modification, enabling, disabling, and removal actions.
  • Monitoring internal application accounts for atypical usage.
  • Disabling user accounts within 24 hours when they are no longer required, and ensuring integration with IdP HR termination processes.

Account lockouts and session management

Game Warden enforces strict FedRAMP-mandated lockout and session policies on all users:

  • Unsuccessful Logon Attempts: After three (3) consecutive failed attempts, Keycloak locks the account for 15 minutes or until an administrator releases it.
  • Concurrent Sessions: Game Warden limits concurrent sessions via Keycloak to a maximum of three (3) for privileged access and two (2) for non-privileged access.
  • Inactivity Timeouts: Game Warden enforces session inactivity timeouts per FedRAMP requirements. You are responsible for implementing a session expiration UI (such as a timeout overlay or redirect to login) and ensuring your application triggers a logout when the session expires.

Account reactivation procedures

If a user triggers a lockout or inactivity disablement, they must follow these procedures to regain access:

  • PKI Users (PIV/CAC): Users authenticating with government-issued credentials can typically restore their account automatically by logging in with a valid certificate.
  • Non-PKI Users: Users without a valid certificate must verify via email. After entering their username, Game Warden sends a verification email. Once the user verifies their email, they regain access.

FAQs

How does group and role membership work?

Group and role membership is centrally managed through Keycloak and should be defined during the user onboarding process. To implement Role-Based Access Control (RBAC), your application can parse the JSON Web Token (JWT claims provided by Keycloak upon successful authentication.

Can I use a custom authorization header?

No. The JWT is wrapped in an Authservice session cookie and not directly visible to the browser. Authservice injects the JWT into the Authorization header of requests before forwarding them to your app.

Can I use a custom authorization header?

Yes, you can configure a custom authorization header in your application. However, Game Warden’s system recognizes and processes the default Authorization header automatically. If you use a custom header, it must be managed explicitly in your application’s backend to ensure proper handling of JWTs. Note that Game Warden’s system recognizes the default Authorization header and strips it for security purposes. Custom headers should be managed explicitly in your backend logic.

How does the login flow work?
  1. The user navigates to the application front-end.
  2. The Istio gateway intercepts the request and routes it through Authservice.
  3. If no valid session token is present, Authservice redirects the user to Game Warden Keycloak for authentication.
  4. After successful login, the user is redirected back with an auth code.
  5. Authservice exchanges the code for tokens, sets a session cookie, and Istio forwards the request to your application.
Will the JWT token be visible in the browser or managed by the backend?

No. Game Warden manages these services and configures routing through Istio and Authservice on our side using virtual services.

How do multi-tenant applications work on Game Warden?

Multi-tenancy is handled at the application level. Game Warden does not manage or enforce tenant isolation—application owners are responsible for implementing user segmentation logic based on JWT claims, such as groups.

Does our team need to install Authservice and Istio inside our own boundary?

No. Game Warden entirely manages these services.

What is the expected logout flow?

You can use the Keycloak end_session_endpoint to log users out universally across environments. This value is published at: https://login.fedramp.gamewarden.io/auth/realms/gamewarden/.well-known/openid-configuration.