Authentification basée sur une politique

Introduction

Lors de la création d'applications grand public, les équipes de conception et les développeurs souhaitent généralement avoir un contrôle total sur l'expérience de l'utilisateur. Cela peut entrer en conflit avec la nécessité d'appliquer de manière centralisée les étapes d'authentification requises pour l'accès aux applications.

IBM Security Verify permet de définir des politiques d'accès qui contrôlent les étapes d'authentification requises pour l'accès aux applications. Les politiques d'accès peuvent spécifier différentes exigences d'authentification en fonction des propriétés de l'utilisateur ou de la connexion. Elles peuvent même être dynamiques, grâce aux capacités avancées de détermination des risques d'Adaptive Access.

Pour les applications qui effectuent une authentification native directement contre les API IBM Security Verify, les politiques d'accès aux applications natives peuvent être appliquées dans le cadre de l'acquisition des jetons de sécurité, en guidant le développeur à travers les étapes d'authentification requises tout en lui permettant de contrôler totalement l'expérience de l'utilisateur.

Politiques d'accès aux applications natives

Une politique d'accès aux applications natives comporte deux parties. La première partie spécifie les règles de premier contact qui contrôlent l'authentification initiale du premier facteur. La deuxième partie spécifie les règles de politique qui contrôlent l'authentification de second facteur.

Les règles de premier contact sont évaluées avant l'authentification et le contexte disponible est donc limité. Les règles de premier contact peuvent être basées sur la géolocalisation (dérivée de l'adresse IP du client) ou sur le type de client OAuth 2.0. La décision des règles de premier contact peut être soit de refuser l'accès soit de spécifier une liste de méthodes d'authentification de premier facteur autorisées.

Les règles de politique sont évaluées une fois l'authentification initiale terminée. Elles ont donc accès à un contexte beaucoup plus riche qui comprend des informations sur l'utilisateur et, éventuellement, des résultats d'accès adaptatifs. La décision des règles de politique peut être soit d'autoriser l'accès, de refuser l'accès, ou d'exiger une authentification de second facteur via un ensemble spécifié de méthodes d'authentification de second facteur.

Le type de subvention "policyauth"

Pour permettre l'application de politiques d'accès aux applications natives dans le cadre de l'acquisition du jeton OAuth 2.0, IBM Security Verify introduit le type de subvention OAuth 2.0 personnalisé "policyauth". Lorsqu'une demande est adressée au point de terminaison du jeton IBM Security Verify OAuth 2.0 avec ce type de subvention, les règles de premier contact de la politique sont évaluées.

Si les règles de premier contact déterminent que l'accès doit être refusé, une réponse de refus est renvoyée à l'appelant.

Si les règles de premier contact déterminent que l'accès doit être autorisé, une liste des facteurs autorisés est renvoyée à l'appelant, accompagnée d'un jeton d'accès dont la portée spéciale est mfa_challenge. Ce jeton d'accès peut être utilisé pour accéder uniquement aux points de terminaison de l'API nécessaires pour compléter l'authentification de premier facteur.

{
    "access_token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "allowedFactors": [
        "password"
    ],
    "scope": "mfa_challenge",
    "grant_id": "11111111-1111-1111-1111-111111111111",
    "token_type": "Bearer",
    "expires_in": 1800
}

Compléter l'authentification de premier facteur

L'authentification de premier facteur est effectuée normalement en utilisant le jeton d'accès fourni par le flux Policy Auth. À l'issue de l'authentification de premier facteur, le client de l'API reçoit un jeton Web JSON (JWT) qui incarne l'identité de l'utilisateur authentifié et le premier facteur complété.

{
    "assertion": "eyJhbGciOiJSUzI1NiIsI..."
}

Ce JWT doit ensuite être utilisé dans un flux d'octroi JWT Bearer OAuth 2.0 pour lancer l'évaluation des règles de politique dans la politique d'accès.

Évaluation des règles de politique

Lorsque le jeton Web JSON (JWT) reçu du flux d'authentification de premier facteur est présenté au point de terminaison du jeton IBM Security Verify OAuth 2.0, dans le cadre d'un flux d'octroi JWT Bearer, cela déclenche l'évaluation des règles de politique dans la politique d'accès de l'application native.

Si les règles de politique déterminent que l'accès doit être refusé, une réponse de refus est renvoyée à l'appelant.

Si les règles de politique déterminent que l'accès doit être autorisé (sans authentification supplémentaire requise), les jetons de sécurité et/ou d'identité demandés dans la demande initiale au point de terminaison du jeton sont renvoyés à l'appelant. L'authentification est terminée.

Si les règles de politique déterminent qu'une authentification supplémentaire est requise, une liste des facteurs autorisés est renvoyée à l'appelant, accompagnée d'un nouveau jeton d'accès intérimaire. Ce jeton d'accès est associé à l'utilisateur qui a terminé l'authentification de premier facteur mais a une portée spéciale de mfa_challenge qui limite ses permissions.

{
    "access_token": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
    "allowedFactors": [
        "emailotp",
        "totp",
        "signatures"
    ],
    "scope": "mfa_challenge",
    "grant_id": "11111111-1111-1111-1111-111111111111",
    "token_type": "Bearer",
    "expires_in": 1800
}

Compléter l'authentification de second facteur

L'authentification de second facteur est effectuée normalement en utilisant le jeton d'accès renvoyé par le flux JWT Bearer. À l'issue de l'authentification de second facteur, le client de l'API reçoit un autre jeton Web JSON (JWT) qui incarne l'identité de l'utilisateur authentifié et les méthodes d'authentification de premier et de second facteur complétées.

Ce JWT doit alors être utilisé dans un autre flux d'octroi JWT Bearer OAuth 2.0 pour recevoir les jetons de sécurité et/ou d'identité demandés dans la demande initiale au point de terminaison du jeton. L'octroi OAuth 2.0 est mis à jour pour refléter les mécanismes d'authentification de premier et de second facteur complétés. L'authentification est terminée.

{
    "access_token": "zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz",
    "grant_id": "11111111-1111-1111-1111-111111111111",
    "token_type": "Bearer",
    "expires_in": 7200
}

💎

Jon Harry, IBM Security