Intégration des webhooks de notification avec des applications personnalisées
Réception et traitement des signalements de fraude liés à l'authentification multifactorielle (MFA) provenant de l'application mobile d'authentification IBM Verify
Cet article vous guidera tout au long de la configuration d'un webhook de notification conçu pour détecter les événements frauduleux liés à l'authentification multifactorielle (MFA) et déclencher une application personnalisée en réponse. Ces événements sont générés lorsqu'un utilisateur final signale une demande d'authentification multifactorielle (MFA) comme frauduleuse dans l'application mobile IBM Verify.
À la fin de cet article, un webhook de notification aura été configuré pour déclencher une application personnalisée qui effectuera les actions suivantes :
- Révoquer toutes les sessions d'authentification actives de l'utilisateur cible
- Lancer la procédure de réinitialisation du mot de passe de l'utilisateur
- Informer l'utilisateur par e-mail des mesures prises
AttentionLes mesures décrites dans cet article concernant le traitement des événements ont été choisies afin d'illustrer quelques-unes des possibilités existantes pour répondre aux signalements de fraude liés à l'authentification multifactorielle (MFA); elles ne constituent en aucun cas des recommandations quant à la manière dont ces événements devraient être gérés d'un point de vue sécuritaire. Dans un environnement de production, il peut arriver que des utilisateurs signalent par erreur une demande d'authentification multifactorielle (MFA) comme frauduleuse alors qu'elle était en réalité légitime.
Prérequis
Attentes et exigences relatives au scénario documenté :
- Le lecteur dispose d'un accès administrateur à l'instance d' IBM Verify, sur laquelle le webhook de notification sera configuré.
- Le type de facteur Authentification IBM Verify est activé dans l'interface utilisateur d'administration. (Authentification -> Facteurs d'authentification -> [✔️] Authentification IBM Verify)
- Le lecteur dispose des droits d'accès nécessaires pour configurer et héberger une application accessible sur Internet via l'adresse IBM Verify.
- Le lecteur maîtrise le processus de configuration d'applications personnalisées à l'aide d' express.js.
- Le lecteur est capable de configurer des clients API sur IBM Verify et maîtrise les mécanismes d'authentification basés sur les API lors de l'intégration de ces derniers ( Créer un client API ).
Termes utilisés dans l'article
- IBM Verify application mobile: l'application mobile d'authentification multifactorielle IBM Verify pour l' iOS et Android. ( Guide de l'utilisateur de IBM Verify )
- Interface utilisateur d'administration: l'interface utilisateur d'administration Web de l'instance d' IBM Verify.
- Client API: application cliente enregistrée sur IBM Verify et permettant d'interagir par programmation avec les API de IBM Verify.
Comprendre les signalements frauduleux liés à l'authentification multifactorielle (MFA)
Un signalement frauduleux d'authentification multifactorielle (MFA) est un type d'incident de sécurité qui se produit lorsqu'un utilisateur signale une notification de demande d'authentification multifactorielle comme suspecte ou frauduleuse via l'application mobile IBM Verify. La possibilité de signaler une tentative d'authentification multifactorielle (MFA) comme frauduleuse s'offre à l'utilisateur après le refus d'une demande d'authentification, sous la forme d'un bouton Signaler comme suspect situé à côté de l'option J'ai changé d'avis. Lorsque l'utilisateur sélectionne l'option Marquer comme suspect, la tentative d'authentification à plusieurs facteurs (MFA) est refusée, marquée comme frauduleuse, et l'accès au flux d'authentification à l'origine de cette tentative est refusé. Lors de la consultation du rapport d'activité MFA dans l'interface utilisateur d'administration, les demandes qui ont été refusées de cette manière seront signalées par un Result de Failure et un Reason de USER_FRAUDULENT.
L'objectif de cet article est d'automatiser la gestion de ces événements sans qu'il soit nécessaire de consulter régulièrement l'interface utilisateur des rapports et sans que l'administrateur ait à intervenir pour y remédier.
Présentation de l'architecture
Vous trouverez ci-dessous une vue d'ensemble de l'architecture et de la manière dont les composants concernés interagiront entre eux. Le schéma d'architecture générale met en évidence, en vert, les éléments configurés dans cet article.
La solution comprendra deux éléments principaux :
- Un webhook de notification configuré pour détecter les événements d'authentification multifactorielle (MFA) ayant échoué générés par le service et, lorsque ceux-ci sont marqués comme
USER_FRAUDULENT, déclencher une application externe chargée de gérer ces événements. - Une application exemple qui recevra les requêtes POST provenant du webhook et effectuera des actions telles que la révocation des sessions utilisateur et le déclenchement de réinitialisations de mot de passe en fonction des informations fournies par l'événement.
Afin de garantir que l'application d'exemple puisse extraire de la requête les informations nécessaires pour effectuer des opérations sur le compte de l'utilisateur, il convient de définir un format de charge utile attendu. Le format d'une requête POST de webhook de notification est le suivant :
{
"correlationid": "CORR_ID-AKdf126121-d8b2-4cfa-a7ea-ad91a5249465",
"data": {
"api_grant_type": "refresh_token",
"cause": "Failed to successfully verify: USER_FRAUDULENT",
"devicetype": "Verify/2 CFNetwork/3860.400.51 Darwin/25.3.0",
"intraservice": "false",
"mfadevice": "iPhone",
"mfamethod": "IBM Verify Push",
"mfaresult": "USER_FRAUDULENT",
"origin": "<IP_ADDRESS>",
"performedby": "3630004RA2",
"performedby_realm": "www.ibm.com",
"performedby_username": "[email protected]",
"realm": "www.ibm.com",
"result": "failure",
"sourcetype": "social",
"subject": "3630004RA2",
"subtype": "mfa",
"targetid": "9dcb2d06-ceb0-49b7-adf7-5b4331478100",
"username": "[email protected]"
},
"day": 25,
"event_type": "authentication",
"geoip": {...},
"id": "b65ec53e-d0af-442e-931c-a967f5894bb3",
"internal": {},
"month": 3,
"servicename": "factors",
"tenantid": "68678f68-55ba-4bfd-b1d6-4791c2853d14",
"tenantname": "example.verify.ibm.com",
"time": 1774414598286,
"year": 2026
}Ces propriétés peuvent toutes être lues par l'application de traitement, et des actions supplémentaires peuvent être entreprises en fonction de leurs valeurs. Dans le cadre de cet exemple, seuls les champs suivants nous intéressent :
data.subjectdata.mfaresultevent_typedata.result
Configuration du webhook de notification
Configurez un webhook de notification qui s'abonne aux USER_FRAUDULENT événements. Cela enverra automatiquement les données JSON de l'événement via une requête POST vers le point de terminaison configuré. Pour plus de détails, consultez la section Création d'un webhook de notification.
- Connectez-vous à l'interface d'administration de votre instance Verify (par exemple : https://example.verify.ibm.com/ui/admin ).
- Accédez à Intégrations -> Webhooks de notification
- Cliquez sur
Create Webhook.
- Donnez un nom au webhook de notification et, si vous le souhaitez, renseignez les coordonnées.
-
Indiquez l' URL publique du point de terminaison externe qui recevra et traitera les événements MFA. L'authentification pour le point de terminaison doit être configurée de manière à garantir que la requête provient d'une source valide. Dans le cas présent, le type d'authentification Header sera utilisé, avec un nom d'en-tête Authorization et une valeur correspondant à un secret partagé entre l'application et le webhook. Une fois que toutes les valeurs de configuration requises pour la première page ont été saisies, cliquez sur le bouton Suivant.
-
Configurez les événements auxquels vous êtes abonné et que le webhook de notification va surveiller en cliquant sur le bouton Ajouter un événement personnalisé + situé vers le bas de la fenêtre contextuelle. Donnez-lui un nom évocateur, par exemple Événements MFA frauduleux, puis, dans la section Centres d'intérêt, configurez le type d'événements qui nous intéresse. Les champs d'événement concernés pour ce webhook sont les suivants :
data.result=failuresurIncludeevent_type=authenticationsurIncludedata.mfaresult=USER_FRAUDULENTsurInclude
Une fois créé et activé, le webhook enverra désormais une requête POST vers le point de terminaison configuré dès qu'un événement d'authentification multifactorielle (MFA) frauduleux se produira sur le tenant. Cette requête devra être interceptée par notre application d'exemple et traitée afin d'exécuter les actions décrites précédemment dans cet article.
Création de l'application REST
L'étape principale de ce flux consiste à créer une application exemple qui recevra et traitera les données JSON envoyées par le webhook de notification, déclenchant ainsi des actions spécifiques en fonction de l'événement.
Dans ce scénario d'exemple, l'application sera créée à l'aide de express.js. Elle disposera d'un seul point de terminaison public qui recevra la charge utile de l'événement MFA et, en fonction des informations contenues, enverra ses propres requêtes à IBM Verify afin d'effectuer des opérations sur le compte de l'utilisateur. Dans le cadre de ce flux de traitement des événements, l'application vérifiera l'authenticité de la requête à l'aide de la valeur de l'en-tête Authorization afin de s'assurer que celle-ci provient bien d'une source autorisée.
Configuration de l'application
Créez un nouveau projet node.js dans un répertoire dédié (dans cet exemple, fraudulent-mfa-app) et installez express.js en tant que dépendance.
npm initCela permettra d'initialiser le projet et de créer un package.json fichier ainsi que notre index.js fichier qui gérera les requêtes. Ce index.js fichier doit être créé manuellement si cela n'a pas été fait via la npm init commande. Pour obtenir de l'aide supplémentaire concernant les applications Node et express.js, reportez-vous à l'exemple Hello World d'introduction à node.js et express.js.
Nous installons ensuite Express en tant que dépendance à l'aide de la commande suivante :
npm install express --saveDans notre index.js fichier, nous allons maintenant définir la structure de base de l'application :
const express = require('express');
const app = express();
// Configuration
const PORT = process.env.PORT || 3000;
const AUTH_SECRET = process.env.AUTH_SECRET || 'your-secret-token-here';
const TENANT_URL = process.env.TENANT_URL || 'https://your-tenant.verify.ibm.com/';
const CLIENT_ID = process.env.CLIENT_ID || '<client ID>';
const CLIENT_SECRET = process.env.CLIENT_SECRET || 'your-client-secret-here';
// Parse JSON bodies
app.use(express.json());
// Function to process fraudulent MFA report
function processFraudulentReport(subject) {
// TODO: Implement actions for fraudulent MFA report
// - Revoke all active authentication sessions
// - Trigger password reset
// - Send notification email
}
// Webhook target endpoint to send notifications to
app.post('/notifications', (req, res) => {
// processing goes here
...
processFraudulentReport(subject);
...
});
// Start server
app.listen(PORT, () => {
console.log(`Server running on port ${PORT}`);
console.log(`Webhook endpoint: http://localhost:${PORT}/notifications`);
});Cette application est désormais configurée pour recevoir des requêtes POST sur ce /notifications point de terminaison.
Traitement du contenu de la notification
Vérifiez que le demandeur dispose des autorisations nécessaires pour appeler l'API. Cette application mettra en œuvre l'autorisation via un secret partagé entre le webhook configuré et cette application. Le webhook enverra la clé secrète dans l'en-tête Authorization ; celle-ci devra être extraite et comparée à la version locale de la clé d'authentification de l'application.
// Webhook endpoint
app.post('/notifications', (req, res) => {
// Check authentication
const authHeader = req.headers['authorization'];
if (!authHeader || authHeader !== AUTH_SECRET) {
return res.status(401).json({ error: 'Unauthorized' });
}
...
});La charge utile peut alors être analysée et les événements MFA peuvent être traités. Express offre un moyen pratique de convertir le corps de la requête en un objet JSON, que nous allons désormais utiliser pour extraire les valeurs du corps de la requête POST. Dans cet exemple, nous n'effectuons aucune opération particulière sur ces valeurs, si ce n'est extraire l'identifiant de l'utilisateur afin de pouvoir révoquer ultérieurement les sessions d'authentification; toutefois, le code est inclus à titre d'illustration.
// Webhook endpoint
app.post('/notifications', async (req, res) => {
// Check authentication
const authHeader = req.headers['authorization'];
if (!authHeader || authHeader !== AUTH_SECRET) {
return res.status(401).json({ error: 'Unauthorized' });
}
const payload = req.body;
const { event_type, data = {}, correlationid } = payload;
const { subject, username, mfaresult, result } = data;
// Validate fraudulent MFA event
if (event_type === 'authentication' &&
result === 'failure' &&
mfaresult === 'USER_FRAUDULENT') {
console.log('FRAUDULENT MFA REPORT:');
console.log(` User: $USERNAME`);
console.log(` Subject: ${subject}`);
console.log(` Correlation ID: ${correlationid}`);
// Process the fraudulent report asynchronously
processFraudulentReport(subject)
.then(() => {
console.log('Fraudulent report processing completed');
})
.catch((error) => {
console.error('Failed to process fraudulent report:', error.message);
});
return res.status(200).json({
message: 'Fraudulent MFA report received and processing',
username
});
}
res.status(200).json({ message: 'Event received but not processed' });
});Maintenant que nous avons reçu et lu la charge utile provenant du webhook, l'application doit effectuer ses propres appels vers les API d' IBM Verify afin de mener à bien des actions administratives. Nous utiliserons l'API native fetch d' Node.js pour effectuer les requêtes API depuis l'application. L'API fetch est intégrée à Node.js, version 18 et plus, et ne nécessite aucune dépendance supplémentaire.
RemarqueCet exemple utilise l'API native
fetchdisponible dans Node.js e 18 et versions ultérieures. Si vous utilisez une ancienne version d' Node.js, pensez à effectuer une mise à jour ou à utiliser lehttpsmodule à la place.
Autorisation de l'application auprès de l'éditeur de logiciels (ISV)
Afin d'autoriser cette application à effectuer des requêtes API sur le compte d'un utilisateur, celle-ci aura besoin des identifiants d'un client API configuré sur l'instance IBM Verify et disposant des autorisations nécessaires pour les API qui seront appelées. Dans le cadre de notre exemple, et afin de permettre les appels vers l'API de réinitialisation du mot de passe et l'API de révocation de session, le client devra être configuré avec les droits suivants :
revokeAllSessionsresetPasswordAnyUser.
L'application obtiendra l'autorisation en fournissant les identifiants de l'API au point de terminaison des jetons ISV, en échange d'un jeton d'accès. Afin de récupérer ce jeton d'accès, nous allons créer une fonction d'aide dans l'application, nommée getAccessToken. Les paramètres CLIENT_ID & CLIENT_SECRET peuvent être obtenus à partir de la page de configuration du client API et doivent être soit configurés en tant que variables d'environnement, soit définis au sein de l'application.
// Function to get access token from IBM Verify
async function getAccessToken() {
try {
const response = await fetch(
`${TENANT_URL}/oauth2/token`,
{
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: new URLSearchParams({
client_id: CLIENT_ID,
client_secret: CLIENT_SECRET,
grant_type: 'client_credentials',
scope: 'openid'
})
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
const data = await response.json();
return data.access_token;
} catch (error) {
console.error('Error getting access token:', error.message);
throw error;
}
}L'application est désormais autorisée à accéder aux API d' IBM Verify nécessitant les revokeAllSessions droits ou resetPasswordAnyUser.
Effectuer des actions sur le compte utilisateur
Annuler toutes les sessions utilisateur
Maintenant que nous disposons d'un jeton valide, nous pouvons configurer les actions à entreprendre lorsqu'un événement d'authentification multifactorielle (MFA) frauduleux est détecté, en commençant par révoquer toutes les sessions d'authentification de l'utilisateur concerné. Pour cela, nous allons appeler le /v1.0/auth/sessions/USERID point de terminaison dans ISV ( https://docs.verify.ibm.com/verify/reference/deleteallsessions ).
// Function to revoke all user sessions
async function revokeUserSessions(subject, accessToken) {
try {
const response = await fetch(
`${TENANT_URL}/v1.0/auth/sessions/${subject}`,
{
method: 'DELETE',
headers: {
'Authorization': `Bearer ${accessToken}`,
'Content-Type': 'application/json'
}
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
console.log(`Successfully deleted all sessions for user ${subject}`);
const data = await response.json();
return data;
} catch (error) {
console.error('Error revoking user sessions:', error.message);
throw error;
}
}Cette opération va désormais révoquer toutes les sessions d'authentification actives de l'utilisateur défini par subject dans le corps de la requête.
Déclencher la réinitialisation du mot de passe de l'utilisateur
L'étape suivante consiste à déclencher une réinitialisation du mot de passe du compte de l'utilisateur cible :
AttentionLe fait de déclencher automatiquement une réinitialisation du mot de passe de l'utilisateur à la suite d'un signalement de fraude est dangereux et doit généralement être évité, car cela risque de conduire facilement un utilisateur final à se retrouver temporairement bloqué hors de son compte si une demande d'authentification multifactorielle (MFA) est signalée par erreur comme frauduleuse, ce qui complique le processus d'authentification. Cet exemple est présenté ici afin d'illustrer les possibilités qui s'offrent en réponse à ce type d'événements; il ne doit pas être mis en œuvre tel quel.
Lorsqu'elle est déclenchée, cette action génère automatiquement un nouveau mot de passe pour l'utilisateur et lui envoie un e-mail l'informant de la réinitialisation de son mot de passe, ce qui permet en outre de remplir la condition consistant à avertir l'utilisateur qu'une action a été effectuée sur son compte. La documentation relative à l'API de réinitialisation du mot de passe est disponible ici : https://docs.verify.ibm.com/verify/reference/resetuserpassword
// Function to trigger password reset for user
async function triggerPasswordReset(subject, accessToken) {
try {
const response = await fetch(
`${TENANT_URL}/v2.0/Users/${subject}/passwordResetter`,
{
method: 'PATCH',
headers: {
'Authorization': `Bearer ${accessToken}`,
'Accept': 'application/scim+json',
'Content-Type': 'application/scim+json',
'usershouldnotneedtoresetpassword': 'false'
},
body: JSON.stringify({
schemas: ['urn:ietf:params:scim:api:messages:2.0:PatchOp'],
Operations: [
{
op: 'replace',
value: {
password: 'auto-generate',
'urn:ietf:params:scim:schemas:extension:ibm:2.0:Notification': {
notifyType: 'EMAIL',
notifyPassword: true,
notifyManager: false
}
}
}
]
})
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
console.log(`Successfully triggered password reset for user ${subject}`);
const data = await response.json();
return data;
} catch (error) {
console.error('Error triggering password reset:', error.message);
throw error;
}
}Maintenant que ces actions ont été définies dans leurs propres fonctions d'aide, il suffit de les appeler dans la processFraudulentReport fonction pour activer cette fonctionnalité.
Pour résumer
// Function to process fraudulent MFA report
async function processFraudulentReport(subject) {
try {
console.log(`Processing fraudulent report for subject: ${subject}`);
// Get access token
const accessToken = await getAccessToken();
console.log('Access token acquired');
// Revoke all user sessions
await revokeUserSessions(subject, accessToken);
// Trigger password reset
await triggerPasswordReset(subject, accessToken);
} catch (error) {
console.error('Error processing fraudulent report:', error.message);
throw error;
}
}Une fois ces étapes terminées, la processFraudulentReport fonction sera appelée dès la réception d'une requête POST provenant du service de notification, ce qui permettra d'automatiser la réponse à ce type d'événements.
Vous trouverez ci-dessous un exemple complet du code de l'application :
const express = require('express');
const app = express();
// Configuration
const PORT = process.env.PORT || 3000;
const AUTH_SECRET = process.env.AUTH_SECRET || 'your-secret-token-here';
const TENANT_URL = process.env.TENANT_URL || 'https://your-tenant.verify.ibm.com';
const CLIENT_ID = process.env.CLIENT_ID || '<client ID>';
const CLIENT_SECRET = process.env.CLIENT_SECRET || 'your-client-secret-here';
// Parse JSON bodies
app.use(express.json());
// Function to get access token from IBM Verify
async function getAccessToken() {
try {
const response = await fetch(
`${TENANT_URL}/oauth2/token`,
{
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: new URLSearchParams({
client_id: CLIENT_ID,
client_secret: CLIENT_SECRET,
grant_type: 'client_credentials',
scope: 'openid'
})
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
const data = await response.json();
return data.access_token;
} catch (error) {
console.error('Error getting access token:', error.message);
throw error;
}
}
// Function to revoke all user sessions
async function revokeUserSessions(subject, accessToken) {
try {
const response = await fetch(
`${TENANT_URL}/v1.0/auth/sessions/${subject}`,
{
method: 'DELETE',
headers: {
'Authorization': `Bearer ${accessToken}`,
'Content-Type': 'application/json'
}
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
console.log(`Successfully deleted all sessions for user ${subject}`);
const data = await response.json();
return data;
} catch (error) {
console.error('Error revoking user sessions:', error.message);
throw error;
}
}
// Function to trigger password reset for user
async function triggerPasswordReset(subject, accessToken) {
try {
const response = await fetch(
`${TENANT_URL}/v2.0/Users/${subject}/passwordResetter`,
{
method: 'PATCH',
headers: {
'Authorization': `Bearer ${accessToken}`,
'Accept': 'application/scim+json',
'Content-Type': 'application/scim+json',
'usershouldnotneedtoresetpassword': 'false'
},
body: JSON.stringify({
schemas: ['urn:ietf:params:scim:api:messages:2.0:PatchOp'],
Operations: [
{
op: 'replace',
value: {
password: 'auto-generate',
'urn:ietf:params:scim:schemas:extension:ibm:2.0:Notification': {
notifyType: 'EMAIL',
notifyPassword: true,
notifyManager: false
}
}
}
]
})
}
);
if (!response.ok) {
const errorData = await response.text();
throw new Error(`HTTP error! status: ${response.status}, body: ${errorData}`);
}
console.log(`Successfully triggered password reset for user ${subject}`);
const data = await response.json();
return data;
} catch (error) {
console.error('Error triggering password reset:', error.message);
throw error;
}
}
// Function to process fraudulent MFA report
async function processFraudulentReport(subject) {
try {
console.log(`Processing fraudulent report for subject: ${subject}`);
// Get access token
const accessToken = await getAccessToken();
console.log('Access token acquired');
// Revoke all user sessions
await revokeUserSessions(subject, accessToken);
// Trigger password reset
await triggerPasswordReset(subject, accessToken);
} catch (error) {
console.error('Error processing fraudulent report:', error.message);
throw error;
}
}
// Webhook endpoint
app.post('/notifications', async (req, res) => {
// Check authentication
const authHeader = req.headers['authorization'];
if (!authHeader || authHeader !== AUTH_SECRET) {
return res.status(401).json({ error: 'Unauthorized' });
}
const payload = req.body;
const { event_type, data = {}, correlationid } = payload;
const { subject, username, mfaresult, result } = data;
// Validate fraudulent MFA event
if (event_type === 'authentication' &&
result === 'failure' &&
mfaresult === 'USER_FRAUDULENT') {
console.log('FRAUDULENT MFA REPORT:');
console.log(` User: $USERNAME`);
console.log(` Subject: ${subject}`);
console.log(` Correlation ID: ${correlationid}`);
// Process the fraudulent report asynchronously
processFraudulentReport(subject)
.then(() => {
console.log('Fraudulent report processing completed');
})
.catch((error) => {
console.error('Failed to process fraudulent report:', error.message);
});
return res.status(200).json({
message: 'Fraudulent MFA report received and processing',
username
});
}
res.status(200).json({ message: 'Event received but not processed' });
});
// Start server
app.listen(PORT, '0.0.0.0', () => {
console.log(`Server running on port ${PORT}`);
console.log(`Webhook endpoint: http://localhost:${PORT}/notifications`);
console.log(`Tenant URL: ${TENANT_URL}`);
});Une fois hébergée sur un point de terminaison accessible via Internet à l'adresse IBM Verify, l'application est prête à recevoir et à traiter les rapports MFA.
Test de l'application
Pour vérifier que le webhook et l'application peuvent communiquer entre eux, vous pouvez effectuer un premier test en cliquant sur le bouton Tester la connexion dans la page d'interface d'administration Intégrations -> Webhooks de notification; un message vert indiquant Réussite devrait s'afficher si la requête est traitée comme prévu.
Pour vérifier que notre intégration fonctionne correctement dans un scénario réel, nous pouvons tester l'application en simulant une transaction MFA refusée par l'utilisateur. Dans le cadre de cette procédure de test, les étapes suivantes doivent être effectuées :
- Créez un utilisateur test dans l'interface d'administration (voir : Gestion des utilisateurs - Procédure )
- Configurez le compte de test avec une méthode d'authentification multifactorielle (MFA) via IBM Verify (voir : Gestion de vos authentificateurs IBM Verify- Ajout de l'application IBM Verify )
Une fois cette étape franchie, nous pourrons tester le processus du début à la fin et nous assurer que l'intégration fonctionne comme prévu.
Lancer la demande d'authentification à plusieurs facteurs (MFA)
Pour déclencher la demande d'authentification à deux facteurs (MFA), nous allons nous connecter au compte de test et tenter d'accéder à l'onglet Sécurité, dont l'accès nécessite une session authentifiée via la MFA. Pour ce faire, rendez-vous sur le tableau de bord USC -> icône Profil en haut à droite -> Profil et paramètres -> Sécurité. En accédant à cette page, l'utilisateur sera automatiquement redirigé vers l'interface d'authentification MFA.
RemarquePour relancer ce processus et être à nouveau invité à s'identifier via l'authentification à deux facteurs (MFA), l'utilisateur devra se déconnecter puis se reconnecter avant d'accéder à nouveau à la page des paramètres de sécurité.
Lorsque vous y êtes invité, sélectionnez la méthode d'authentification appropriée (dans ce cas, IBM Verify, affichée sous la forme 'iPhone (Touch Approval)) et attendez de recevoir une notification sur l'appareil.
Refuser la demande d'authentification MFA
L'utilisateur sera alors invité à répondre à la demande d'authentification multifactorielle (MFA) via l'application mobile IBM Verify, soit par le biais d'une notification push, soit en ouvrant l'application et en actualisant manuellement la page. Dans cet exemple, nous utilisons l'application mobile iOS, à partir de laquelle les captures d'écran suivantes ont été réalisées.
Lorsque le système vous demande d'approuver ou de refuser la transaction, sélectionnez l'option refuser. L'application proposera désormais deux options pour refuser la demande : Marquer comme suspect et J'ai changé d'avis, ainsi que la possibilité d'annuler le refus.
Dans cette liste, sélectionnez Marquer comme suspect. Cela entraînera le rejet de la transaction et déclenchera un USER_FRAUDULENT événement, ce qui lancera le flux d'automatisation configuré dans ce scénario. L'utilisateur devrait alors recevoir un e-mail l'informant qu'une réinitialisation du mot de passe a été lancée pour son compte, ce qui confirme que le processus fonctionne comme prévu.
De plus, lorsque l'utilisateur tente d'accéder à une autre page de l'instance IBM Verify au cours de la même session de navigation, il est automatiquement redirigé vers la page de connexion afin de s'authentifier à nouveau, en raison de la révocation de toutes les sessions d'authentification actives.
Conclusion
L'intégration du webhook d'articles et de notifications à l'application d'exemple illustre un processus de correction automatisé permettant de traiter les demandes d'authentification multifactorielle (MFA) suspectes signalées par les utilisateurs concernant l'application mobile IBM Verify. Cela permet de personnaliser la gestion de ce type d'événements sans qu'un administrateur humain ait à intervenir directement pour consulter l'interface utilisateur de rapport afin de déterminer les meilleures mesures à prendre.
Il présente en outre un exemple d'utilisation du type USER_FRAUDULENT de résultat d'événement MFA pouvant être généré lors de l'utilisation de l'application mobile IBM Verify, explique comment ces résultats peuvent être traités et indique les mesures à prendre pour remédier à l'activité suspecte signalée. L'un des points forts réside ici dans la facilité d'intégration d'applications personnalisées permettant d'utiliser les API d' IBM Verify, en tirant parti des méthodes d'autorisation disponibles, à savoir les webhooks de notification et les clients API, afin de créer un flux sécurisé de bout en bout.
Updated about 9 hours ago