Configuration d'un agent d'identité pour l'authentification à l'aide de plusieurs sources d'attributs

Suivez cette procédure pour configurer un agent d'identité à l'aide d'attributs provenant de sources telles que LDAP, PostgreSQL,, Db2 et Oracle Database.

A propos de cette tâche

Une combinaison d'une ou plusieurs sources de données sur site peut être utilisée comme fournisseur d'identité unique pour IBM® Verify. Cette configuration permet à votre agent d'identité d'authentifier les utilisateurs et d'extraire leurs attributs à partir d'une ou plusieurs sources de données.

Les sources de données prises en charge par cette configuration sont les suivantes :
  • LDAP
  • IBM Db2
  • PostgreSQL
  • Oracle Database
Terminologie
Source d'authentification
La source de données sur laquelle vous souhaitez effectuer l'authentification.
JavaScript configuration
Un fichier de configuration sur site qui définit les détails de configuration de la source de données.
JavaScript module
Votre code permettant de gérer les interactions avec l' LDAP secondaire.
LDAP primaire
La gestion d' LDAP s est intégrée; aucun plug-in d' JavaScript n'est nécessaire pour l' LDAP principale.
Sources de données alternatives
Une ou plusieurs sources de données supplémentaires à utiliser en complément ou à la place de l' LDAP principale.
Remarque : il est possible d'utiliser jusqu'à 10 sources de données dans n'importe quel ordre, mais la configuration de l' LDAP e principale et celle des sources de données secondaires diffèrent.

Procédure

  1. Sélectionnez Intégrations > Agents d'identité.
  2. Sélectionnez « Créer une configuration d'agent ».
  3. Sélectionnez « Authentification » comme motif.
  4. Sélectionnez la vignette « LDAP ».
  5. Cliquez sur Suivant.
  6. Configurer les paramètres de connexion
    Indiquez les informations suivantes pour définir les propriétés de connexion LDAP :
    Remarque : l' LDAP e principale est facultative et ne doit pas nécessairement servir de source d'authentification. Si vous ne souhaitez pas utiliser d' LDAP principale, indiquez des valeurs fictives dans cette section. Si vous choisissez de ne pas utiliser d' LDAP principal, vous devez indiquer le code suivant dans l'une de vos configurations d' JavaScript.
    "authenticationSource":{
    "isAuthenticationSource": false,
          "disablePrimaryLDAPLookup": false
        },
    
    URI de l'hôte LDAP externe
    Cet attribut correspond aux informations de connexion du serveur LDAP sur site. Pour une configuration de reprise en ligne LDAP de cluster, vous pouvez ajouter plusieurs URI de serveur LDAP en sélectionnant Ajouter un URI.
    Base
    Cet attribut est la base de recherche de conteneur LDAP pour les utilisateurs.
    Nom distinctif de liaison LDAP
    Cet attribut est l'utilisateur de connexion au serveur LDAP.
    Mot de passe de liaison LDAP
    Cet attribut est le mot de passe de connexion au serveur LDAP.
    Certificat d'autorité de certification LDAP
    Cet attribut facultatif est le certificat SSL utilisé si l'agent sur site nécessite une connexion TLS au serveur LDAP.
    Afficher les paramètres supplémentaires
    Vous pouvez définir les paramètres suivants.
    • Indiquez si LDAP requiert TLS.
    • Nombre maximal de connexions LDAP simultanées pour le serveur LDAP.
    • Combien de temps une authentification par mot de passe réussie est-elle mise en cache?
    • Durée de maintien de la connexion.
    • Délai d'inactivité avant la fermeture d'une connexion par le serveur LDAP.
    • Durée maximale de traitement d'une demande.
  7. Cliquez sur Suivant.
  8. Indiquez les propriétés utilisateur.
    Attributs
    Cet attribut est une liste d'attributs utilisateur LDAP séparés par des virgules qui sont renvoyés par une opération de vérification de mot de passe réussie. Pour les attributs d' LDAP s primaires, utilisez le nom d'attribut « LDAP ». Pour les sources de données alternatives, faites précéder le nom des attributs utilisateur du nom du plug-in JavaScript censé renvoyer ces attributs au format pluginName-Attribute.. Par exemple, si vous définissez
    "pluginName": "OcPlug",
    OcPlug alors tous les attributs renvoyés par doivent être précédés du préfixe OcPlug-. Par exemple, OcPlugin-mobile cela demande au plug-in OcPlug « JavaScript » de récupérer la valeur «mobile».
    Les attributs doivent être séparés par des virgules. Par exemple :
    givenName, sh, displayName, manager, mail, mobile,
    memberOf, uid, OcPlug-OCD_SPEC_ID, db2PLUG-
    XTENDEDATTR, ldap-seeAlso
    Remarque : cet exemple montre comment définir les attributs d'un plug-in. Les attributs sans préfixe tels que givenName, sn, displayName, manager, mail, mobile memberOf,, et uid proviennent de la source principale LDAP. OcPlug renvoie l'attribut OCD_SPEC_ID, « db2Plug » renvoie l'attribut XTENDEDATTR et le module «ldap» renvoie l'attribut seeAlso.
    Attributs binaires
    Cet attribut est une liste d'attributs utilisateur LDAP binaires séparés par des virgules qui sont renvoyés par une opération de vérification de mot de passe réussie.
    Attribut du nom d'utilisateur
    Cet attribut est l'attribut de dénomination tel que user id qui est utilisé pour rechercher un utilisateur pour la vérification des mots de passe.
    Remarque : les attributs d'identification des noms d'utilisateur sont sensibles à la casse. L'attribut samAccountName par défaut s'applique aux versions antérieures de Windows Active Directory. Pour les versions 2016 et ultérieures d' Active Directory, l'attribut est sAMAAccountName.
    Classe d'objets
    Cet attribut est une liste de classes d'objets séparées par des virgules que l'utilisateur LDAP peut détenir. Les classes d'objets sont utilisées avec l'attribut username pour rechercher un utilisateur pour la vérification des mots de passe.
    Remarque : les attributs binaires, les attributs de nom d'utilisateur et les classes d'objets sont destinés à l' LDAP principale, mais sont tous transmis aux plug-ins d' JavaScript s et doivent être gérés manuellement par l'implémentation du plug-in.
  9. Cliquez sur Suivant.
  10. Mettez en correspondance les attributs du fournisseur d'identité avec ceux Verify de Cloud Directory.
    Une fois l'agent d'identité créé, vous pouvez modifier ou mettre à jour les mappages à l'aide de la fonction icône du crayon d'édition située sur la vignette de l'agent.
  11. Cliquez sur Suivant.
  12. Dans la section « Finaliser la configuration », indiquez les informations suivantes.
    • Un nom unique et reconnaissable pour l'agent
    • Une description
    • Un nom d'affichage pour le fournisseur d'identité
    • Un domaine pour le fournisseur d'identité
  13. Facultatif : sélectionnez « Afficher les paramètres avancés » pour ajouter des attributs de configuration ou pour sélectionner un certificat de chiffrement.
    Remarque : les paramètres avancés sont destinés à être utilisés par l' LDAP principal, mais ils sont transmis aux plug-ins d' JavaScript s et mis à leur disposition pour un traitement manuel.
  14. Cliquez sur « Enregistrer » puis sur « Continuer ».
  15. Dans la section « Étapes suivantes », procédez comme suit.
    1. Sélectionnez « Afficher les identifiants API » et utilisez l'icône « Copier dans le presse-papiers » pour copier et enregistrer l'ID client et la clé secrète.
      Remarque : seuls les utilisateurs disposant des autorisations nécessaires peuvent voir le secret client. Pour plus d'informations, consultez la section « Mises à jour de sécurité pour les droits d'accès ».
    2. Si ce n'est pas déjà fait, téléchargez l'agent Bridge depuis le référentiel de conteneurs d' IBM (ICR). Consultez la section « Installation et configuration de Verify Bridge » sur Docker.
    3. Ajoutez vos données d'identification de l'API à la configuration de l'agent.
  16. Cliquez sur Terminer.
    La configuration est ajoutée aux agents d'identité et le fournisseur d'identité apparaît dans la section Authentification > Fournisseurs d'identité.
  17. Configuration des modules complémentaires d' JavaScript.
    Le fichier exécutable « bridge » effectue une recherche dans les répertoires suivants, par rapport à son emplacement.
    • ./jsconfig/ - L'emplacement des fichiers de configuration.
    • ./jsplugins/ - L'emplacement des plug-ins d' JavaScript.

    Pour rendre ces répertoires accessibles à un conteneur Docker, vous pouvez effectuer un montage lié à partir du système de fichiers de l'hôte.

    volumes:
                    - ./jsconfig:/go/src/jsconfig:ro
                    - ./jsplugins:/go/src/jsplugins:ro
    
    Cet exemple présente la configuration d'un plug-in de base de données pour l' Oracle.
    {
        "pluginName": "OcPlug",
        "pluginType": "oracledb",
        "executionOrder": 1,
        "hardFail": true,
        "authenticationSource": {
          "isAuthenticationSource": true,
          "disablePrimaryLDAPLookup": false
        },
        "bindingConfig": {
          "connectionString": "oracle://system:oraclepass@host.docker.internal:1521/XE?CONNECTION TIMEOUT=5",
          "maxPoolSize": 50,
          "minPoolSize": 10,
          "agedTimeout": 60,
          "maxIdleTime": 10
        },
        "custom": {
          "table": "users"
        }
      }
    
    L'exemple suivant présente une configuration pour un module complémentaire d' LDAP.
    {
        "pluginName": "plugin1",
        "pluginType": "ldap",
        "executionOrder": 1,
        "hardFail": false,
        "authenticationSource": {
          "isAuthenticationSource": true,
          "disablePrimaryLDAPLookup": false
        },
        "bindingConfig": {
          "bindDn": "cn=admin,dc=ibm,dc=com",
          "bindPassword": "pass",
          "uris": [
            "ldaps://localhost:8636",
            "ldap://localhost:8389"
          ],
          "maxPoolSize": 50,
          "agedTimeout": 60,
          "connectTimeout": 5,
          "filter": "(|(|(objectclass=ePerson)(objectclass=person))(objectclass=User))", 
          "userObjectClasses": "top,Person,organizationalPerson,inetOrgPerson",
          "selector": "objectClass,cn,sn,givenName,userPassword,streetAddress,seeAlso,mobile", 
          "userIdentifier": "uid",
          "baseDn": "dc=ibm,dc=com",
          "tlsConfig": {
            "caCert": "-----BEGIN CERTIFICATE-----\nMIIDbzCCAlegAwIBAgIULjAe6hySQZ8C8d1LnWKHlpirro4wDQYJKoZIhvcNAQEL\nBQAwRzELMAkGA1UEBhMC…",
            "insecureSkipVerify": false,
            "tlsMinVersion": 0,
            "clientCertLabel": "extauthn.client"
          }
        },
        "custom": {
          "table": "users"
        }
      }
    

    Le tableau présente les propriétés du module d'extension de configuration.

    Propriété Définition
    pluginName Le nom du plug-in. Le pont recherche ./jsplugins/<pluginName>.js ce fichier par rapport à l'exécutable du pont.
    pluginType
    • OracleDB
    • postgres
    • Db2
    • ldap
    Ordonnance d'exécution L'ordre dans lequel le plug-in s'exécute. Du plus bas au plus élevé.
    hardFail falseSi une erreur survient lors de la récupération des attributs, Bridge ignore ce plug-in. Sinon, une erreur est renvoyée et l'authentification échoue
    isAuthenticationSource Sélectionnez cette option true si l'authentification s'effectue au niveau de ce plug-in.
    Remarque : si vous définissez cette propriété sur true , le plug-in se bloque immédiatement.
    disablePrimaryLDAPLookup Désactive l' LDAP principale.
    connectionString La chaîne de connexion appropriée pour votre base de données. Il s'applique à
    • Db2
    • PostgreSQL
    • Oracle Database.

    Ne rien indiquer pour « LDAP ».

    LDAP uniquement
    filtre LDAP filtres.
    bindDn Le DN de liaison.
    bindPassword Le mot de passe de liaison.
    uris LDAP URI. Vous pouvez définir plusieurs scénarios de basculement. Indiquez le protocole ldaps pour l' TLS
    userObjectClasses Sélecteurs d'objets utilisateur.
    sélecteur Sélecteurs. Les attributs utilisateur souhaités doivent apparaître ici.
    userIdentifier Identifiant utilisé lors d'une recherche standard.
    baseDn L'emplacement dans la hiérarchie des répertoires à partir duquel la recherche commence.
    caCert Le certificat d'autorité de certification (CA) utilisé pour valider le certificat présenté par le serveur LDAP.
    insecureSkipVerify Ignorer les vérifications de certificats d' TLS.
    tlsMinVersion

    Version TLS minimale

    • 769 – v1.0
    • 770 – v.1.1
    • 771 – v1.2 (par défaut)
    • 772 – v1.3
    clientCertLabel

    Pour MTLS. C'est l'identifiant du certificat et de la clé utilisés pour signer le trafic qui est transmis au serveur LDAP.

    L'agent recherche le certificat à l'adresse

    /cert/<clientCertLabel>_cert.pem /cert/<clientCertLabel>_key.pem

    personnalisé Les valeurs personnalisées qui peuvent être transmises au plug-in via la configuration en vue d'un traitement manuel.
    Exemples de chaînes de connexion.
    Db2
    HOSTNAME=host.docker.internal;PORT=50000;UID=db2inst1;PWD=db2_password;DATABASE=usersdb"
    PostgreSQL
    host=host.docker.internal port=8788 dbname=postgres user=postgres password=postgrespassword connect_timeout=5
    LDAP TLS
    caCert.Pour utiliser TLS afin de vous connecter à LDAP via un plug-in JavaScript, veillez à indiquer le ldaps:// dans la uris section et à spécifier un valide.
    "uris": [
            "ldaps://localhost:8636"
          ],
    
    Pour exécuter MTLS à partir d'un plug-in d' LDAP, vous pouvez placer le certificat client et la clé privée du certificat client dans le /cert/ répertoire de votre conteneur à l'aide de montages liés.
    - ./cert/:/cert:ro
    Assurez-vous que les noms des certificats respectent le format <clientCertLabel>_cert.pem et <clientCertLabel>_key.pem, où clientCertLabel correspond à clientCertLabel la valeur spécifiée dans la configuration du plug-in pour les plug-ins LDAP.