Nœuds : décisions

Nœuds qui évaluent une condition et branchent le graphe d’authentification en conséquence. Beaucoup ne se limitent pas à true/false : ils renvoient des sorties métier explicites, à connecter individuellement.

1 2 3

Exemple : une boucle de nouvelle tentative avec RetryLimitNode#

Le graphe le plus simple qui illustre un mécanisme non trivial : une boucle qui redemande le mot de passe en cas d’échec, jusqu’à une limite de tentatives.

UsernameCollectorNode ──outcome──▶ PasswordCollectorNode ──outcome──▶ DataStoreNode
                                          ▲                              │
                                          │ true (sous la limite)        │ false
                                          │                              ▼
                                    RetryLimitNode ◀───────────── (échec credentials)
                                          │
                                          │ false (limite atteinte)
                                          ▼
                                       FailureNode

DataStoreNode ──true──▶ SuccessNode

{
  "startNodeId": "username",
  "steps": {
    "username": { "type": "UsernameCollectorNode", "config": {}, "outcomes": { "outcome": "password" } },
    "password": { "type": "PasswordCollectorNode", "config": {}, "outcomes": { "outcome": "check" } },
    "check": {
      "type": "DataStoreNode",
      "config": { "authLevel": 0 },
      "outcomes": { "true": "success", "false": "retry" }
    },
    "retry": {
      "type": "RetryLimitNode",
      "config": { "retryLimit": 3 },
      "outcomes": { "true": "password", "false": "failure" }
    },
    "success": { "type": "SuccessNode", "config": {}, "outcomes": {} },
    "failure": { "type": "FailureNode", "config": {}, "outcomes": {} }
  }
}

RetryLimitNode ne connaît que sa propre propriété retryLimit : il compte les passages en échec dans le transient state (perdu si le navigateur ferme l’onglet), et bascule sur false une fois la limite atteinte. C’est le nœud qui coupe la boucle password → check → retry → password et évite un bruteforce illimité.

Les nœuds#

DataStoreNode : authentifie username/password contre le User Store LDAP ; en cas de succès écrit authenticatedUser et authLevel en shared state et réinitialise le compteur de tentatives.

Outcomes : true / false.

AccountLockStatusNode : vérifie si le compte est verrouillé via LockoutService.isLocked(). Aucune propriété configurable. Outcomes : true / false.

LockoutNode : agit sur le verrouillage (à la différence d’AccountLockStatusNode, qui ne fait que le lire) : verrouille ou déverrouille le compte selon action.

Outcome : outcome.

AuthLevelNode : compare le niveau d’authentification courant du shared state au minimum requis.

Outcomes : true / false.

RetryLimitNode : voir l’exemple ci-dessus.

Outcomes : true / false.

BearerTokenNode : valide un jeton Bearer opaque (en-tête Authorization, ou clé de shared state en repli), écrit username en cas de succès.

Outcomes : true / false.

StepUpAuthNode : déclenche une ré-authentification si le niveau courant est insuffisant ; le niveau requis peut être surchargé dynamiquement via une clé de shared state (utile pour protéger une transaction spécifique).

Outcomes : true / false.

ScriptNode : exécute un script serveur identifié par scriptId, avec accès en binding à sharedState, username, logger, idRepository, et aux constantes SUCCESS/FAILED.

Outcomes : true / false.

ScriptedDecisionNode : décision écrite en JavaScript directement dans le graphe, sans passer par la bibliothèque de scripts. Le script branche avec action.goTo('<outcome>') et peut demander une saisie avec action.send(...). Il dispose de sharedState (lecture et écriture), requestHeaders, callbacks (valeurs soumises), callbacksBuilder (créer des callbacks), logger et idRepository.

Outcomes : ceux déclarés dans outcomes.