6.2.10. Tipos de autenticación

<< Prev   Next >>

6.2.10.1. Información general

Autenticación - comprobación de que el identificador presentado (nombre) pertenece a un usuario específico del sistema, comprobación de la autenticación. El sistema "1C:Enterprise" admite varias variantes de autenticación diferentes, que se analizarán en las siguientes secciones.

6.2.10.2. Autenticación por los medios del sistema "1C:Enterprise"

Un usuario puede ser autenticado por el sistema "1C:Enterprise" ingresando su nombre y contraseña (en el diálogo de autenticación, como parámetros de la línea de comandos o como una línea de conexión con la base de información para una conexión exterior o un servidor de automatización). En este caso, el sistema "1C:Enterprise" comprueba la presencia del usuario y la corrección de la introducción de su contraseña.

6.2.10.3. Autenticación de sistema operativo

El usuario puede ser autenticado implícitamente por medios del sistema operativo. Para ello, el usuario debe estar asociado a algún usuario del sistema operativo. Cuando se inicia el sistema, "1C:Enterprise" le solicita al sistema operativo el usuario que actualmente está autenticado en el sistema. Para hacerlo, en el sistema operativo Windows se usa la interfaz SSPI y en el sistema operativo Linux se usa GSS-API. A continuación se verifica que el usuario de "1C:Enterprise" esté asociado a este usuario del sistema operativo. Si la búsqueda finaliza correctamente se considera, que el usuario del sistema "1C:Enterprise" se ha autenticado correctamente y no se muestra el diálogo de autenticación.

El usuario del sistema operativo se especifica en el formato: \\domain_name\username. En este caso, el nombre de usuario no debe contener caracteres de alfabetos distintos al alfabeto latino. El formato del nombre de dominio y el nombre de usuario puede depender de los ajustes del controlador de dominio y las cuentas en él. El nombre correcto del usuario del sistema operativo se puede encontrar en los registros del evento CONN del registro tecnológico en el atributo Txt, que comienza con el texto Srvr: DstUserName2:. Por ejemplo, el evento 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) significa que como el nombre de usuario del sistema operativo en la descripción del usuario de la base de información debe contener \\d1.d2\user1.

Si se necesita forzar la autenticación mediante los medios del sistema "1C:Enterprise", se debe especificar el parámetro de línea de comandos /WA- en la línea de comandos para iniciar la aplicación de cliente. En consecuencia, el parámetro de la línea de comandos /WA+ está destinado a forzar la autenticación por medios del sistema operativo (actúa de manera predeterminada).

Consulte también:

• Registro tecnológico.

6.2.10.4. Autenticación con la ayuda de OpenID

OpenID (https://openid.net/) - es un protocolo que permite a un usuario usar una sola cuenta para la autenticación en múltiples recursos, sistemas, etc., no relacionados entre sí. El sistema "1C:Enterprise" utiliza un protocolo creado sobre la base del protocolo OpenID de la versión 2.0 según el modelo Direct Identity.

El esquema general de trabajo es el siguiente:

• El usuario está intentando iniciar sesión.
• El sistema determina que la autenticación OpenID funciona en la base de información (según el archivo de publicación default.vrd).
• Se envía una solicitud de autenticación al proveedor de OpenID. Obviamente, el proveedor de OpenID debe ser accesible desde la dirección donde está publicada la base de información.
• Si es necesario realizar una acción interactiva (se está realizando la primera autenticación para un identificador determinado o ha expirado el tiempo de vida de los datos de autenticación de este identificador), el proveedor le indica al sistema que solicite un nombre de usuario y una contraseña. El sistema realiza una acción interactiva y devuelve los datos solicitados al proveedor de OpenID.

  Los datos de autenticación del usuario se almacenan en archivos de cookies, que se ubican en un repositorio individual para cada navegador web. El cliente ligero usa su propio repositorio.

• Si el proveedor autentica al usuario, el sistema devuelve un atributo de que el usuario está autenticado.

La autenticación OpenID solo funciona cuando se accede a la base de información a través de los protocolos HTTP y HTTPS. Esto significa que solo un cliente web, un cliente móvil y un cliente ligero conectado a la base de información a través de un servidor web pueden usar la autenticación OpenID. Con la autenticación OpenID, las solicitudes entre dominios son posibles cuando se trabaja con un cliente ligero, así como con los navegadores web Mozilla Firefox, Google Chrome y Safari.

Puede actuar como proveedor de OpenID como una base de información de "1C:Enterprise" publicada en un servidor web de manera especial, así como un sistema de información arbitrario que implementa el trabajo de conformidad con el protocolo OpenID Authentication 2.0 y una extensión de este protocolo implementada en la plataforma "1C:Enterprise". La dirección del proveedor de OpenID utilizado debe especificarse en el archivo default.vrd (elemento <rely>) al publicar una base de información que es cliente de un proveedor de OpenID.

Es importante comprender que el campo "clave" mediante el cual el usuario de la base de información de "1C:Enterprise" se compara con la base de usuarios del proveedor de OpenID es el valor especificado en el atributo Name del usuario de la base de información. En otras palabras, el usuario podrá ingresar a la base de información si en la base de información en el atributo Name se especifica el identificador devuelto por el proveedor de OpenID. La descripción del identificador devuelto debe obtenerse de la documentación del proveedor de OpenID utilizado.

La contraseña del usuario se especifica en el margen del proveedor de OpenID. Si la base de información de "1C:Enterprise" actúa como proveedor de OpenID, la contraseña se establece en la base de información que actúa como proveedor de OpenID. La contraseña establecida en una base de información que es cliente de un proveedor de OpenID se ignora cuando se autentica con la ayuda de OpenID. Si se utiliza un proveedor de OpenID de terceros, la contraseña se establece mediante los medios y herramientas de este proveedor. Después de cambiar la contraseña del usuario en el repositorio de usuarios del proveedor de OpenID, 1C:Enterprise seguirá la siguiente configuración:

• en las sesiones en curso, este usuario se considerará autenticado hasta que finalicen las sesiones;
• al crear una nueva sesión, se solicitará una contraseña aunque los datos de autenticación del usuario aún no hayan caducado.

Si se necesita forzar la autenticación usando OpenID, entonces en la línea de comandos para iniciar la aplicación de cliente, se debe especificar el parámetro de la línea de comandos /OIDA + (actúa por defecto). En consecuencia, el parámetro de la línea de comandos /OIDA- se usa para forzar la desactivación de la autenticación OpenID.

Consulte también:

• OpenID Authentication 2.0 (consulte https://openid.net/specs/openid-authentication-2_0.html).
• Requisitos adicionales para un proveedor de OpenID.

6.2.10.5. Autenticación con la ayuda de OpenID Connect

OpenID Connect (https://openid.net/connect/) - es un protocolo que es una extensión del protocolo de autorización OAuth 2.0. OpenID Connect permite que el sistema "1C:Enterprise" verifique la identidad del usuario en función de la autenticación realizada por un proveedor externo. Este protocolo se aplica cuando se utiliza el cliente ligero, el cliente móvil y el cliente web. El sistema "1C:Enterprise" no puede actuar como proveedor de OpenID Connect. Para el trabajo solo se utilizan proveedores externos. La compatibilidad con el protocolo OpenID Connect también significa la capacidad de utilizar el Sistema de identificación y autenticación unificado (SIAU).

Los siguientes datos se utilizan para comparar a un usuario de "1C:Enterprise" y a un usuario del proveedor de autenticación:

• Por parte del proveedor de autenticación, por defecto, se usa la dirección de correo electrónico (como parámetro clave). Al configurar el acceso al proveedor OpenID Connect, es posible especificar qué campo del token de autenticación se utilizará como clave.
• Desde el lado de 1C:Enterprise, el parámetro clave predeterminado está en el atributo Name del usuario de la base de información. Es posible configurar el sistema de tal manera que el campo clave sea el atributo OSUser, Email o un valor de la colección UserMatchingKeys.

En el caso de que para la comparación se use la colección UserMatchingKeys, su llenado solo se puede realizar utilizando el lenguaje integrado. El código puede tener la siguiente vista:

IBUser = InfoBaseUsers.Find(UserCode);
IBUser. UserMatchingKeys.Insert("googleIV", "user-name@google.com");
IBUser.Record();

El elemento de la colección UserMatchingKeys se usará si la lista de proveedores en el archivo default.vrd contiene la descripción de un proveedor cuyo atributo name es igual al valor de googleIV. El usuario que se identifica por el valor de la variable UserCode se utilizará al iniciar la sesión si el valor del campo de comparación del token devuelto por el proveedor de OpenID Connect tendrá el valor user-name@google.com. La descripción del proveedor googleIV se proporciona en el ejemplo para el elemento openidconnect.providers del archivo default.vrd.

Cuando el cliente móvil se está ejecutando, la autenticación se realiza mediante el navegador web del dispositivo móvil:

• Sistema operativo Android: navegador web Google Chrome.
• Sistema operativo iOS: versión 9.0 y posteriores.

En caso de que el dispositivo móvil no cumpla con los requisitos anteriormente mencionados, es posible que el usuario deba volver a autenticarse en el lado del proveedor de OpenID Connect en el cliente móvil. Para forzar la autenticación en el próximo inicio de sesión, se debe ejecutar el comando Finalizar trabajo en el cliente móvil.

Consulte también:

• Para obtener una descripción del esquema de trabajo con el proveedor OpenID Connect, consulte la pág.
• Descripción del archivo default.vrd.

6.2.10.6. Autenticación con la ayuda de JWT

Token - un medio para identificar a un usuario o una sesión individual de trabajo en una aplicación. JSON Web Token (abreviado como JWT) - un estándar para crear tókenes de acceso basado en el formato JSON. JWT se describe en el estándar RFC 7519 (https://datatracker.ietf.org/doc/html/rfc7519, en inglés). JWT se utiliza para la autenticación de usuarios en aplicaciones cliente/servidor. Una descripción más detallada de JWT (y el uso de este mecanismo en aplicaciones).

La autenticación usando JWT funciona solo en aquellas bases de información que están publicadas en el servidor web. Para especificar el JWT, se utiliza un comando de la línea de comandos para iniciar la aplicación de cliente AccessToken.

La base de información publicada debe configurarse de manera especial. El ajuste de la publicación se realiza con la ayuda del archivo default.vrd.

Consulte también:

• Descripción del trabajo con JWT.
• Archivo default.vrd.

6.2.10.7. Autenticación de dos factores

6.2.10.7.1. Información general

La plataforma puede realizar la autenticación del usuario por sí misma o puede utilizar los resultados de la autenticación realizada por otro recurso en el que confíe (sistema operativo o proveedor de OpenID). En cualquier caso, el usuario introduce un nombre de usuario y una contraseña. Si se especifica el par nombre de usuario/contraseña correcto, la plataforma considera que el usuario está identificado y le proporciona acceso a la aplicación.

Este esquema convencional es simple y conveniente, pero tiene un inconveniente importante. Se debe recordar la contraseña, para ello debe ser breve y sencilla. Pero esa contraseña es fácil de descifrar. Para que una contraseña sea difícil de descifrar, debe ser larga y compleja. Pero tal contraseña no es fácil de recordar. Por eso, en realidad, todo se reduce a que las personas usan contraseñas simples, y en diferentes lugares las mismas.

La autenticación de dos factores - es un método que permite, por un lado, complicar a los atacantes el acceso a los datos de otras personas y, por otro lado, es una solución que permite nivelar las deficiencias de la protección de contraseña clásica.

La autenticación de dos factores requiere que el usuario tenga dos de los tres posibles tipos de datos de autenticación:

• Algo que sabe, algo que recuerda. Es el nombre de usuario y la contraseña.
• Algo que posee. Este podría ser el teléfono móvil o el correo electrónico del usuario.
• Algo que le es inherente. Esto puede ser una característica física del usuario, como una huella dactilar, un retrato o un patrón del iris.

El significado de la autenticación de dos factores es que para obtener acceso a la aplicación, el usuario debe confirmar dos veces que es él y de diferentes maneras. Por ejemplo, ingresar el nombre de usuario/contraseña (y este será el primer factor de autenticación), y luego ingresar el código enviado a su teléfono móvil (y este será el segundo factor de autenticación).

El primer factor de autenticación es verificado por la plataforma "1C:Enterprise" en sí, y un tercer servicio se utiliza para operar con el segundo factor de autenticación, que se llamará proveedor del segundo factor.

El proveedor del segundo factor (en el contexto de esta sección se puede usar el término "proveedor") - es un servicio HTTP que proporciona una interfaz de programación para realizar ciertas acciones. El papel del proveedor del segundo factor puede ser, por ejemplo, una base de información de "1C:Enterprise" que tiene un conjunto de servicios HTTP que permiten enviar mensajes o autenticar. Este puede ser un servicio de terceros que envía mensajes por SMS o correo electrónico, puede ser un servicio que genere códigos de segundo factor o un servicio de autenticación que interactúa con el usuario a través de su propia aplicación móvil, y así sucesivamente. Lo único importante es que se puede acceder al proveedor a través de solicitudes HTTP.

La autenticación de dos factores sólo puede utilizarse para la autenticación mediante el sistema 1C:Enterprise (autenticación estándar), en cualquier variante de la base de información y para cualquier aplicación cliente.

Consulte también:

• Autenticación de "1C:Enterprise".

6.2.10.7.2. Variantes de uso del segundo factor

Entonces, la autenticación estándar del sistema "1C:Enterprise" (el primer factor) se ve así:

1. El usuario lanza la aplicación de cliente. La aplicación de cliente le solicita al usuario el primer factor de autenticación nombre de usuario y contraseña. El usuario los ingresa, la aplicación de cliente los envía al servidor.
2. El servidor verifica que el nombre de usuario y la contraseña sean correctos.
3. Si los datos especificados son correctos, el servidor comprueba que el usuario solo necesita especificar un factor de autenticación para trabajar con la aplicación. Si no es necesario utilizar el segundo factor, entonces se considera que el usuario está totalmente identificado y puede comenzar a trabajar. Es un escenario de autenticación habitual.

Si se configura la autenticación de dos factores para el usuario, se realizan los primeros dos pasos, como antes, especificando el nombre de usuario/contraseña y verificando estos datos de los servidores de "1C:Enterprise".

El uso del segundo factor se puede realizar de dos formas:

1. El servidor de "1C:Enterprise" genera el segundo factor por sí mismo y verifica si el usuario ingresa el valor de este factor correctamente. El proveedor realiza solo la función de transporte - de transmitir el valor del segundo factor al usuario. En este caso, tanto el servidor de "1C:Enterprise" como el usuario conocen el canal utilizado para transmitir el valor del segundo factor.

   El proceso se ve de la siguiente manera:

   • El servidor de "1C:Enterprise" informa a la aplicación de cliente que el usuario debe especificar el segundo factor de autenticación.
   • La aplicación de cliente muestra el formulario de entrada del segundo factor.
   • El servidor de "1C:Enterprise" genera y envía al usuario el valor del segundo factor (por ejemplo, algún número), que el usuario debe especificar en el formulario abierto por la aplicación de cliente. El valor del segundo factor se puede enviar al usuario por correo electrónico o por SMS.
   • El usuario recibe los datos del segundo factor y los ingresa en la ventana abierta por la aplicación de cliente. La aplicación de cliente envía los datos del segundo factor al servidor de "1C:Enterprise".
   • El servidor de "1C:Enterprise" verifica que los datos ingresados coincidan con los datos que fueron generados (por el servidor) y enviados al usuario.
   • Si los valores del segundo factor transmitido por la aplicación de cliente y generado por el servidor de "1C:Enterprise" coinciden el usuario se considera identificado y se le otorga acceso a la aplicación.
2. El servidor de "1C:Enterprise" utiliza un servicio de terceros que informa al servidor de "1C:Enterprise" el resultado de la aplicación del segundo factor por el usuario. En este caso, el servidor "1C:Enterprise" no tiene información sobre el tipo del segundo factor utilizado. La forma de transmisión del segundo factor al usuario también está determinada por el proveedor seleccionado del segundo factor. El servidor de "1C:Enterprise" solo sabe que hay un servicio de confianza que, en respuesta a una solicitud para aplicar el segundo factor de autenticación, informa si el segundo factor se aplicó con éxito o sin éxito.

   El proceso se ve de la siguiente manera:

   • El servidor de "1C:Enterprise" informa a la aplicación de cliente que el usuario debe autenticar el segundo factor del lado del proveedor.
   • La aplicación de cliente le muestra al usuario un formulario en el que el usuario debe realizar una determinada acción después de que el usuario sea autenticado por el proveedor del segundo factor.
   • El servidor envía una solicitud HTTP al proveedor con una solicitud para autenticar al usuario.
   • El proveedor inicia el procedimiento de autenticación. El método de autenticación queda a discreción del proveedor.
   • Una vez finalizado el procedimiento de autenticación, el usuario informa a la aplicación de cliente al respecto.
   • La aplicación de cliente envía esta información al servidor de "1C:Enterprise" que solicita al proveedor del segundo factor los resultados de la autenticación.
   • El proveedor informa el resultado de la autenticación al servidor. Si se ha realizado con éxito, el usuario se considera identificado y se le otorga acceso a la aplicación.

Cada uno de los métodos examinados en esta sección tiene cierto soporte por parte del sistema "1C:Enterprise". El ajuste del uso del segundo factor de autenticación se analiza en la siguiente sección.

6.2.10.7.3. Ajuste del segundo factor

El ajuste del uso del segundo factor en "1C:Enterprise" se divide en varias partes:

• Ajuste de las plantillas de solicitud que se envían a los proveedores.
• Vinculación de una plantilla de solicitud a un usuario de la base de información.
• Parametrización de solicitudes.

Echemos un vistazo más de cerca a cada parte.

Para describir la solicitud HTTP que se debe enviar al proveedor, se utiliza el objeto SecondAuthenticationFactorSettingTemplate. La elección de una de las variantes para el segundo factor de autenticación se realiza en el proceso de configuración de los parámetros de la plantilla. En el caso de que sea necesario implementar la primera variante del segundo factor de autenticación (el propio servidor de "1C:Enterprise" genera, envía y verifica el valor del segundo factor), se utilizan los atributos AuthenticationHTTPRequest y AuthenticationHTTPRequestMethod. El primer atributo contiene una descripción de la solicitud HTTP (un objeto de tipo HTTPRequest), y el segundo parámetro permite especificar qué método HTTP se utilizará para hacer la solicitud al proveedor del segundo factor de autenticación.

En el caso de que sea necesario realizar la segunda variante de autenticación (el servidor de "1C:Enterprise" solo inicia la autenticación en el proveedor del segundo factor y recibe su resultado), los parámetros examinados anteriormente permanecen y se usan para el propósito previsto para comenzar a usar el segundo factor de autenticación. Se utilizan dos atributos adicionales para comprobar el resultado de la autenticación: AuthenticationResultVerificationHTTPRequest y AuthenticationResultVerificationHTTPRequestMethod.

Cada plantilla tiene su propio nombre (atributo homónimo), lo que permitirá identificar la plantilla al realizar otras acciones.

Al formar una solicitud HTTP (para establecer cualquier atributo), se deben recordar las siguientes características:

1. El método HTTP se especifica como una línea. Esto se debe a que la especificación HTTP permite el uso de verbos personalizados (métodos).
2. El texto de la solicitud puede contener parámetros. Parámetros - es un texto que comienza con el carácter "&". Por ejemplo, se puede usar el parámetro &user_name para especificar el nombre de usuario. Estos parámetros serán reemplazados con valores reales en el momento en que se envíe la solicitud (se revisará a continuación). El motivo de esta decisión es la suposición de que las solicitudes HTTP del segundo factor de autenticación para diferentes usuarios serán casi las mismas. Las diferencias se observarán solo en alguna información que sea específica para un usuario en particular. Por ejemplo, una solicitud condicional para enviar un mensaje SMS con el código del segundo factor se verá así: . Al enviar una solicitud, el parámetro &phone_number deberá reemplazarse con el número de teléfono real del usuario.

   La plataforma proporciona una variable predefinida &secret, que contiene el valor del segundo factor generado por la plataforma.

Teniendo toda la información, veamos un ejemplo de creación de una plantilla para trabajar con el segundo factor de acuerdo con la primera variante (la plataforma genera, envía, proporciona la introducción y verificación del segundo factor):

Request = New HTTPRequest;
Request.ResourceAddress = "&addr";
Request: SetBodyFromString ("Introduzca el valor &secret. No le comente este valor a nadie!", "Utf-8");
Provider = SecondAuthenticationFactorSettingsTemplates.CreateTemplate();
Provider.AuthenticationHTTPRequest = Request;
Provider.AuthenticationHTTPRequestMethod = "POST";
Provider.Name = "Solicitud - respuesta";
Provider.Record();

Las primeras tres líneas forman la solicitud HTTP que utilizará la plataforma. Las líneas restantes crean una plantilla del proveedor del segundo factor que enviará una solicitud utilizando el método POST y tendrá el nombre Request - response.

Como, probablemente, ya ha quedado claro, si es necesario generar una plantilla para un proveedor de segundo factor que funcione según la segunda variante (todas las acciones las realiza el propio proveedor, la plataforma solo ejecuta el inicio de la operación y solicita el resultado de la autenticación), entonces el ejemplo anterior debe ser cambiado de tal manera que:

1. La solicitud de autenticación coincidía con los requisitos del proveedor que se estaba utilizando.
2. Se generó (y se especificó en la plantilla) una solicitud para comprobar los resultados de la autenticación. Esta solicitud se ejecutará después de que el usuario haya "informado" a la aplicación de cliente que ha sido autenticado por el proveedor.

Después de que hemos guardado una o más plantillas para proveedores, se hizo posible asignar cualquiera de las plantillas al usuario. Se debe recordar que se pueden asignar varias plantillas a un usuario y especificar de que forma serán procesadas.

Se utilizan dos atributos del objeto InfoBaseUser para configurar los ajustes del usuario:

• SecondAuthenticationFactorSetting - aquí se necesita asignar una matriz de los objetos del tipo SecondAuthenticationFactorSetting.
• SecondAuthenticationFactorSettingsProcessing - describe lo que hará la plataforma si se especifican varios proveedores del segundo factor y el primer (en orden de omisión) proveedor devolvió un error.

Después de especificar los atributos descritos anteriormente, se debe fijar el objeto que describe al usuario de la base de información.

Nos queda considerar el último punto: ¿dónde tomará la plataforma los valores que se sustituirán por las variables en las solicitudes HTTP? Para esto examinemos más detalladamente el objeto SecondAuthenticationFactorSetting. Este objeto contiene dos campos:

• SettingTemplateName - aquí se debe especificar el nombre de la plantilla de ajuste del proveedor del segundo factor, que se especificó en el atributo Nombre al configurar la plantilla del proveedor.
• Parameters - a este atributo se le debe asignar una coincidencia. La coincidencia debe contener tantos elementos, cuantos parámetros haya en la plantilla de configuración del proveedor del segundo factor (excluyendo el parámetro &secret). La clave del elemento de coincidencia es el nombre del parámetro (sin el símbolo "&"), y el valor es el valor de la variable.

Ahora tenemos toda la información para indicarle al usuario de la base de información la necesidad de realizar la autenticación de dos factores al ingresar a la base de información.

ProviderParameters = New Map;
ProviderParameters.Insert("addr", "http://example.com/resource");
UserSetting = New SecondAuthenticationFactorSetting;
UserSetting.SettingTemplateName = "Pregunta - respuesta";
UserSetting.Parameters = ProviderParameters;

UserSettings = New Array;
UserSettings.Add(UserSetting);

User = InfoBaseUsers.FindByName("Seller");
User.SecondAuthenticationFactorSettings = UserSettings;
User.SecondAuthenticationFactorSettingsProcessing = SecondAuthenticationFactorSettingsProcessingType.UseNextIfFailed;
User.Record();

La plataforma reemplazará los nombres de los parámetros por los valores reales en los siguientes atributos:

• atributo HTTPRequest.ResourceAddress;
• atributo HTTPRequest.Headers;
• cuerpo de la solicitud de objeto HTTPRequest (la forma en la que se especifica el cuerpo de la solicitud no afecta el funcionamiento de la sustitución);
• atributo SecondAuthenticationFactorSettingTemplate.AuthenticationHTTPRequestMethod;
• atributo SecondAuthenticationFactorSettingTemplate.AuthenticationResultVerificationHTTPRequestMethod.

Queda por mencionar que si el proveedor del segundo factor elegido para el usuario "se ha roto" el usuario no podrá acceder a la base de información. En este caso, el término "se ha roto" significa cualquier evento que no permita que el proveedor complete su tarea: no hay Internet para el acceso del servidor al proveedor, no hay Internet para el acceso del proveedor al usuario, se ha producido un error en la parte del proveedor, etc.

También se debe comprender que si planea usar un proveedor externo del segundo factor, entonces los servicios de este proveedor pueden ser pagados y el proveedor puede presentar condiciones y restricciones adicionales que se encuentran fuera del sistema "1C:Enterprise" y son no considerados en esta documentación.

6.2.10.7.4. Autenticación OpenID y la autenticación de dos factores

El sistema de software "1C:Enterprise" admite la autenticación mediante el protocolo OpenID. Si el sistema de información utiliza la autenticación OpenID, entonces el proveedor de OpenID debe solicitar el segundo factor. Esto también es cierto si la base de información del sistema "1C:Enterprise" se especifica como proveedor de OpenID. En otras palabras, la autenticación de dos factores debe configurarse en la base de información que actúa como un proveedor de OpenID.

6.2.10.8. Uso de datos biométricos para un inicio de sesión rápido en el cliente móvil

En los dispositivos que tienen herramientas de autenticación biométrica (sensor de huellas dactilares, escáner facial, escáner de iris, etc.), la casilla de verificación Utilizar datos biométricos se muestra en los diálogos de configuración de la base de información del cliente móvil y en los diálogos de autenticación (en un dispositivo móvil). La activación de esta casilla conduce al uso del siguiente mecanismo:

• Después del primer inicio de sesión exitoso, los nombres de usuario y contraseñas ingresados para la base de información, la autenticación mediante OpenID y el servidor web se colocan en un repositorio seguro.
• En el siguiente intento de inicio de sesión, se implementa la siguiente lógica:
  • Primero se intenta iniciar sesión sin utilizar los datos de repositorio seguro para verificar que por el momento no se requiere autenticación o que hay datos de autenticación actualizados del proveedor de OpenID. Si el dispositivo móvil tiene datos de autenticación actualizados, la solicitud de datos biométricos para la confirmación de la autenticación se realizará solo después de que haya expirado la vida útil de los datos de autenticación.
  • Si el paso anterior falla, se le solicita al usuario que realice la autenticación biométrica mediante la interfaz del sistema operativo móvil. Se solicitará el tipo de autenticación especificado en la configuración del dispositivo móvil del usuario.
  • Si el usuario ha rechazado la autenticación biométrica, se realizará una transición al diálogo de autenticación estándar (utilizando el nombre de usuario y la contraseña).
  • Si el dispositivo móvil acepta los datos biométricos, los datos que se recordaron como resultado de la autenticación exitosa anterior se recuperan del repositorio seguro. Los datos obtenidos se utilizan para la autenticación.
  • Si el dispositivo no acepta los datos biométricos, los datos de la autenticación exitosa anterior se eliminan del repositorio seguro. Después de eso, se realiza la transición al cuadro de diálogo de autenticación estándar (usando un nombre de usuario y una contraseña).
• La biometría no se puede usar cuando se utiliza la autenticación con OpenID Connect, ya que la autenticación se realiza en una página web segura del proveedor de OpenID Connect. Esta página no se puede completar automáticamente con el nombre de usuario y la contraseña almacenados de este proveedor. Además, OpenID Connect brinda re-autenticación en este dispositivo sin ingresar el nombre de usuario y la contraseña por un tiempo ilimitado.

  Si la autenticación mediante OpenID Connect es compatible con el dispositivo móvil, se utiliza esta precisamente. Si rechaza la autenticación con OpenID Connect, aparece la posibilidad de inicio de sesión rápido utilizando los datos biométricos. Para intentar reutilizar la autenticación con OpenID Connect, debe ocurrir un intento fallido de inicio de sesión.

<< Prev   Next >>