Mise en place d'un exemple d'application
Getting Started with Adaptive Access for Native Applications
Introduction
Ce guide explique comment utiliser Adaptive Access dans une application native NodeJS en utilisant les packages Adaptive Browser SDK et Adaptive Proxy SDK.
Le SDK du navigateur adaptatif est utilisé pour diffuser le JavaScript côté client qui permet la collecte de données dans le navigateur. Le SDK Adaptive Proxy fournit des classes qui gèrent les transactions d'authentification dépendant de politiques qui incluent des déterminations de risque d'accès adaptatif.
Pour mieux comprendre les différentes entités impliquées dans l'accès adaptatif, voir Adaptive SDK.
Prérequis
Vous devez déjà avoir créé une définition d'application personnalisée pour votre application et l'avoir intégrée à l'Adaptive Sign-On. Voir Embarquez votre application.
NodeJS doit être installé sur la machine où vous allez créer et exécuter l'exemple d'application décrit dans ce guide. NodeJS est disponible pour de nombreuses plateformes, notamment Windows, MacOS, et Linux. Téléchargez et installez NodeJS ici.
Mise en place de l'environnement
Vous allez maintenant mettre en place votre environnement de développement en créant un nouveau projet Node et en installant quelques dépendances initiales.
Créer un nouveau projet Node
Dans un répertoire vide, créez un nouveau projet Node à l'aide de la commande bash suivante :
npm init -y
Cela créera un fichier package.json, qui conservera la trace de toutes les dépendances de votre projet, facilitant ainsi votre processus de développement.
Installer les dépendances
Les dépendances suivantes sont nécessaires pour cet exemple d'application :
Utilisez npm pour installer ces dépendances :
npm install adaptive-browser-sdk adaptive-proxy-sdk express body-parser express-session
Créer un fichier index.js
Le fichier index.js sera le point de départ de votre projet. Il s'agit du script qui sera exécuté en premier lorsque vous lancerez votre projet.
touch index.js
Configuration du serveur Express
Modifiez le fichier index.js à l'aide d'un éditeur de texte ou d'un IDE. Importez les dépendances et configurez votre serveur Express en ajoutant le code suivant à votre fichier index.js.
const express = require('express');
const app = express();
// Add JSON middleware, since we'll be handling JSON requests
app.use(express.json());
// add session awareness
const session = require('express-session')
app.use(session({
secret: 'keyboard cat',
resave: false,
saveUninitialized: true,
}));
// Define a static route into the Adaptive Browser SDK npm module
// so that the client-side code can be loaded at /static/adaptive-v1.js
app.use('/static/adaptive-v1.js', express.static(__dirname
+ '/node_modules/adaptive-browser-sdk/dist/adaptive-v1.min.js'));
Ajout d'une page de connexion
Après l'intégration d' une application, un extrait de page web est fourni. Cet extrait charge le SDK du navigateur adaptatif en utilisant le lien statique que vous avez ajouté à votre application NodeJS dans la section précédente. Vous allez maintenant créer une page de connexion pour l'exemple d'application et intégrer le snippet web.
Créer un fichier login.html
Créez le fichier login.html dans le répertoire racine de votre projet. Cette page demandera à l'utilisateur ses identifiants de connexion lors de la collecte.
touch login.html
Intégrer un snippet web dans la page de connexion
La page login.html doit inclure le snippet web créé pour l'application dans le <head> de la page pour charger et initialiser le Browser SDK. Le SDK du navigateur effectuera alors la collecte de données côté client requise par Adaptive Access.
Ajoutez le code suivant à la page login.html:
<html>
<head>
<!--
Paste the script snippet that was provided when you
on-boarded your application.
-->
</head>
<body>
<h1>Login</h1>
<form name='login' action='/login' method='POST'>
<label for='username'>Username:</label><br>
<input type='text' id='username' name='username'><br>
<label for='password'>Password:</label><br>
<input type='password' id='password' name='password'><br>
<input type='submit' value='Submit'>
</form>
</body>
</html>
Collez l'extrait de site web fourni lors de l'intégration dans la page login.html- en remplaçant le bloc <!-- ... --> qui indique où le placer.
N'invoquer le SDK du navigateur que sur les pages de connexion et de recollection
Le SDK du navigateur ne doit pas être invoqué sur des pages qui ne sont pas la page de connexion ou la page de recollection. L'exécution de la collecte sur d'autres pages peut entraîner un comportement inattendu.
Veiller à ce que la collecte soit complète
Avec le snippet web en place, le SDK du navigateur commencera à fonctionner en arrière-plan dès que la page de connexion sera chargée. Cela permet de l'exécuter pendant que l'utilisateur entre ses données de connexion.
Il est important qu'une fois que l'utilisateur a saisi ses données de connexion, la soumission du formulaire soit augmentée. Il existe deux raisons à cela :
- Il est nécessaire de capturer le site
sessionIDgénéré par le SDK du navigateur. Cette adressesessionIDest utilisée dans les appels de l'API à IBM Verify pour les mettre en corrélation avec les données recueillies dans le navigateur. - Pour s'assurer que le SDK du navigateur termine son exécution avant que l'utilisateur ne quitte la page.
Le SDK du navigateur fournit une fonction, getSessionId(), qui renvoie une promesse. La résolution de cette promesse comprendra l'identifiant de la session. Cette méthode doit être invoquée et la promesse renvoyée doit être enchaînée dans la soumission du formulaire, de sorte que la séquence suivante soit respectée :
- L'utilisateur soumet le formulaire
- Le SDK du navigateur résout la promesse d'ID de session
- Le formulaire de connexion est complété pour inclure l'identifiant de session
- Soumission du formulaire
Par conséquent, dans votre page de connexion, vous devez compléter la soumission du formulaire par la modification suivante :
window.addEventListener('load', function (e) {
var form = document.getElementsByName('login')[0];
form.addEventListener('submit', function (event) {
event.preventDefault();
getSessionId().then(sessionID => {
const sessionIDField = document.createElement('input');
sessionIDField.type = 'hidden';
sessionIDField.name = 'sessionId';
sessionIDField.value = sessionID;
form.appendChild(sessionIDField);
form.submit();
});
});
});
Votre page de connexion devrait maintenant ressembler à ceci :
<html>
<head>
<script src="/static/adaptive-v1.js"></script>
<script>startAdaptiveV1("xxxxxx.cloudfront.net", 123456);</script>
<script>
window.addEventListener('load', function (e) {
var form = document.getElementsByName('login')[0];
form.addEventListener('submit', function (event) {
event.preventDefault();
getSessionId().then(sessionID => {
const sessionIDField = document.createElement('input');
sessionIDField.type = 'hidden';
sessionIDField.name = 'sessionId';
sessionIDField.value = sessionID;
form.appendChild(sessionIDField);
form.submit();
});
});
});
</script>
</head>
<body>
<h1>Login</h1>
<form name='login' action='/login' method='POST'>
<label for='username'>Username:</label><br>
<input type='text' id='username' name='username'><br>
<label for='password'>Password:</label><br>
<input type='password' id='password' name='password'><br>
<input type='submit' value='Submit'>
</form>
</body>
</html>
L'augmentation peut également être incluse dans une chaîne de promesses, si la validation et la soumission sont déjà gérées en JavaScript. Par exemple :
function formSubmit() {
validateFormFields().then(formData => {
return getSessionId().then(sessionID => {
formData['sessionId'] = sessionID;
return formData;
})
}).then(formData => postForm(formData));
}
Pour la documentation de l'API pour le SDK du navigateur, voir le README de GitHub.
Servir la page de connexion
Pour exposer votre nouvelle page login.html, vous devez l'ajouter en tant que ressource à l'application NodeJS. Pour vous faciliter la tâche, vous ajouterez également une page racine qui redirigera vers cette page de connexion si la session n'est pas authentifiée.
Ajoutez ce qui suit au fichier index.js créé ci-dessus :
// Create a home page that redirects to /login if authentication not complete.
// Returns session token object if authenticated.
app.get('/', (req, res) => {
if (!req.session.token) {
res.redirect('/login');
} else {
res.send(req.session.token);
}
});
// Expose the '/login.html' file for GET /login.
app.get('/login', (_, res) => {
res.sendFile(__dirname + '/login.html');
});
// Start the server on port 3000.
const port = 3000;
app.listen(port, console.log(`Listening on port ${port}...`));
Questions de domaine
Pour que le processus de collecte fonctionne correctement, il faut accéder au serveur en utilisant un domaine autorisé spécifié lors de l'intégration de l'application.
Si vous n'êtes pas encore prêt à exécuter l'application sur votre serveur public, une solution temporaire consiste à ajouter
127.0.0.1 www.<YOUR.ALLOWED.DOMAIN>au fichier /etc/hosts sur votre machine de développement locale.
Commencez votre demande. Vous pouvez le faire à l'aide de cette commande :
node index.js
Lorsque le serveur est en cours d'exécution, accédez à l'application dans un navigateur :
http://www.<YOUR.ALLOWED.DOMAIN>:3000/
Si tout va bien, vous devriez voir ce qui suit au chargement de votre page de connexion (dans ce cas avec les outils de développement affichant la console JavaScript ):
Console de collecte du SDK du navigateur adaptatif
La fenêtre du navigateur indique que la page de connexion a été affichée avec succès. La trace de la console montre que le SDK du navigateur adaptatif a été appelé avec succès et que le service a renvoyé un identifiant de session.
La logique d'application permettant de gérer la page de connexion soumise sera ajoutée ultérieurement.
Arrêtez l'application en appuyant sur Ctrl-C dans le terminal où s'exécute votre processus Node.
Hébergement d'une ressource statique connue
Dans le cadre de l'ajout du SDK du navigateur, une ressource statique doit également être ajoutée à l'application. Il est recommandé d'utiliser un PNG transparent de 1x1 pixel.
Cette ressource statique doit être disponible sur le chemin d'accès /icons/blank.gif et répondre aux exigences suivantes :
- Il ne doit exister aucune redirection automatique de cette URL vers une autre page Web.
- Vous devez ajouter une exception complète à toute politique de sécurité du contenu (CSP).
- La taille maximale de l'image est de 500 octets.
- Le type d'image doit être
image/gif,image/png,image/jpeg, ouimage/jpg. - La ressource statique doit inclure un en-tête de type de contenu, par exemple
Content-Type:image/png, afin d'éviter d'inviter l'utilisateur à télécharger la ressource.
Le SDK du navigateur comprend une ressource statique qui peut être exposée de la même manière que le SDK du navigateur lui-même.
Ajoutez le code suivant à la fin de votre fichier index.js:
// Define a static route into the Adaptive Browser SDK npm module
// so that the blank gif is available at /icons/blank.gif
app.use('/icons/blank.gif', express.static(__dirname
+ '/node_modules/adaptive-browser-sdk/blank.gif'));
Ajouter le SDK proxy à l'application
Le Proxy SDK permet à un serveur d'application d'utiliser facilement l'API /token dans des flux natifs.
Il est faiblement couplé au SDK du navigateur et n'impose pas d'exigences de déploiement spécifiques à l'application. Cela permet au développeur de contrôler la manière dont le formulaire de connexion interagit avec l'application dorsale.
Interaction entre les navigateurs et les SDK de proxy
Initialiser le SDK
Afin d'utiliser le Proxy SDK, il doit être requis et initialisé. L'initialisation nécessite trois entrées :
- tenantUrl- Le site URL de votre locataire IBM Verify.
- clientId- L'identifiant du client de votre application personnalisée.
- clientSecret- Le secret du client de votre application personnalisée.
Pour savoir comment obtenir le site clientId et clientSecret, voir On-boarding a native application.
Informations d'identification de l'application
Les adresses
client_idetclient_secretutilisées par le SDK adaptatif sont des identifiants d'application et non des identifiants de client API.
Ajoutez ces lignes à la fin de votre fichier index.js (en remplaçant les valeurs par celles de votre locataire et de votre application):
// Initialize Adaptive Proxy SDK
const Adaptive = require('adaptive-proxy-sdk');
const adaptiveConfig = {
tenantUrl: 'https://cloudidlab.ice.ibmcloud.com', // Your Verify tenant URL
clientId: '6d7393c8-53c3-4d0b-844b-886e28cb9af5', // Your Verify client ID
clientSecret: '2coMYUTIzg', // Your Verify client secret.
};
const adaptive = new Adaptive(adaptiveConfig);
Protégez vos secrets
Dans le cadre d'une utilisation en production, le site
clientSecretest généralement extrait d'un magasin sécurisé géré par le déploiement de l'application.
Maintenant que le SDK est initialisé, nous pouvons authentifier un utilisateur.
Utilisation du Proxy SDK pour authentifier un utilisateur
Le Proxy SDK crée et gère une "transaction" d'authentification qui comprend l'authentification initiale (premier facteur) et l'authentification multi-facteurs optionnelle (MFA), en gérant l'état à travers les demandes.
Entrées SDK
Le serveur d'application doit fournir trois éléments lorsqu'il appelle les fonctions du SDK Adaptive Proxy :
- ID de session- Il est reçu dans les données POST de la page de connexion.
- Adresse IP- Soit extraite directement de la demande, soit consommée à partir d'un en-tête fourni par le point final qui a reçu la demande (c'est-à-dire
X-forwarded-for). - User-Agent- un en-tête standard inclus dans les requêtes HTTP (c'est-à-dire
User-Agent).
Ces valeurs sont transmises au Proxy SDK sous la forme de context. Ce contexte est inclus dans l'appel de l'API à /token.
Réponse du SDK
Lors de l'intégration avec le Proxy SDK, trois types de réponses peuvent devoir être gérées :
- Autoriser- Authentification terminée. Les jetons d'identité et d'accès sont inclus dans cette réponse.
- Deny- L'utilisateur se voit refuser l'accès. Aucune autre action n'est possible.
- Require- Authentification supplémentaire requise. Informations sur les méthodes autorisées.
Les fonctions du SDK peuvent également générer des erreurs. Cela peut se produire lorsque, par exemple, le nom d'utilisateur et le mot de passe fournis sont incorrects.
Création d'un flux de travail de connexion
Ces trois réponses permettent de construire un flux de travail tel que :
- L'utilisateur initie la connexion
- Évaluation du premier facteur réalisée
- L'utilisateur peut se voir refuser l'accès à ce moment-là.
- par exemple, tentative d'accès à partir d'un pays interdit
- L'utilisateur peut être tenu d'utiliser des méthodes spécifiques de premier facteur
- L'utilisateur peut se voir refuser l'accès à ce moment-là.
- L'utilisateur est invité à se connecter au moyen d'un premier facteur
- L'utilisateur se connecte avec succès
- Réalisation d'une évaluation adaptative des risques
- L'utilisateur peut être autorisé à accéder immédiatement en raison d'un score de risque évalué faible
- L'utilisateur peut être amené à fournir d'autres facteurs d'authentification
- L'utilisateur peut se voir refuser l'accès en raison d'un score de risque élevé
Diagramme d'état des flux
En fonction de l'expérience utilisateur requise dans l'application, deux approches peuvent être adoptées :
-
Lorsque vous utilisez l'authentification par mot de passe pour le premier facteur, vous pouvez présenter la page de connexion à l'utilisateur immédiatement, puis initialiser la transaction d'authentification adaptative uniquement lorsque l'utilisateur a fourni un nom d'utilisateur et un mot de passe.
-
En cas d'utilisation d'autres méthodes de premier facteur, ou lorsque les règles de préauthentification peuvent modifier les méthodes de premier facteur proposées, la transaction d'authentification adaptative doit être initialisée avant la présentation de la page de connexion. Dans ce cas, l'identifiant de session utilisé dans l'appel initial au SDK doit être une chaîne vide (puisque la collecte par le SDK du navigateur n'a pas encore été exécutée).
Cet exemple d'application ne prend en charge que l'authentification par mot de passe comme premier facteur et utilise donc la première approche parce qu'elle est plus simple à mettre en œuvre.
Ajoutez les lignes suivantes à la fin de votre fichier login.js:
// add body parsing
const bodyParser = require('body-parser');
// Add url form-encoded middleware to process login form
app.use(bodyParser.urlencoded({
extended: true
}));
var identitySourceId;
// Manage login form POST to /login
app.post("/login", async (req, res) => {
// Extract parameters from request.
const username = req.body.username;
const password = req.body.password;
const sessionId = req.body.sessionId;
// Set up context required for call to Adaptive SDK
var context = {
sessionId: sessionId,
userAgent: req.headers['user-agent'],
ipAddress: req.ip
};
// Perform a risk assessment.
let assessResult = await adaptive.assessPolicy(context);
if (assessResult.status == "deny") {
res.status(403).send({
error: "Denied"
});
return
}
// Store Adaptive sessionId to session
req.session.sessionId = sessionId;
if (assessResult.allowedFactors.filter((entry) =>
{ return entry.type == "password" }).length > 0) {
try {
// Look up identity source ID
if (!identitySourceId) {
let identitySources = await adaptive.lookupIdentitySources(
context, assessResult.transactionId, "Cloud Directory")
identitySourceId = identitySources[0].id;
}
// Check password - returns risk evaluation
let result = await adaptive.evaluatePassword(context,
assessResult.transactionId, identitySourceId,
username, password);
handleEvaluateResult(req, res, context, result);
} catch (error) {
console.log(error);
if (error.response.data.messageDescription) {
res.status(403).send({error: error.response.data.messageDescription});
} else {
res.status(403).send({error: "Password check failed"});
}
}
} else {
res.status(403).send({error: "Password login not allowed"});
}
});
async function handleEvaluateResult(req, res, context, result) {
// If denied, return 403 forbidden.
if (result.status == "deny") {
console.log(result);
res.status(403).send({error: "Denied"});
return
}
// If allowed, store token and redirect to homepage
if (result.status == "allow") {
req.session.token = result.token;
res.redirect("/");
return
}
// MFA Case to be handled here
}
Note : L'objet adaptive a été initialisé à l'aide du proxy SDK dans une section précédente.
Identité Source ID
Dans le code ci-dessus, l'identifiant de la source d'identité pour le répertoire du nuage est obtenu dynamiquement sur la base de son nom. Si vous préférez, vous pouvez coder en dur l'ID de la source d'identité. Vous pouvez trouver l'ID d'une source d'identité en regardant ses propriétés dans l'interface d'administration de votre locataire (sous Configuration->Sources d'identité)
Exécution de l'authentification multi-facteur
Le code de la section précédente ne traite que les réponses deny et allow après l'authentification à première vue. Dans cette section, vous ajouterez du code pour gérer le cas où une authentification multifactorielle supplémentaire est requise.
Un défi d'AMF est détecté en vérifiant la présence d'un status ayant la valeur requires. Un statut "requires" indique qu'une authentification supplémentaire doit être effectuée par l'utilisateur final. Il est possible qu'un statut "requires" soit renvoyé chaque fois que /token est invoqué, que ce soit pour établir une subvention ou pour utiliser un jeton de rafraîchissement.
Contrôle de l'évaluation des politiques
Vous pouvez contrôler le moment où l'AMF est requise en ajoutant ou en ajustant les règles à l'aide de l'éditeur de politique. Pour plus d'informations sur la politique, voir Politique d'accès aux applications natives.
Vous allez maintenant ajouter du code pour gérer une réponse requires, traiter les inscriptions renvoyées et lancer l'OTP par courrier électronique s'il est disponible.
Insérez le code suivant à l'endroit où vous voyez // MFA Case to be handled here dans votre fichier index.js:
if (result.status == "requires") {
// Extract type from each available factor.
var availableFactors = result.enrolledFactors.map(f => f.type);
// Save transactionId to session
req.session.transactionId = result.transactionId;
// In this instance we're only supporting email OTP
var emailIdx = availableFactors.indexOf("emailotp");
if (emailIdx != -1) {
req.session.currentFactor = "emailotp";
try {
// Initiate the email OTP
await adaptive.generateEmailOTP(context, result.transactionId,
result.enrolledFactors[emailIdx].id);
// Return /otp challenge page;
res.sendFile(__dirname + '/otp.html');;
} catch (error) {
res.status(500).send({error: "OTP generate fail: " + error.message});
}
} else {
res.status(500).send({ error: "Email OTP factor not available."
+ JSON.stringify(result)});
}
}
Créez un fichier nommé otp.html et remplissez-le avec ce contenu simple pour présenter un défi OTP :
<html>
<head>
</head>
<body>
<h1>Submit OTP</h1>
<p>If the received code's format is 1234-567890
only enter the group of digits after the '-',
i.e. 567890</p>
<form name="otpform" action="/otp" method="POST">
<label for="otp">OTP:</label><br>
<input type="text" id="otp" name="otp"><br>
<input type="submit" value="Submit">
</form>
</body>
</html>
Ajoutez ce qui suit à la fin de votre fichier index.js pour exposer cette page OTP et gérer le POST qu'elle renvoie lorsque l'utilisateur soumet l'OTP :
// Handle OTP challenge page POST to /otp
app.post("/otp", async (req, res) => {
const otp = req.body.otp;
// Get adaptive transaction from session
var transactionId = req.session.transactionId;
// Set up context required for call to Adaptive SDK
var context = {
sessionId: req.session.sessionId,
userAgent: req.headers['user-agent'],
ipAddress: req.ip
};
// Verify the email OTP - risk evaluation returned
try {
let result = await adaptive.evaluateEmailOTP(context, transactionId, otp);
// If denied, return 403 forbidden
if (result.status == "deny") {
res.status(403).send({error: "Denied"});
return
}
// If allowed, save token and redirect to homepage
if (result.status == "allow") {
req.session.token = result.token;
res.redirect("/");
return
}
} catch (error) {
console.log(error);
if (error.response.data.messageDescription) {
res.status(403).send({error: error.response.data.messageDescription});
} else {
res.status(403).send({error: error.message});
}
}
});
L'OTP fourni par l'utilisateur est vérifié en appelant la fonction evaluateEmailOTP
Si l'OTP est incorrect, la fonction génère une erreur.
Il serait inhabituel de recevoir un statut deny à ce stade, mais cela est possible et doit être traité.
Si l'OTP est correct, la réponse aura le statut allow. Dans ce cas, un jeton d'identité (JWT) et un jeton d'accès pour l'utilisateur authentifié seront également renvoyés. Il appartient au développeur de l'application de stocker ces jetons dans la session et de marquer la session comme étant authentifiée.
Voici un exemple de l'objet de résultat renvoyé :
{
"status": "allow",
"token": {
"access_token": "gJduCYHPK0jG7RBiMSiQ3WtGQvxUzpp4GtqTZi8s",
"scope": "openid",
"grant_id": "24c6fa4e-dca5-4876-bd24-6b897920d74b",
"id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InNlcnZlciJ9.eyJhY3IiOi...HAiOiAxNTk5MTAxMzY3fQ.HZ9LE3Hb3GkXD..7sQJFlXoXGP3w",
"token_type": "Bearer",
"expires_in": 7199
}
}
Dans cet exemple d'application, vous êtes redirigé vers / une fois l'authentification terminée. La présence du jeton entraîne l'affichage d'un simple message You are authenticated.
Félicitations ! Vous avez configuré avec succès une application native pour Adaptive Access.
Validation
Après avoir déployé avec succès votre application web et incorporé le SDK du navigateur adaptatif IBM Verify et le SDK du proxy IBM Verify, une validation de bout en bout peut être réalisée.
Scénario de validation
Nous pouvons utiliser un scénario de validation simple pour nous assurer que la configuration de l'application Web native et de l'accès adaptatif est correcte.
Si le scénario n'aboutit pas, vous devez
- utiliser les informations contenues dans le site Événements et rapports pour déterminer le résultat de l'événement et du rapport (succès, événement manquant, indisponible, inattendu)
- suivez les étapes de dépannage pour ce type de résultat, comme décrit dans la section Dépannage de l'accès adaptatif.
-
Le scénario de validation simple recommandé comprend
- Créer un utilisateur
- S'authentifier auprès de l'application Web
- Relever le défi de l'AMF
- Accéder à l'application
-
Le scénario est validé :
- IBM Verify Intégration du SDK du navigateur adaptatif
- Collecte et détection des navigateurs des clients
- IBM Verify Invocation du SDK Proxy
- Invocation et évaluation de la politique d'accès adaptative
-
L'expérience de l'utilisateur doit être :
- Lancer l'application Web native
- Défi du premier facteur (mot de passe)
- Défi AMF (e-mail OTP)
- Accès autorisé
Page de connexion chargée
À l'aide des Developer Tools du navigateur, vérifiez que le SDK du navigateur lance la collecte et la détection des accès adaptatifs.
Ces demandes doivent être visibles dans l'onglet Network et inclure une demande à l' URL cloudfront qui a été fournie lors de l'intégration de l'application.
Par exemple :
https://d1anfu45urknyg.cloudfront.net/511843/aloads.js?dt=login&r=0.3289762412868322
Vous devriez voir des chargeurs JavaScript supplémentaires demandés, qui peuvent inclure
- bits.js
- main.js
- tags.js
Ces chargeurs doivent renvoyer un code de réponse 200 avec un corps de réponse non vide.
De plus, vous devriez voir plusieurs autres requêtes vers la même URL cloudfront avec des chemins URI différents au fur et à mesure que la collecte se poursuit.
Native Web application login. collection, detection and Session ID generation
ID de session généré
Lors de l'invocation de getSessionId() à partir du SDK du navigateur, la console des Developer Tools navigateur affichera Session ID qui peut être utilisé pour effectuer la corrélation de l'ID de session avec le rapport d'accès adaptatif ou l'API du service d'événements.
Par exemple
CDN snippet loaded
[:getTCSID(csid)] csid: pp24c528943651cbe63c91dd0590b24323a80a0b401600954689
[:getFlow()]
Si la sortie de la trace a été effacée ou si Developer Tools n'était pas ouvert pendant la collecte et que le site Session ID n'est pas visible, vous pouvez invoquer le SDK du navigateur pour obtenir l'ID de la session sans déclencher la collecte.
await getSessionId()
qui renvoie l'identifiant de la session en cours
pp24c528943651cbe63c91dd0590b24323a80a0b401600954689
Évaluation de la politique d'accès
Après l'authentification initiale, la politique d'accès adaptative pour les applications natives est évaluée. Lorsque l'on utilise l'action recommandée de MFA per session pour le niveau de risque Medium dans les règles de post-authentification, les nouveaux utilisateurs seront invités à se soumettre à l'AMF lors de l'établissement de la session.
Une fois l'AMF terminée, la session de l'utilisateur sera ramenée au niveau de risque Low et l'utilisateur sera autorisé à accéder à l'application - à moins que le même utilisateur ne tente de se connecter à partir d'un nouvel appareil.
Native Web application Adaptive access policy
Rapport sur l'accès adapté
Lors de l'utilisation de la politique d'accès adaptative recommandée, le nouvel utilisateur sera évalué au niveau de risque Medium et devra se soumettre à l'AMF (par session). Une fois le défi MFA relevé, la politique d'accès adaptative est réévaluée et l'utilisateur devrait maintenant être évalué comme étant de niveau de risque Low et autorisé à accéder.
Niveaux de risque
Si la collecte et la détection révèlent des indications de risque spécifiques, l'utilisateur peut être évalué à un niveau de risque plus élevé.
Des exemples de niveaux de risque sont décrits dans les niveaux de risque de la note de confiance.
Dans l'exemple suivant de rapport sur l'accès adaptatif
- la ligne du bas indique
Risk Service Unavailableen raison de l'exécution du scénario de validation avant la fin de l'intégration.
L'action politique correspondant au niveau de risqueMediumest appliquée. - la ligne du milieu indique que l'évaluation du nouvel utilisateur est
MediumNiveau de risque, car c'est la première fois que cet utilisateur est évalué sur cet appareil. - la ligne supérieure montre la réévaluation de la politique après la réussite de l'AMF.
Il est maintenant vérifié que l'utilisateur utilise ce navigateur pour cette application et le niveau de risque est évalué àLow.
Les détails clés de l'évaluation sont affichés lors de la sélection d'une ligne d'événement.
L'identifiant de session doit correspondre à celui généré par le SDK Web dans la page de connexion.
Lors des authentifications ultérieures (logins) ou du rafraîchissement du jeton, l'utilisateur doit continuer à être évalué au niveau de risque Low, à moins qu'un indicateur Adaptive details ne soit déclenché et ne modifie le niveau de risque de l'utilisateur, par exemple, un ou plusieurs des éléments suivants :
- Anomalie comportementale
- Nouvel appareil
- Appareil à risque
- Connexion à risque
- Nouvel emplacement
Adaptive access report detail for new user reauthentication and refresh
Si la validation de l'accès adaptatif ne s'exécute pas correctement, le dépannage peut commencer en suivant la procédure de collecte de données décrite dans la section Événements et rapports.
- Effectuer la corrélation de l'identifiant de session entre l'identifiant généré par le SDK Web et l'API du service d'événements ou le rapport d'accès adaptatif.
- Initialement, lorsqu'un SessionID expiré ou non apparié est présenté, aucun événement ou rapport ne sera créé dans le rapport d'accès adaptatif. Au lieu de cela, l'évaluation de la politique renvoie une erreur indiquant que la collecte était incomplète. Il s'agit de déclencher une réminiscence pour tenter de récupérer.
- Si aucun identifiant de session n'est fourni ou après plusieurs tentatives infructueuses d'utilisation d'un identifiant de session, une réponse " Risk Service Unavailable " est renvoyée à la politique d'accès adaptative qui renverra l'action politique du niveau de risque
Medium. - Si l'utilisateur n'a pas été invité à utiliser l'AMF ou s'il continue d'être évalué à un niveau de risque supérieur à
Low, revoir la décision d'évaluation Unexpected.
Updated about 1 month ago