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 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. Ils 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 sur les API IBM Verify, les politiques d'accès aux applications natives peuvent être appliquées dans le cadre de l'acquisition des jetons de sécurité, 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 à deuxième 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 Les règles de premier contact peuvent décider de refuser l'accès ou de spécifier une liste de méthodes d'authentification à premier facteur autorisées.

Les règles de politique générale sont évaluées une fois l'authentification initiale terminée. Ils 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. Les règles de politique générale peuvent décider d'autoriser l'accès, de le refuser ou d'exiger une authentification de deuxième facteur via un ensemble spécifié de méthodes d'authentification de deuxième 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 Verify introduit le type de subvention OAuth 2.0 "policyauth". Lorsqu'une demande est faite au point de terminaison IBM Verify OAuth 2.0 token 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 d'extrémité de l'API nécessaires pour compléter l'authentification au 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 à premier facteur

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

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

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

Évaluation des règles politiques

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

Si les règles de politique générale 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 générale déterminent que l'accès doit être autorisé (sans autre authentification), les jetons de sécurité et/ou d'identité demandés lors de la requête initiale au point de terminaison des jetons sont renvoyés à l'appelant. L'authentification est terminée.

Si les règles de politique générale déterminent qu'une authentification supplémentaire est nécessaire, une liste des facteurs autorisés est renvoyée à l'appelant, accompagnée d'un nouveau jeton d'accès provisoire. Ce jeton d'accès est associé à l'utilisateur qui a complété l'authentification à premier facteur, mais il 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 à deuxième facteur

L'authentification à deuxième facteur s'effectue normalement en utilisant le jeton d'accès renvoyé par le flux JWT Bearer. À l'issue de l'authentification à deuxième facteur, le client de l'API reçoit un autre jeton Web JSON (JWT) qui contient l'identité de l'utilisateur authentifié et les méthodes d'authentification à premier et à deuxième facteur.

Ce JWT doit ensuite être utilisé dans un autre flux d'octroi de 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. La subvention OAuth 2.0 est mise à jour pour refléter les mécanismes d'authentification de premier et de second facteur. L'authentification est terminée.

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

jon Harry, IBM Sécurité