Last Updated: 1/17/2023, 4:38:38 AM

# IAM Clients

# Overview

An IAM client is defined as an application, such as a game server or website, that requests access to protected platform resources, such as our platform’s microservices. IAM clients allow you to control which resources can be accessed by an application, as opposed to a specific user.

IAM clients implement the OAuth 2.0 framework (opens new window). You may have used other IAM Clients in the past, such as when using your GMail or Facebook account to log in to websites.

IAM clients can be defined under the publisher or game namespace, depending on whether the intended application is specific to one of your games or used by all games on your platform.

# Client Types

There are two client types, as per the OAuth 2.0 Client Type (opens new window) framework:

  • A confidential client requires a combination of Client ID and Client Secret to authorize with the backend. Confidential clients are normally needed in cases where you do not want to log in with a user account (such as a game server), and as a result, will typically have access permissions defined on the client itself. Therefore, confidential clients should only be used in cases where you can control who has access to the client’s ID and secret, to prevent unauthorized users from being able to access your services.
  • A public client does not specify a client secret; only the client ID is needed for authorization. Public clients are best for applications that require a user to log in with their user account. Permissions should generally not be defined for public clients, since the user’s permissions will override the client’s permissions once the user is signed into their account.

# Common IAM Clients

Most projects typically define a few common client archetypes:

  • Game client IAM client for game clients should be configured as public. It should have no permissions assigned, because the permissions will come from the signed-in user.
  • Game server hosted by Armada IAM client for dedicated servers can be configured as public or private. However, you will need to assign permissions to the client if your dedicated servers do not login as a user (the most common case). For an example of permissions that would typically be assigned to a dedicated server IAM client, see the example permissions below.
  • Dedicated Server Uploader IAM client for uploading dedicated server builds. Since access for uploaders is usually tightly controlled, it is best to specify these types of clients as confidential.
  • Launcher IAM clients for the launcher should be configured as public clients. Once the user signs in, that user’s permissions will override the launcher client permissions. But the launcher client will need to be given permissions to access certain services on its own, such as the login service.

# Fields

  • Client ID serves as the unique ID for the client across the system. It is automatically generated when you first create the client.

  • Client Type defines how secure the client’s login tokens will be. You can choose between Public and Confidential types. Refer to the Client Types section to read more about this.

  • Secret serves as the password for confidential clients. You can fill the field manually, or have the system create one for you by clicking the Generate Client Secret button.

    NOTE

    Once the client has been created, you can no longer access the client secret. Make sure you save the secret in a secure place.

  • Client Name serves as the name of the client, and is how this client will be identified in user-facing forms and documents.
  • Namespace defines which namespace this client should be created within. This only affects where the client appears in the Admin Portal, and does not necessarily affect what resources the client can access.
  • Scopes is a mechanism in OAuth 2.0 to limit which resources can be accessed by an IAM Client. You can select a service from the dropdown menu to add it to the IAM client’s scope. After the scopes are validated, then the user/client permission will be checked for additional validation. You can learn more about Scopes by reading the OAuth 2.0 documentation (opens new window).
  • Redirect URI is only used by clients that represent web-based applications (such as a website or Launcher). For web-based clients, the value should be set to the URL that the user will be redirected to upon successful login. Since this field is required for all clients, you can input the default value of http://127.0.0.1 for non web-based clients, such as game servers, game clients, or server uploaders.
  • Target Audience is used to constrain which service endpoints the client is allowed to access. When given a value, it serves as a white list to allow backend services to quickly reject connection attempts before client or user permissions are checked. When a client attempts to access a service endpoint, the service first checks the client’s Target Audience list. The connection attempt will be rejected if the service’s URI does not match the Base URI of any of the clients listed in the Target Audience field (unless the field is empty). If the client passes the Target Audience check,or if the client’s Target Audience field is empty, the service will proceed to the next step in authenticating the client’s request, such as checking its permissions and scopes.
    The Target Audience dropdown contains a list of clients from the namespace that the client is defined in, along with the Base URI value specified by that client.
  • Base URI is only needed for clients that are used by services, and should be set to the URI of the service itself. For clients that are not intended to be used to allow a service to access the rest of the platform, the value should be left empty.
  • Description is used to give a clear description of the IAM Client.
  • Platform defines which third-party platforms the SDK client runs on. This field is optional. If you choose not to bind to any third-party platform, input None.
  • Advanced Configuration
    • Two-Factor Authentication is used to toggle the activation status of two-factor authentication (2FA) for the client.
    • Override Expiration Time is used to override the default Access Token Expiration Times and Refresh Token Expiration Times. You can use this field to change the expiration times to better suit your game’s play style or for testing purposes.

# Prerequisites

Permissions are used to grant access to specific resources within our services. Make sure your account has the following permissions before you attempt to manage IAM clients in the Admin Portal. For a full list of permissions that impact IAM client management, see the IAM tab of the permissions reference.

Usage Permissions Action
Create a Client ADMIN:NAMESPACE:{namespace}:CLIENT Create
Retrieve Client ADMIN:NAMESPACE:{namespace}:CLIENT Update
Update Client ADMIN:NAMESPACE:{namespace}:CLIENT Update
Update Client Permission ADMIN:NAMESPACE:{namespace}:CLIENT Update
Add Client Permission ADMIN:NAMESPACE:{namespace}:CLIENT Update
Delete Client Permission ADMIN:NAMESPACE:{namespace}:CLIENT Update

Permissions work slightly differently depending on whether they are assigned to IAM Clients or are roles (opens new window) assigned to users. For more information, read the Authentication and Authorization (opens new window) documentation.

# Manage Clients in the Admin Portal

# Create a Client

  1. In the Admin Portal, go to the Platform Configuration section and click the IAM Clients menu.

    iam-clients

  2. On the IAM Clients page, make sure that you are in the right namespace. Then, click Create New and fill out the appropriate fields (see the Fields section above for more information).

    iam-clients

  3. Once completed, click Create. The new IAM Client will be created.

# Add Permissions to a Client

After you create a client, you can add permissions to the client by following the steps below.

  1. In the Admin Portal, go to the Platform Configuration section and click the IAM Clients menu.

    iam-clients

  2. Click View next to the client to which you want to add permissions.

    iam-clients

  3. On the Client Details page, switch to the Permissions tab.

    iam-clients

  4. Click the Add button to add a new permission to the client.

    iam-clients

  5. Fill in the required fields:

    iam-clients

    Here’s a list of permissions required or frequently used by each common client type:

    Dedicated Server Client (Mandatory)
    Permission Action
    ADMIN:DSM READ
    NAMESPACE:{namespace}:DSM:SERVER UPDATE
    Dedicated Server Client (Optional)

    You should give these permissions to a dedicated server client depending on the services you are using. See the permissions reference (opens new window) for more information about what these permissions do.

    Permission Action
    ADMIN:NAMESPACE:{namespace}:ENTITLEMENT READ
    ADMIN:NAMESPACE:{namespace}:PARTY:STORAGE READ, UPDATE
    ADMIN:NAMESPACE:{namespace}:STATITEM UPDATE
    ADMIN:NAMESPACE:{namespace}:USER:*:ACHIEVEMENT UPDATE
    ADMIN:NAMESPACE:{namespace}:USER:*:CLOUDSAVE:RECORD CREATE, READ, UPDATE, DELETE
    ADMIN:NAMESPACE:{namespace}:USER:*:ENTITLEMENT READ
    ADMIN:NAMESPACE:{namespace}:USER:*:PUBLIC:CLOUDSAVE:RECORD CREATE, READ, UPDATE
    ADMIN:NAMESPACE:{namespace}:USER:*:STATITEM CREATE, READ, UPDATE
    ADMIN:NAMESPACE:{namespace}:USER:*:WALLET UPDATE
    NAMESPACE:{namespace}:SESSION CREATE, READ, UPDATE
    ADMIN:NAMESPACE:{namespace}:MATCHMAKING:CHANNEL CREATE, DELETE
    Dedicated Server Uploader Client (Mandatory)
    Permission Action
    NAMESPACE:{namespace}:DSUS:CONFIG CREATE
    NAMESPACE:{namespace}:DSUS:IMAGE CREATE
    NAMESPACE:{namespace}:DSUS:IMAGE READ
    NAMESPACE:{namespace}:DSM:SERVER CREATE, UPDATE
    NAMESPACE:(namespace):DSM:CONFIG READ

    Once completed, the permission appears in the client permission list.

    iam-clients

# Manage Clients using the Client SDKs

# Log In with Client Credentials

This code is used to generate an IAM token using IAM Client credentials if the game server needs to do an S2S call to the Backend services.