Stratégie d'accès aux API

La stratégie d’accès aux API contrôle l’accès aux ressources d’API. Il est parfois nécessaire qu’un titre autorise ou refuse certaines API depuis le client du jeu, à des fins de lutte contre la triche ou pour d’autres raisons de sécurité. Vous pouvez contrôler l’accès à l’aide d’instructions de stratégie qui spécifient un ensemble de règles d’accès appliquées dans des situations spécifiques. Cette rubrique explique comment utiliser les stratégies d’autorisation d’API pour créer les règles appropriées. Vous pouvez également gérer la stratégie d’accès aux API de votre titre directement dans Game Manager. Pour plus d’informations, consultez Stratégie d’accès aux API dans Game Manager.

Ce guide présente des techniques avancées. Si elle est mal appliquée, cette fonctionnalité peut désactiver complètement l’accès client à votre titre.

Contrôle et structure des stratégies

Les titres utilisent les appels de l’API Admin de PlayFab pour récupérer et mettre à jour les stratégies d’accès. Les deux appels spécifiques que vous utilisez pour définir la stratégie d’accès aux API sont GetPolicy et UpdatePolicy. Pour plus d’informations sur les appels de l’API Admin, consultez Référence de l’API PlayFab. Pour utiliser l’API Admin, vous devez fournir la clé secrète de développeur associée à votre titre. La clé de développeur sert à autoriser votre titre à effectuer des appels de l’API Admin. Pour plus d’informations sur la récupération de votre clé secrète, consultez Gestion des clés secrètes. Chaque stratégie contient une liste d’instructions, qui agissent comme des règles pour une ou plusieurs ressources PlayFab. PlayFab définit un ensemble par défaut d’instructions de stratégie qui autorise toutes les stratégies. Si vous supprimez cet ensemble d’instructions de stratégie sans le remplacer, votre titre ne pourra plus appeler les API Client. Les instructions de stratégie PlayFab par défaut :

    "Statements": [
        {
            "Resource": "pfrn:api--*",
            "Action": "*",
            "Effect": "Allow",
            "Principal": "*",
            "Comment": "The default allow all policy"
        }
    ]

Chaque ensemble d’instructions d’autorisation se compose des éléments suivants, tels que définis dans Authentication - Update Policy :

Resource : chaîne qui identifie de manière unique une ou plusieurs ressources PlayFab. Pour décrire la ressource d’API, utilisez la convention indiquée ci-dessous. pfrn:api--/API-GROUP/API-CALL Spécifiez l’API Client comme API-GROUP : Client, Server ou Admin. Remplacez API-CALL par un nom d’API tel que ConfirmPurchase, LoginWithTwitch ou ReportPlayer. Une chaîne de ressource prend en charge les caractères génériques. La chaîne de ressource suivante correspond à n’importe quelle ressource. pfrn:api--*
Action : chaîne qui décrit une opération à effectuer sur la ressource. Utilisez * pour correspondre à n’importe quelle opération.
Effect : chaîne qui spécifie une définition de règle. Utilisez Allow ou Deny pour autoriser ou refuser les opérations sur la ressource.
Principal : chaîne qui identifie de manière unique la classe de l’utilisateur. Utilisez * pour correspondre à n’importe quel utilisateur.
Comment : chaîne définie par l’utilisateur qui fournit des informations supplémentaires sur l’instruction de stratégie.
ApiConditions : objet facultatif qui définit des conditions de règle avancées, par exemple le chiffrement et les en-têtes signés.

Vous pouvez définir des règles de sécurité strictes pour votre application en modifiant votre stratégie afin d’utiliser des instructions d’autorisation plus détaillées qui n’autorisent l’accès qu’aux API que vous utilisez dans votre application. L’exemple suivant montre comment restreindre l’appel DeleteCharacterFromUser :

    {
        "Resource": "pfrn:api--/Server/DeleteCharacterFromUser",
        "Action": "",
        "Effect": "Deny",
        "Principal": "",
        "Comment": "Disable server character delete"
    }

Exemple de stratégie d’accès aux API

L’exemple de code suivant illustre les opérations de base sur les stratégies. Le code effectue les actions suivantes :

Récupère et journalise la stratégie existante.
Met à jour la stratégie.
Récupère et journalise à nouveau la stratégie existante.

public void Start() {
    PlayFabSettings.staticSettings.DeveloperSecretKey = "<insert key here>";
    PlayFabSettings.TitleId = "< insert title id here >";
    FetchApiPolicy(UpdateApiPolicy);
}

private void FetchApiPolicy(Action nextAction = null) {
    PlayFabAdminAPI.GetPolicy(new GetPolicyRequest() {
        PolicyName = "ApiPolicy"
    }, result => {
        Debug.Log(result.PolicyName);
        foreach (var statement in result.Statements)
        {
            Debug.Log("Action: "+ statement.Action);
            Debug.Log("Comment: "+ statement.Comment);
            if(statement.ApiConditions != null)
                Debug.Log("ApiCondition.HashSignatureOrEncryption: "+ statement.ApiConditions.HasSignatureOrEncryption);
            Debug.Log("Effect: "+ statement.Effect);
            Debug.Log("Principal: "+statement.Principal);
            Debug.Log("Resource: "+ statement.Resource);
        }

        if (nextAction != null) nextAction();

    },error=>Debug.LogError(error.GenerateErrorReport()));
}

private void UpdateApiPolicy() {
    PlayFabAdminAPI.UpdatePolicy(new UpdatePolicyRequest() {
        PolicyName = "ApiPolicy",
        OverwritePolicy = false, // Append to existing policy. Set to True, to overwrite.
        Statements = new List<PermissionStatement>() {
            new PermissionStatement() {
                Action = "*", // Statement effects Execute action
                ApiConditions = new ApiCondition() {
                    HasSignatureOrEncryption = Conditionals.False // Require no RSA encrypted payload or signed headers
                },
                Comment = "Do not allow clients to confirm purchase",
                Resource = "pfrn:api--/Client/ConfirmPurchase", // Resource name
                Effect = EffectType.Deny, // Do not allow,
                Principal = "*"
            }
        }
    }, result => {
        FetchApiPolicy();
    }, error => Debug.LogError(error.GenerateErrorReport()));
}

L’image ci-dessous montre un exemple de la sortie après la première exécution du code. Comme illustré, la stratégie se compose de plusieurs instructions d’autorisation.

Introduction

Onboarding & Access

Setup & Install

Build Your First Title

Contrôle et structure des stratégies

Exemple de stratégie d’accès aux API

​Contrôle et structure des stratégies

​Exemple de stratégie d’accès aux API

Contrôle et structure des stratégies

Exemple de stratégie d’accès aux API