Esta guía explica el uso de las opciones de autenticación con el controlador C de MongoDB. Asegúrese de que el servidor MongoDB también esté configurado correctamente para la autenticación antes de establecer una conexión. Para obtener más información, consulte Documentación de seguridad de MongoDB.
El controlador C de MongoDB admite varios mecanismos de autenticación mediante el uso de URI de conexión de MongoDB.
De forma predeterminada, si se proporcionan un nombre de usuario y una contraseña como parte de la cadena de conexión (y una base de datos de autenticación opcional), se utilizan para conectarse a través del mecanismo de autenticación predeterminado del servidor.
Para seleccionar un mecanismo de autenticación específico distinto del predeterminado, consulte la lista de mecanismos compatibles a continuación.
mongoc_client_t *client = mongoc_client_new ("mongodb://user:password@localhost/?authSource=mydb");
Los valores admitidos actualmente para la opción de cadena de conexión authMechanism son:
Autenticación básica (SCRAM-SHA-256)
MongoDB 4.0 introduce compatibilidad con la autenticación mediante el protocolo SCRAM con el hash SHA- más seguro256 descrito en la RFC. Usar este mecanismo 7677de autenticación significa que la contraseña nunca se envía por cable durante la autenticación, sino que se calcula como una prueba de que la contraseña del cliente coincide con la que conoce el servidor. En MongoDB.,4 0el controlador C puede determinar el mecanismo de autenticación predeterminado correcto para usuarios con1 256 credenciales SCRAM-SHA- y SCRAM-SHA- almacenadas:
mongoc_client_t *client = mongoc_client_new ("mongodb://user:password@localhost/?authSource=mydb"); /* the correct authMechanism is negotiated between the driver and server. */
Alternativamente, SCRAM-SHA-256 se puede especificar explícitamente como un mecanismo de autenticación.
mongoc_client_t *client = mongoc_client_new ("mongodb://user:password@localhost/?authMechanism=SCRAM-SHA-256&authSource=mydb");
Autenticación básica (SCRAM-SHA-1)
El mecanismo de autenticación predeterminado antes de MongoDB 4.0 es SCRAM-SHA-1 (RFC 5802). El uso de este mecanismo de autenticación significa que la contraseña nunca se envía realmente a través de la red durante la autenticación, sino que es una prueba calculada de que la contraseña del cliente es la misma que la contraseña que conoce el servidor.
mongoc_client_t *client = mongoc_client_new ("mongodb://user:password@localhost/?authMechanism=SCRAM-SHA-1&authSource=mydb");
Nota
SCRAM-SHA-1 Se autentica en la base de datos admin de forma predeterminada. Si el usuario se crea en otra base de datos, se requiere especificar la fuente de autenticación.
Autenticación heredada (MONGODB-CR)
El mecanismo de autenticación de MONGODB-CR está obsoleto y ya no funcionará en MongoDB 4.0. En su lugar, no especifique ningún mecanismo de autenticación y el controlador utilizará un mecanismo de autenticación compatible con su servidor.
Autenticación GSSAPI (Kerberos)
Nota
En entornos similares a UNIX, la compatibilidad con Kerberos requiere compilar el controlador contra cyrus-sasl.
En Windows, la compatibilidad con Kerberos requiere compilar el controlador con Windows Native SSPI o cyrus-sasl. La configuración predeterminada del controlador utilizará Windows Native SSPI.
Para modificar la configuración predeterminada, utilice la opción cmake ENABLE_SASL.
GSSAPI (Kerberos) La autenticación está disponible en la edición Enterprise de MongoDB. Para autenticarte con GSSAPI, el controlador C de MongoDB debe estar instalado con soporte para SASL.
En entornos similares a UNIX, ejecute el comando kinit antes de utilizar los siguientes métodos de autenticación:
$ kinit mongodbuser@EXAMPLE.COM mongodbuser@EXAMPLE.COM's Password: $ klistCredentials cache: FILE:/tmp/krb5cc_1000 Principal: mongodbuser@EXAMPLE.COM Issued Expires Principal Feb 9 13:48:51 2013 Feb 9 23:48:51 2013 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Ahora, la autenticación se realiza mediante la URI de MongoDB. seGSSAPI autentica con la $external base de datos virtual, por lo que no es necesario especificar una base de datos en la URI. Tenga en cuenta que el principal de Kerberos debe estar codificado en URL:
mongoc_client_t *client; client = mongoc_client_new ("mongodb://mongodbuser%40EXAMPLE.COM@mongo-server.example.com/?authMechanism=GSSAPI");
Nota
GSSAPI se autentica contra la base de datos $external, por lo que no es necesario especificar la base de datos authSource.
El controlador admite estas propiedades GSSAPI:
CANONICALIZE_HOST_NAMEEsto podría ser necesario con Cyrus-SASL cuando los hosts informan nombres de host diferentes a los utilizados en la base de datos Kerberos. El valor predeterminado es "false".SERVICE_NAME: Utilice un nombre de servicio diferente al predeterminado, "mongodb".
Establece propiedades en la URL:
mongoc_client_t *client; client = mongoc_client_new ("mongodb://mongodbuser%40EXAMPLE.COM@mongo-server.example.com/?authMechanism=GSSAPI&" "authMechanismProperties=SERVICE_NAME:other,CANONICALIZE_HOST_NAME:true");
Si encuentra errores como Invalid net address, compruebe si la aplicación está protegida por un firewall NAT (Traducción de Direcciones de Red). De ser así, cree un ticket que use los tickets Kerberos forwardable y addressless. Esto se puede hacer pasando -f -A a kinit.
$ kinit -f -A mongodbuser@EXAMPLE.COM
Autenticación simple SASL
Nota
El controlador C de MongoDB debe compilarse con soporte SASL para poder utilizar la autenticación SASL PLAIN.
MongoDB Enterprise Edition admite el mecanismo de autenticación SASL PLAIN, inicialmente diseñado para delegar la autenticación a un servidor LDAP. El uso del mecanismo SASL PLAIN es muy similar al mecanismo de desafío-respuesta con nombres de usuario y contraseñas. Este mecanismo de autenticación utiliza la base de datos virtual $external para la compatibilidad con LDAP:
Nota
SASL PLAIN Es un mecanismo de autenticación de texto sin cifrar. Se recomienda encarecidamente conectarse a MongoDB mediante TLS con validación de certificado al usar el mecanismo PLAIN.
mongoc_client_t *client; client = mongoc_client_new ("mongodb://user:password@example.com/?authMechanism=PLAIN");
PLAIN se autentica contra la base de datos $external, por lo que no es necesario especificar la base de datos authSource.
X.509 Autenticación de certificado
Nota
El controlador C de MongoDB debe compilarse con compatibilidad con TLS para la autenticación X.509. Una vez hecho esto, inicie un servidor con las siguientes opciones:
$ mongod --tlsMode requireTLS --tlsCertificateKeyFile server.pem --tlsCAFile ca.pem
El mecanismo MONGODB-X509 autentica un nombre de usuario derivado del nombre de sujeto distinguido del certificado X.509 presentado por el controlador durante la negociación TLS. Este método de autenticación requiere el uso de conexiones TLS con validación de certificados.
mongoc_client_t *client; mongoc_ssl_opt_t ssl_opts = { 0 }; ssl_opts.pem_file = "mycert.pem"; ssl_opts.pem_pwd = "mycertpassword"; ssl_opts.ca_file = "myca.pem"; ssl_opts.ca_dir = "trust_dir"; ssl_opts.weak_cert_validation = false; client = mongoc_client_new ("mongodb://x509_derived_username@localhost/?authMechanism=MONGODB-X509"); mongoc_client_set_ssl_opts (client, &ssl_opts);
MONGODB-X509 Se autentica en la $external base de datos, por lo que no es necesario especificar la base de datos authSource. Para más información sobre x509_derived_username, consulte el 509 tutorial del servidor MongoDB x..
Nota
El controlador C de MongoDB intentará determinar el nombre de usuario derivado de x509 cuando no se proporciona ninguno y, a partir de MongoDB 3.4, no es necesario proporcionar el nombre de usuario en absoluto.
Autenticación a través de AWS IAM
El mecanismo MONGODB-AWS se autentica en los servidores MongoDB con credenciales proporcionadas por AWS Identity and Access Management (IAM).
Para autenticarse, cree un usuario con un nombre de recurso de Amazon (ARN) asociado en la base de datos $external y especifique MONGODB-AWS authMechanism en la URI.
mongoc_uri_t *uri = mongoc_uri_new ("mongodb://localhost/?authMechanism=MONGODB-AWS");
Dado que MONGODB-AWS siempre se autentica contra la base de datos $external, no es necesario especificar la base de datos authSource.
Las credenciales incluyen el access key id, secret access key y el session token opcional. Estos pueden obtenerse de las siguientes maneras.
Credenciales de AWS a través de URI
Las credenciales se pueden pasar directamente en la URI como nombre de usuario/contraseña.
mongoc_uri_t *uri = mongoc_uri_new ("mongodb://<access key id>:<secret access key>localhost/?authMechanism=MONGODB-AWS");
Esto puede incluir un session token pasado con authMechanismProperties.
mongoc_uri_t *uri = mongoc_uri_new ("mongodb://<access key id>:<secret access key>localhost/?authMechanism=MONGODB-AWS&authMechanismProperties=AWS_SESSION_TOKEN:<token>");
Credenciales de AWS a través del entorno
Si las credenciales no se pasan a través de la URI, libmongoc verificará las siguientes variables de entorno.
ID DE CLAVE DE ACCESO DE AWS
CLAVE DE ACCESO SECRETA DE AWS
AWS_SESSION_TOKEN (optional)
Credenciales de AWS a través de ECS
Si las credenciales no se pasan en la URI o con las variables de entorno, libmongoc verificará si la variable de entorno AWS_CONTAINER_CREDENTIALS_RELATIVE_URI está configurada y, de ser así, intentará recuperar las credenciales temporales de los metadatos de la tarea ECS consultando una dirección local de enlace.
Credenciales de AWS vía EC2
Si las credenciales no se pasan en la URI o con variables de entorno, y la variable de entorno AWS_CONTAINER_CREDENTIALS_RELATIVE_URI no está configurada, libmongoc intentará recuperar credenciales temporales de los metadatos de la máquina EC2 consultando las direcciones locales del enlace.