Configuración de un agente de identidad para la autenticación mediante el uso de varias fuentes de atributos

Siga este procedimiento para configurar un agente de identidad con atributos procedentes de fuentes como LDAP, PostgreSQL,, Db2 y Oracle Database.

Acerca de esta tarea

Se puede utilizar una combinación de una o varias fuentes de datos locales como único proveedor de identidades para IBM® Verify. Esta configuración permite que tu agente de identidad autentique y obtenga los atributos de los usuarios de una o varias fuentes de datos.

Las fuentes de datos compatibles con esta configuración son:
  • LDAP
  • IBM Db2
  • PostgreSQL
  • Oracle Database
Terminología
Origen de autenticación
La fuente de datos con la que se va a realizar la autenticación.
JavaScript configuración
Un archivo de configuración local que especifica los detalles de configuración de la fuente de datos.
JavaScript complemento
Tu código para gestionar la interacción con el servidor LDAP secundario.
LDAP de primaria
Incluye gestión integrada de « LDAP », por lo que no se necesita el complemento « JavaScript » para el sitio principal « LDAP ».
Fuentes de datos alternativas
Una o varias fuentes de datos adicionales que se utilizarán junto con la principal LDAP o en su lugar.
Nota: Se pueden utilizar hasta 10 fuentes de datos en cualquier orden, pero la configuración de la fuente de datos principal LDAP y la de las fuentes de datos alternativas es diferente.

Procedimiento

  1. Selecciona «Integraciones » > «Agentes de identidad ».
  2. Selecciona «Crear configuración de agente ».
  3. Selecciona «Autenticación» como finalidad.
  4. Selecciona el mosaico « LDAP ».
  5. Selecciona «Siguiente ».
  6. Configurar los ajustes de conexión
    Proporcione la información siguiente para definir las propiedades de conexión LDAP.
    Nota: El servidor de autenticación principal LDAP es opcional y no es necesario que sea la fuente de autenticación. Si no deseas utilizar un « LDAP » principal, introduce valores ficticios en esta sección. Si decides no utilizar un servidor de dominios de primer nivel ( LDAP ), debes especificar el siguiente código en una de tus configuraciones de servidor de dominios de segundo nivel ( JavaScript ).
    "authenticationSource":{
    "isAuthenticationSource": false,
          "disablePrimaryLDAPLookup": false
        },
    
    URI de host de LDAP externo
    Este atributo es la información de conexión del servidor LDAP local. Para una configuración de migración tras error de LDAP de clúster, puede añadir varios URI de servidor LDAP seleccionando Añadir URI.
    Base
    Este atributo es la base de búsqueda del contenedor de LDAP para los usuarios.
    DN de enlace de LDAP
    Este atributo es el usuario de conexión del servidor LDAP.
    Contraseña de enlace LDAP
    Este atributo es la contraseña de conexión del servidor LDAP.
    Certificado de autoridad emisora de certificados LDAP
    Este atributo opcional es el certificado SSL que se utiliza si el agente local requiere una conexión TLS con el servidor LDAP.
    Ver valores adicionales
    Puede definir los valores siguientes.
    • Habilite si LDAP requiere TLS.
    • El número máximo de conexiones LDAP simultáneas para el servidor LDAP.
    • Cuánto tiempo se almacena en caché una autenticación de contraseña correcta.
    • Cuánto tiempo se mantiene la conexión.
    • El tiempo de inactividad antes de que el servidor LDAP cierre una conexión.
    • El tiempo máximo para procesar una solicitud.
  7. Haga clic en Siguiente.
  8. Proporcione las propiedades de usuario.
    Atributos
    Este atributo es una lista de los atributos de usuario de LDAP separados por comas que se devuelven de una operación de verificación de contraseña satisfactoria. Para los atributos de « LDAP » (primarios), utiliza el nombre de atributo « LDAP ». En el caso de fuentes de datos alternativas, antepone al nombre de los atributos de usuario el nombre del complemento « JavaScript », que se espera que devuelva los atributos en el formato pluginName-Attribute.. Por ejemplo, si establece que
    "pluginName": "OcPlug",
    entonces cualquier atributo que devuelva el OcPlug debe ir precedido del prefijo OcPlug-. Por ejemplo, OcPlugin-mobile indica al complemento OcPlug « JavaScript » que recupere el valor «mobile».
    Los atributos deben estar separados por comas. Por ejemplo:
    givenName, sh, displayName, manager, mail, mobile,
    memberOf, uid, OcPlug-OCD_SPEC_ID, db2PLUG-
    XTENDEDATTR, ldap-seeAlso
    Nota: El ejemplo muestra cómo especificar los atributos de un complemento. Los atributos sin prefijo, como givenName, sn, displayName, manager, mail, mobile memberOf,, y uid , proceden del archivo principal LDAP. OcPlug devuelve el atributo OCD_SPEC_ID« db2Plug », devuelve el atributo XTENDEDATTR «» y el complemento «ldap» devuelve el atributo seeAlso«».
    Atributos binarios
    Este atributo es una lista de los atributos de usuario de LDAP binarios separados por comas que se devuelven de una operación de verificación de contraseña satisfactoria.
    Atributo de nombre de usuario
    Este atributo es el atributo de denominación, como por ejemplo user id, que se utiliza para buscar un usuario para la verificación de contraseña.
    Nota: Los atributos de identificación de usuario distinguen entre mayúsculas y minúsculas. El atributo samAccountName predeterminado se aplica a las versiones anteriores de Windows Active Directory. En « Active Directory » de 2016 y versiones posteriores, el atributo es sAMAAccountName.
    Clase de objeto
    Este atributo es una lista de clases de objeto separadas por comas que el usuario de LDAP puede tener. Las clases de objeto se utilizan con el atributo username para buscar un usuario para la verificación de contraseña.
    Nota: Los atributos binarios, los atributos de nombre de usuario y las clases de objetos están pensados para el servidor principal ( LDAP ), pero se transmiten a los complementos del servidor secundario ( JavaScript ) y deben gestionarse manualmente en la implementación del complemento.
  9. Selecciona «Siguiente ».
  10. Asigna los atributos del proveedor de identidades a los Verify atributos de Cloud Directory.
    Una vez creado el agente de identidad, puedes modificar o actualizar las asignaciones mediante la función icono de lápiz de edición de la ficha del agente.
  11. Selecciona «Siguiente ».
  12. En «Finalizar configuración», introduzca la siguiente información.
    • Un nombre exclusivo y reconocible para el agente
    • Descripción
    • Un nombre para mostrar del proveedor de identidades
    • Un dominio para el proveedor de identidad
  13. Opcional: Selecciona «Ver configuración avanzada » para añadir atributos de configuración o para seleccionar un certificado para el cifrado.
    Nota: La configuración avanzada está pensada para que la utilice el servidor principal LDAP, pero se transmite a los complementos JavaScript y se pone a su disposición para su procesamiento manual.
  14. Haz clic en «Guardar» y continúa.
  15. En «Próximos pasos», sigue estos pasos.
    1. Selecciona «Ver credenciales de la API» y utiliza el icono de copiar al portapapeles para copiar y guardar el ID de cliente y el secreto de cliente.
      Nota: Solo los usuarios con los permisos adecuados pueden ver el secreto del cliente. Para obtener más información, consulte las actualizaciones de seguridad para los derechos.
    2. Si aún no lo has descargado, descarga el agente Bridge del repositorio de contenedores de IBM (ICR). Consulte «Instalación y configuración de Verify Bridge» en Docker.
    3. Añada las credenciales de la API a la configuración del agente.
  16. Haz clic en «Finalizar ».
    La configuración se agrega a los agentes de identidad y el proveedor de identidad aparece en Autenticación > Proveedores de identidad.
  17. Configuración de los complementos de « JavaScript ».
    El ejecutable «bridge» busca en los siguientes directorios, relativos a su propia ubicación.
    • ./jsconfig/ - La ubicación de los archivos de configuración.
    • ./jsplugins/ - La ubicación de los complementos de « JavaScript ».

    Para que un contenedor de Docker pueda acceder a estos directorios, puedes realizar un montaje vinculado desde el sistema de archivos del host.

    volumes:
                    - ./jsconfig:/go/src/jsconfig:ro
                    - ./jsplugins:/go/src/jsplugins:ro
    
    Este ejemplo muestra la configuración del complemento para un complemento de base de datos de 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"
        }
      }
    
    El siguiente ejemplo muestra una configuración para un complemento de 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"
        }
      }
    

    En la tabla se enumeran las propiedades del complemento de configuración.

    Propiedad Definición
    pluginName El nombre del complemento. El puente busca ./jsplugins/<pluginName>.js este archivo en relación con el ejecutable del puente.
    pluginType
    • OracleDB
    • postgres
    • Db2
    • ldap
    Orden de ejecución El orden en el que se ejecuta el complemento. De menor a mayor.
    hardFail falseEn ese caso, Bridge omite este complemento si se produce un error al recuperar los atributos. De lo contrario, se devuelve un error y la autenticación falla
    isAuthenticationSource Selecciona esta opción true si la autenticación se lleva a cabo en este complemento.
    Nota: Si se establece esta propiedad en true , el complemento entrará automáticamente en estado de fallo grave.
    disablePrimaryLDAPLookup Desactiva el servidor de dominios de primer nivel LDAP.
    connectionString La cadena de conexión adecuada para tu base de datos. Es aplicable a
    • Db2
    • PostgreSQL
    • Oracle Database.

    Déjelo en blanco para « LDAP ».

    Solo LDAP
    filtro LDAP filtros.
    bindDn El DN de enlace.
    bindPassword La contraseña de enlace.
    URI LDAP URI. Se pueden especificar varios para situaciones de conmutación por error. Especifica el protocolo ldaps para TLS.
    userObjectClasses Seleccionadores de objetos de usuario.
    Selector Selectores. Los atributos de usuario que desees deben aparecer aquí.
    userIdentifier Identificador que se utiliza al realizar una búsqueda estándar.
    baseDn La ubicación en la jerarquía de directorios desde donde comienza la búsqueda.
    caCert El certificado de CA que se utiliza para validar el certificado presentado por el servidor LDAP.
    insecureSkipVerify Omitir las comprobaciones de certificados de TLS.
    tlsMinVersion

    Versión mínima de TLS

    • 769 – v1.0
    • 770 – v.1.1
    • 771 – v1.2 (predeterminado)
    • 772 – v1.3
    clientCertLabel

    Para MTLS. Es la etiqueta del certificado y la clave que se utiliza para firmar el tráfico que se envía al servidor LDAP.

    El agente busca el certificado en

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

    personalizado Los valores personalizados que se pueden pasar al complemento a través de la configuración para su procesamiento manual.
    Ejemplos de cadenas de conexión.
    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.Para utilizar TLS para conectarse a LDAP a través de un complemento de JavaScript, asegúrate de especificar el ldaps:// en la uris sección y de indicar una válida.
    "uris": [
            "ldaps://localhost:8636"
          ],
    
    Para ejecutar MTLS desde un complemento de LDAP, puedes colocar el certificado de cliente y la clave privada del certificado de cliente en el /cert/ directorio de tu contenedor utilizando montajes vinculados.
    - ./cert/:/cert:ro
    Asegúrate de que los nombres de los certificados tengan el formato <clientCertLabel>_cert.pem y <clientCertLabel>_key.pem, donde clientCertLabel es el clientCertLabel especificado en la configuración del complemento para los complementos de LDAP.