Stratégie d'accès pour les types d'octroi d'API

Lorqu'une stratégie d'accès est appliquée, il convient de répondre à ces besoins métier fondamentaux :

• L'utilisateur s'est-il suffisamment authentifié pour accéder à cette application ?
• L'utilisateur authentifié est-il autorisé à accéder à cette application ?
• L'appareil ou le contexte client utilisé pour accéder à cette application est-il autorisé ?

Ces conditions requises sont appliquées dans les flux de navigateur classiques. Sinon, le navigateur demande une authentification multi-facteur ou renvoie une page d'erreur à l'utilisateur, ce qui interrompt l'accès. Dans un type d'octroi d'API, ces facultés ne sont pas toutes disponibles. Les problèmes suivants doivent donc être traités.

• Réception d'un contexte à partir d'un appareil client.
• Renvoi d'une demande d'authentification multi-facteur, incluant
  • Les API nécessaires à l'exécution de l'authentification multi-facteur.
  • Le mode d'accès aux API.

Type d'octroi policyauth

Pour appliquer efficacement une stratégie d'accès à un flux d'API OAuth 2.0 uniquement, un nouveau type d'octroi est introduit. Ce type d'octroi permet à un client de présenter un contexte à la stratégie d'accès avant toute authentification. Cette possibilité permet d'implémenter une expérience utilisateur améliorée. Par exemple, lorsqu'un utilisateur appuie sur un bouton de connexion, avant d'être invité à saisir des données d'identification, il est évalué en fonction de la stratégie associée. S'il ne répond pas aux exigences de la stratégie, l'utilisateur reçoit un message d'erreur indiquant qu'il ne peut pas s'authentifier ou accéder à la ressource en raison des exigences de la stratégie.

Réponses à la demande d'authentification de /token

Lorsqu'une stratégie d'accès est appliquée à un flux d'API OAuth 2.0, une demande d'authentification multi-facteur doit faire partie du contrat d'API. Les méthodes classiques de l'opérateur effectuant les étapes d'authentification multi-facteur dans le cadre de la demande adressée à /authorize ne sont pas possibles.

Lorsqu'une demande d'authentification multi-facteur est renvoyée par /token,

• La portée est mfa_challenge et aucune autre portée n'est renvoyée.
• Un jeton d'accès est émis.
  • Le jeton d'accès est autorisé à accéder aux API d'authentification nécessaires. Il est important d'utiliser ce jeton d'accès et non un jeton d'accès client API standard. Ce jeton est utilisé pour suivre les facteurs d'authentification déjà exécutés et les actions passées dans l'octroi.
  • Le jeton d'accès renvoie active: true à partir des demandes adressées à /introspect. Toute API chargée de protéger un serveur de ressources doit, lorsque des défis d'authentification multifactorielle (MFA) sont utilisés, vérifier que la valeur scope renvoyée par /introspect n'est pas égale à mfa_challenge.
• Un tableau de facteurs pouvant être exécutés pour répondre à cette demande allowedFactors est éventuellement répertorié.

Présentation du contexte à /token

Le client API qui effectue une demande auprès de /token peut présenter des informations contextuelles bien définies et arbitraires à /token pour les utiliser dans l'évaluation de la stratégie d'accès.

Trois informations contextuelles obligatoires doivent être incluses.

• sessionId - Identificateur de session arbitraire qui est émis et conservé par le client OAuth.
• ipAddress - Etant donné que le client OAuth est responsable des interactions avec l'agent utilisateur, l'adresse IP de l'utilisateur doit être explicitement fournie.
• userAgent - Tout comme l'adresse IP, l'agent utilisateur doit être explicitement fourni.

D'autres paramètres peuvent être inclus et des conditions d'attribut de contexte peuvent être créées sur ces valeurs.

Le contexte est fourni à /token sous la forme d'un fichier JSON codé en base64. Exemple de contenu JSON pour le contexte :

{
    "sessionId":"MDNjZmQ3NDM2NjFmMDc5NzVmYTJmMT",
    "ipAddress":"129.42.38.10",
    "userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36"
}

Les informations contextuelles sont considérées comme dignes de confiance, car elles sont présentées par un client API qui a émis un ensemble sécurisé de données d'identification client. Ce client API doit s'assurer qu'il ne permette pas que le contexte soit présenté de manière arbitraire par l'agent utilisateur consommateur, qui peut ensuite être utilisé pour contourner les contrôles métier.

Le contexte doit être fourni chaque fois qu'une politique d'accès est invoquée pour tous les types d'autorisation API, policyAuth, JWT Bearer, ROPC et refresh token.

Satisfaction d'une demande d'authentification multi-facteur

Pour satisfaire une demande d'authentification multi-facteur renvoyée par le noeud final /token, vous pouvez utiliser les API des facteurs d'authentification. Ces API sont utilisées pour satisfaire à la fois les exigences du premier et du deuxième facteurs. Le jeton d'accès renvoyé dans la réponse mfa_challenge est utilisé pour demander le facteur approprié. Une fois la réussite du facteur terminée, un jeton Web JSON (JWT) est renvoyé. Ce JWT contient quelques informations importantes.

• L'ID grant_id dérivé du jeton d'accès qui a été utilisé pour demander l'API de facteur. Cet ID gère la corrélation entre les différentes demandes adressées à /token.
• Les interventions factor qui ont été réalisées ainsi que les interventions antérieures.

Ce JWT est présenté à /token dans le cadre d'un flux de type d'octroi jwtBearer. La stratégie d'accès est réévaluée et un jeton entièrement autorisé ou une autre demande sont émis.

Application de la stratégie d'accès à différents types d'octroi

Lorsque vous configurez une application, vous pouvez choisir d'appliquer la stratégie d'accès à un type d'octroi spécifique.

Cette configuration contrôle si la stratégie d'accès est évaluée sur une demande en tant que /token en fonction de la valeur du paramètre grant_type. Cette évaluation s'applique indépendamment des appels précédents de /token pour un octroi spécifique.