Kit de développement de logiciels adaptatif

Introduction

IBM Verify L'accès adaptatif peut être utilisé pour protéger les applications web développées de manière native (c'est-à-dire lorsque l'expérience complète de l'utilisateur est gérée par l'application). Grâce à l'accès adaptatif, vous pouvez rapidement sécuriser votre application native contre les attaquants, en introduisant le MFA si nécessaire, sans augmenter la friction pour la majorité de vos utilisateurs.

*Si votre application web ou mobile prend en charge l'authentification unique fédérée OIDC ou SAML, consultez la section Accès adaptatif pour l' Single Sign On.

Dans ce flux, le contexte d'accès adaptatif, les capacités de collecte des risques et l'ensemble de l'expérience d'authentification sont réalisés par votre application à l'aide de IBM Verify AdaptiveSDK. Ce cas de figure est le plus fréquent lorsque l'application est utilisée indépendamment d'un point d'authentification commun ( IdP ). Cela peut s'avérer essentiel dans les cas d'utilisation du CIAM, ou pour les applications de base sur mesure qui nécessitent une expérience utilisateur hautement personnalisée.

Pour commencer, voir On-boarding a native application.

Comprenons les différentes entités impliquées dans le déploiement d'une application native. Il y en a trois à connaître :

• IBM Verify
• Le serveur d'application
• L'application client

Chacun d'entre eux joue un rôle spécifique dans la mise en œuvre de l'accès adaptatif pour les applications natives. Le diagramme suivant montre la relation entre les entités.

Composants

IBM Verify

IBM Verify est le moteur qui fournit la capacité d'accès adaptatif qui est construite sur les principes standards OAuth 2.0 / OpenID Connect.

Lors du déploiement d'une application native, le serveur d'application contactera IBM Verify afin d'obtenir un jeton d'accès à utiliser par l'application. Ce jeton d'accès ne sera délivré qu'une fois que toutes les exigences de la politique configurées sur l'application seront satisfaites, ce qui peut nécessiter une authentification à plusieurs facteurs sur la base de l'évaluation des risques fournie par la capacité d'accès adaptative.

Dans ce scénario, l'interaction avec IBM Verify est purement basée sur l'API, le développeur intégrant son serveur d'application avec les API fournies pour enrichir ses capacités d'authentification.

Pour plus d'informations sur l'appel aux API de IBM Verify pour évaluer les politiques, voir les rubriques du centre de connaissances.

Le serveur d'application

Dans ce scénario, le serveur d'application héberge la logique de l'application que l'utilisateur final essaie d'utiliser. Ce scénario permet au serveur d'application de se décharger de nombreuses exigences d'authentification traditionnelles sur IBM Verify, au lieu de consommer l'API basée sur les normes mentionnée. Ces API permettent à l'application d'établir une session utilisateur et de demander une authentification supplémentaire. En utilisant les API de IBM Verify, l'application n'a plus besoin de gérer :

Un répertoire d'utilisateurs

• IBM Verify Cloud Directory est utilisé comme magasin de sauvegarde

Audit des événements de connexion

• Les documents d'authentification sont fournis par les rapports IBM Verify

Mise en œuvre de méthodes multifactorielles

• Il existe des API prêtes à l'emploi pour réaliser des scénarios d'authentification de base et avancés, tels que le mot de passe à usage unique par courrier électronique ou l'authentification moderne et sans friction FIDO2*

Lors du déploiement d'une application utilisant cette API pour l'authentification adaptative, le SDK Adaptive Proxy peut être utilisé pour simplifier et rationaliser l'intégration avec les API IBM Verify. Il est également disponible pour être inclus dans les projets NodeJS via npm.

L'application client

L'application client a établi une session avec son serveur d'application et c'est cette session qui est protégée et enrichie à l'aide de IBM Verify Adaptive access. Pour ce faire, le SDK adaptatif doit être déployé dans l'application client.

Le SDK du navigateur adaptatif facilite la gestion des sessions et s'intègre aux flux de connexion et d'authentification de l'application. Il est également disponible pour être inclus dans les projets NodeJS via npm.

Comprendre l'architecture

Ce qui précède nous aide à comprendre les différentes entités au sein d'un déploiement de IBM Verify Adaptive access pour les applications natives. Répétons-le :

1. L'application native qui interagit avec l'utilisateur
   • Embarque le SDK du navigateur adaptatif
   • Souhaite appeler les API à l'aide de access_token, soit à partir de l'application, soit à l'aide d'une session du serveur d'application
     • Ce jeton d'accès est validé par le serveur de ressources à l'aide de l'introspection de jeton OAuth
   • N'appelle pas directement IBM Verify
2. Le serveur d'application avec lequel l'application fonctionne
   • Est-ce le client OIDC qui est enregistré auprès d' IBM Verify
     • Il est délivré à client_id et client_secret
   • Héberge l'application utilisée par l'utilisateur final
   • Appelle l'API IBM Verify pour obtenir un jeton d'accès à utiliser par l'application native
   • Héberge des API sécurisées par l'utilisation de jetons OAuth 2.0
     • Le point final d'introspection du jeton IBM Verify est utilisé pour prendre des décisions en matière d'autorisation.
3. IBM Verify
   • Fournit des capacités d'authentification, d'autorisation, de MFA et d'audit à l'aide d'une API normalisée.
   • Utilisé pour embarquer l'application
     • Émet un client_id et client_secret
   • Délivre des jetons d'accès et de rafraîchissement au serveur d'application
   • C'est là que la politique d'accès est élaborée