Authentification par mot de passe

Introduction

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

Prérequis

Un utilisateur final peut s'authentifier à l'aide de la validation de mot de passe s'il dispose d'un compte avec un mot de passe défini dans l'un des éléments suivants :

• l'annuaire cloud IBM Security 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 dans IBM Security Verify :

• Authentifier tout utilisateur

L'application doit avoir acquis un jeton d'accès en utilisant le flux Client Credentials ou en initiant le flux Authentification basée sur des politiques.

Variables

Les variables suivantes sont nécessaires pour ce guide :

Déterminer l'ID de source d'identité

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

📘

Considération de performance

Les ID de source d'identité ne changent pas une fois qu'ils sont créés. Si l'application recherchera les ID de source d'identité à l'exécution, cela devrait être fait 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é en utilisant l'interface d'administration Verify et ensuite fourni dans le cadre de l'initialisation de l'application (généralement comme 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 retournera un tableau de toutes les sources d'identité qui sont disponibles pour l'authentification basée sur 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 retournées comme un tableau dans l'attribut password. Chaque membre du tableau a un name et un id. L'application pourrait présenter les noms de sources d'identité à l'utilisateur et utiliser l'id associé lors de l'exécution de l'authentification par mot de passe.

Option 3 : Rechercher la source d'identité par nom

Un filtre de recherche peut être spécifié dans la chaîne de requête de la requête GET au point de terminaison d'authentification par mot de passe. Cela peut être utilisé pour rechercher une source d'identité par nom.

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

//Prérequis
//var axios = require('axios');
//var tenant_url = "URL du locataire";
//var access_token = "Jeton d'accès";
//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);

  //Code suivant ici.

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

La réponse sera la même que la recherche sans le filtre mais le tableau password ne contiendra qu'un seul membre.

🚧

Les noms de source d'identité peuvent changer

Le nom d'une source d'identité est un champ modifiable de la définition de 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 : Implémenter le mappage depuis le 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 suffixe commun), l'application pourrait identifier la source d'identité de cette façon. Les ID de source d'identité pourraient être codés en dur ou recherchés en utilisant les méthodes décrites ci-dessus.

Effectuer l'authentification

Une fois qu'une application a collecté le nom d'utilisateur et le mot de passe de l'utilisateur, elle doit appeler le point de terminaison d'authentification par 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}\"}"

//Prérequis
//var axios = require('axios');
//var tenant_url = "URL du locataire";
//var access_token = "Jeton d'accès";
//var idsource_id = "ID de source d'identité";
//var username = "nom d'utilisateur soumis";
//var password = "mot de passe soumis"

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));

  //Authentification réussie
  //Code suivant ici

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

    //Authentification échouée
    //Code suivant ici

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

Si l'authentification échoue, un statut 400 est retourné. Dans ce cas, le corps de la réponse inclut un messageId qui peut être utilisé pour identifier la raison. Une messageDescription lisible par l'homme est également retournée :

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

Si l'authentification réussit, un objet JSON qui contient certaines informations sur l'utilisateur authentifié est retourné :

{
    "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 a maintenant des informations de base pour l'utilisateur authentifié. Si un objet SCIM complet pour l'utilisateur est requis, cela peut être obtenu du point de terminaison SCIM en utilisant l'id de l'objet utilisateur.

Retourner une assertion JWT

Si la chaîne de requête returnJwt=true est ajoutée à la requête de validation d'authentification, le JSON retourné après une authentification réussie inclura un attribut assertion qui contient un JWT qui affirme l'authentification réussie.

Un client d'application peut utiliser cela pour exécuter un flux OAuth JWT Bearer pour obtenir un jeton d'accès pour l'utilisateur authentifié (dans le cadre d'un flux Authentification basée sur des politiques).

💎

Jon Harry, IBM Security