Authentification par mot de passe

Introduction

Dans ce guide, vous apprendrez à effectuer la validation de mot de passe de manière programmatique via les API REST à l'aide de IBM Verify.

Prérequis

Un utilisateur final peut s'authentifier à l'aide de la validation de mot de passe s'il dispose d'un compte dont le mot de passe est défini dans l'une des catégories suivantes :

• l'annuaire du nuage IBM Verify
• un annuaire LDAP connecté via une instance Verify Bridge
• un système de gestion des appareils mobiles connecté (par exemple MaaS360 )

Le client API utilisé par l'application doit disposer des autorisations suivantes sur IBM Verify:

• Authentifier un utilisateur

L'application doit avoir acquis un jeton d'accès en utilisant le flux "Client Credentials " ou en initiant le flux "Policy-based Authentication".

Variables

Les variables suivantes sont nécessaires pour ce guide :

Déterminer l'identité ID source

Lors de l'appel de l'API d'authentification par mot de passe, l'ID de la source d'identité où le compte d'utilisateur existe doit être fourni. Il existe plusieurs moyens d'y parvenir, qui sont décrits dans les sections suivantes.

📘

Considération de la performance

Les identifiants des sources d'identité ne changent pas une fois qu'ils sont créés. Si l'application doit rechercher les identifiants des sources d'identité au moment de l'exécution, il convient de le faire une fois au démarrage de l'application plutôt que d'effectuer la recherche à chaque événement d'authentification.

Option 1 : ID codé en dur

Si tous les utilisateurs de l'application proviennent d'une seule source d'identité, l'ID de cette source peut être recherchée à l'aide de l'interface d'administration de Verify, puis fournie dans le cadre de l'initialisation de l'application (généralement sous la forme d'une propriété de configuration).

Option 2 : présenter les sources disponibles à l'utilisateur et lui permettre de choisir

Si le point de terminaison d'authentification par mot de passe est appelé avec un GET, il renvoie un tableau de toutes les sources d'identité disponibles pour l'authentification par mot de passe :

curl -X GET "https://${tenant_url}/v1.0/authnmethods/password" -H "Authorization: Bearer ${access_token}"

La réponse a le format suivant :

{
    "total": 3,
    "password": [
        {
            "name": "Cloud Directory",
            "location": "https://verifylab.verify.ibm.com/v1.0/authnmethods/password/10a9bc20-7511-47e0-b836-f6e18e31f978",
            "id": "10a9bc20-7511-47e0-b836-f6e18e31f978",
            "type": "ibmldap"
        },
        ...
    ],
    "limit": 200,
    "count": 200,
    "page": 1
}

Les sources d'identité sont renvoyées sous forme de tableau dans l'attribut password. Chaque membre du réseau a un name et un id. L'application pourrait présenter les noms des sources d'identité à l'utilisateur et utiliser l'identifiant associé lors de l'authentification par mot de passe.

Option 3 : Recherche d'une source d'identité par nom

Un filtre de recherche peut être spécifié dans la chaîne de requête de la demande GET adressée au point final d'authentification par mot de passe. Cette fonction peut être utilisée pour rechercher une source d'identité par son nom.

curl -X GET "https://${tenant_url}/v1.0/authnmethods/password?search=name%20%3D%20%22Cloud%20Directory%22" -H "Authorization: Bearer ${access_token}"

//Pre-requisites
//var axios = require('axios');
//var tenant_url = "Tenant URL";
//var access_token = "Access Token";
//var directory_name = "Cloud Directory";

var request = {
  method: 'get',
  url: 'https://' + tenant_url +
    '/v1.0/authnmethods/password?search=name = "' + directory_name + '"',
  headers: {
    'Authorization': 'Bearer ' + access_token
  }
};

axios(request).then((response) => {
  var idsource_id = response.data.password[0].id;
  console.log(idsource_id);

  //Next code here.

}).catch((error) => {
  console.log(error);
});

La réponse sera identique à la consultation sans filtre, mais le tableau password ne contiendra qu'un seul membre.

🚧

Identité Source Les noms peuvent changer

Le nom d'une source d'identité est un champ modifiable de la définition de la source d'identité. Si le nom d'une source d'identité est modifié, les applications effectuant une recherche par nom devront être mises à jour.

Option 4 : mise en œuvre de la cartographie à partir du nom d'utilisateur

S'il existe un moyen programmatique de déterminer la source d'identité correcte à partir du nom d'utilisateur (par exemple un préfixe ou un suffixe commun), l'application pourrait identifier la source d'identité de cette manière. Les identifiants des sources d'identité peuvent être codés en dur ou recherchés à l'aide des méthodes décrites ci-dessus.

Effectuer l'authentification

Lorsqu'une application a recueilli le nom d'utilisateur et le mot de passe de l'utilisateur, elle doit appeler le point de terminaison d'authentification du mot de passe pour vérifier s'il est valide.

curl -X POST "https://${tenant_url}/v1.0/authnmethods/password/${idsource_id}" -H "Authorization: Bearer ${access_token}" -H "Content-Type: application/json" --data-raw "{\"username\": \"${username}\",\"password\": \"${password}\"}"

//Pre-requisites
//var axios = require('axios');
//var tenant_url = "Tenant URL";
//var access_token = "Access Token";
//var idsource_id = "Identity Source ID";
//var username = "submitted username";
//var password = "submitted password"

var request = {
  method: 'post',
  url: 'https://' + tenant_url +
    '/v1.0/authnmethods/password/' + idsource_id,
  headers: {
    'Authorization': 'Bearer ' + access_token,
    'Content-Type': 'application/json'
  },
  data: {
    "username": username,
    "password": password
  }
};

axios(request).then((response) => {
  var user = response.data;
  console.log(JSON.stringify(user));

  //Successful authentication
  //Next code here

}).catch((error) => {
  if (error.response.status == 400
   && error.response.data) {
    var err = error.response.data;
    console.log(JSON.stringify(err));

    //Failed authentication
    //Next code here

  } else {
    console.log(error)
  }
});

Si l'authentification échoue, un état 400 est renvoyé. Dans ce cas, le corps de la réponse comprend un messageId qui peut être utilisé pour identifier le motif. Un messageDescription lisible par l'homme est également renvoyé :

{
  "messageId": "CSIBH0044E",
  "messageDescription": "The system cannot authenticate the user because the user name or password was incorrect."
}

Si l'authentification est réussie, un objet JSON contenant des informations sur l'utilisateur authentifié est renvoyé :

{
    "groups": [
        {
            "sourceId": "10a9bc20-7511-47e0-b836-f6e18e31f978",
            "displayName": "testgroup",
            "name": "6510001VZE"
        }
    ],
    "attributes": [
        {
            "values": [
                "[email protected]"
            ],
            "name": "email"
        },
        {
            "values": [
                "Demo User"
            ],
            "name": "name"
        },
        {
            "values": [
                "User"
            ],
            "name": "familyName"
        },
        {
            "values": [
                "Demo"
            ],
            "name": "givenName"
        },
        {
            "values": [
                "testuser"
            ],
            "name": "username"
        },
        {
            "values": [
                "cloudIdentityRealm"
            ],
            "name": "realm"
        },
        {
            "values": [
                "regular"
            ],
            "name": "userCategory"
        }
    ],
    "id": "651000TFPF"
}

L'application dispose maintenant d'informations de base sur l'utilisateur authentifié. Si un objet SCIM complet pour l'utilisateur est nécessaire, il peut être obtenu à partir du point final SCIM en utilisant le site id de l'objet utilisateur.

Renvoi d'une assertion JWT

Si la chaîne de requête returnJwt=true est ajoutée à la demande de validation de l'authentification, le JSON renvoyé à la suite d'une authentification réussie comprendra un attribut assertion qui contient un JWT attestant de la réussite de l'authentification.

Une application cliente peut l'utiliser pour exécuter un flux OAuth JWT Bearer afin d'obtenir un jeton d'accès pour l'utilisateur authentifié (dans le cadre d'un flux d' authentification basé sur une politique ).

jon Harry, IBM Sécurité