Skip to content

Access Control

Game Warden authenticates users via Keycloak. However, we do not control nor do we provision users of your application. You can parse the provided JWT to identify users with unique fields and configure your application logic to associate them with necessary permissions and or groups needed to interact within your application.

FAQ: What is Keycloak?

Keycloak is the Identity and Access Management (IAM) solution that we employ to authorize users to reach the Game Warden App and Game Warden-hosted applications. It integrates with the Platform One Single Sign-on (P1 SSO) such that you only need one set of credentials for secure access.

FAQ: Do I need to set up a Keycloak account?

By performing the steps of the New User Account article, you automatically establish your own Keycloak account.

Application Access

By default, anyone who has your application’s endpoint - be it in the Development (DEV), Staging (STG), or Production (PRD) environments - will have access. Some caveats to keep in mind:

  • All users (developers and end-users) must establish a P1 SSO account to access Game Warden-hosted applications - and -
  • If an application is hosted at Impact Level (IL) 4 or higher, the end user must possess a Government Access Card with the appropriate permissions* to access that impact level.
    • These permissions are dictated by the end-user’s DoD command.
  • Users with .gov or .mil email addresses automatically have access to IL2, IL4, and IL5 environments when they use their Government Access Cards

JWT Authorization

FAQ: What is a JSON Web Token?

JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. For more information, see here.

When users browse to the application within the Kubernetes cluster, they are prompted to authenticate. Authservice orchestrates this process, directing users to Keycloak for login. Upon successful authentication, Keycloak generates a JSON Web Token (JWT) encapsulating user claims. As users interact with the application, every request is intercepted by Istio's Envoy proxies. Authservice, seamlessly integrated with Istio, intercepts these requests and injects the JWT into the authorization header. This JWT acts as a secure bearer token, accompanying each request to the application. By utilizing this approach, the system ensures a continuous, secure session, enabling the application to verify user identity and permissions for seamless and protected interactions within the Kubernetes environment.

Example

Example: the client (browser/user) sends a username and password along with profile information gathered by Authservice to the server which, in turn, creates a JWT and assigns a secret only known to the JWT. At this point, the JWT contains user profile information, login credentials, and a secret. The server sends the JWT to the client. The client returns the JWT to the server. The server verifies that the JWT has not been altered, signaling that the user requesting application access is the same user who provided login credentials. If valid, the server grants application access. Since JWT stores all user information on the client, the user has application access.

A JWT has three parts, each comprising specific data:

  • Header – The header includes the token type, JWT, for example. It also includes the algorithm in use, such as “alg”: “HS256” (which works in conjunction with the Signature to verify users and is used to encode/decode data), and a token expiration date.

  • Payload – Includes user information and any designated groups/roles. For example, the payload will include the sub or subject, such as the user ID. It also will include the username.

  • Signature – Reviews header and payload data before it is returned to the server to ensure the client has not altered this data. Verifies the JWT sender (user) and, if valid, grants application access.

JWT authorization exists for each user request. Application teams might leverage this tool solely for authentication. They also might manage authorization internally relative to application code, if they require role or group-based authentication.

Example

Example: you can store users’ roles/groups in the application database and use the authenticated ID of users in the JWT to compare to those groups using the application code.

You must manage your application user roles and permissions.

The Process

When integrating your applications with Game Warden, two primary actions occur:

  • Authentication (AuthN)
    • Keycloak authenticates user requests.
  • Authorization (AuthZ)
    • Keycloak determines the level of access a user should receive.
    • If a user registers with a DoD-supported Public Key Infrastructure (PKI) method (using a Government Access Card), our Keycloak SSO automatically assigns the appropriate Impact Level groups and roles from Platform One.

After the Authservice validates a request, it sets the Authorization: Bearer header (which contains JWT authentication) in the request that it passes into the application code. This data is in JWT format, can be parsed with any JWT library, and contains the user's Keycloak profile.

Due to this process any pre-existing Authorization header will be stripped and replaced with the aforementioned JWT (JSON Web Token).

Developers can identify data within encoded and decoded JWTs by viewing each of its three parts: Header, Payload, and Signature.

Sample Decoded JWT with Payload Data decoded

Sample Encoded JWT - An encoded JWT displays the Header, Payload, and Signature. A period separates each. encoded

See below for a visual representation of our authservice flow:

Authorization Policies

Game Warden uses Istio in concert with Keycloak to employ authorization policies. Customer configured, customized Authorization Policies can be used to limit access to endpoints using Gamewarden’s keycloak groups, giving you options for granular access control.

  • For example, an authorization policy could limit access to your developers in a DEV environment or you could permit only Airforce users to access your endpoint.

After you draft your policy, provide it to your Customer Ops representative and we will apply it to your cluster.

Example Policy 
# This policy ensures that Identities without this string  
# "/Customers/<customer_name>/<some group>" in their JWTs 
# group claim are not allowed to reach pods and services 
# labeled with "app.kubernetes.io/name": foo  

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "pgadmin-allow-mmt-developer-group"
  namespace: "mmt"
spec:
  selector:
    matchLabels:
      "app.kubernetes.io/name": foo
  action: DENY
  rules:
  - to:
    - operation:
        hosts: [foo.il2.afwerx.dso.mil"]
    when:
    - key: request.auth.claims[groups]
      notValues: ["/Customers/<customer_name>/<some group>"]


# Auth Pols are granular and flexible in nature instead 
# of blocking for a whole host you could just block for a path 
# instead by changing the rule object to some like this
- to:
  - operation:
      paths: ["/admin"]
  when:
  - key: request.auth.claims[groups]
    notValues: ["/Customers/<customer_name>/admins"]

# This would have the effect of only allowing users with the admin group 
# in the claim from being able to hit the admin endpoints within the application

Reach out to your Customer Operations representative or submit a Support Ticket for any questions you may have.

Account Time-out

Users who are not actively accessing Game Warden resources (and authenticating via Keycloak) will be deactivated after 30 days of inactivity.

Deactivated users will be sent an email notification:

Clicking the Login button will take the user to a page asking for their username. For users logging in with a DoD PKI, their account is restored.

For users without a DoD PKI, after entering their username, a verification email is sent. After the user verifies via email, their account is restored.

Note

If you end user missed the email, they can click on this link to start the account re-enablement process.

FAQ

  • How does a customer of Game Warden add groups or roles? This is controlled by your application as described above in conjunction with the parsing of the JWT created upon user login.
  • How and when does a web application session timeout? The Keycloak configuration for user session timeouts is set to 4 hours.
  • How does multi-tenant applications work on Game Warden? This is an application control and is not configured by Game Warden employees. To take advantage of user segriagation the recommendation is to implement user controls within your application.
  • Can I use a custom authorization header? Yes, you can configure a custom authorization header to be used in your application however using the default Authorization will be interpreted by the system and stripped as described above.

Last updated: 02/16/24

Return to Help Center Home