Active Directory y autenticación basada en notificaciones

  • Artículo

La autenticación basada en notificaciones proporciona un protocolo de seguridad estándar del sector para autenticar un usuario en un equipo host. La autenticación basada en notificaciones es un conjunto de normas WS-* que describe el uso de un símbolo de Lenguaje de marcado de aserción de seguridad (SAML) en modo pasivo (cuando WS-Federation se usa con la aplicación web de Dynamics 365 for Customer Engagement) o en modo activo (cuando WS-Trust se usa con clientes de Windows Communication Foundation (WCF)). Esta autenticación funciona junto con WCF para proporcionar autenticación segura de usuarios y un canal de comunicación con un Dynamics 365 Server. Todas las ediciones de Dynamics 365 Customer Engagement (on-premises) admiten autenticación basada en notificaciones.

La autenticación basada en notificaciones necesita la disponibilidad de un servicio de token de seguridad (STS) ejecutándose en un servidor. Un servidor STS se puede basar en servicios de federación de Active Directory (AD FS) V2 o cualquier plataforma que proporcione el protocolo de funcionario STS. Más información: TechnNet: Configurar IFD para Dynamics 365 Customer Engagement (on-premises).

Escenarios de autenticación compatibles

Dynamics 365 Customer Engagement (on-premises) admite los siguientes escenarios de autenticación para cada tipo de implementación.

 

Implementación Modelo de autenticación
Dynamics 365 for Customer Engagement (on-premises) Autenticación de Active Directory y basada en notificaciones
Implementación con conexión a Internet de Dynamics 365 for Customer Engagement (IFD) Autenticación de Active Directory y basada en notificaciones

Cómo funciona la autenticación basada en notificaciones

Se envía una solicitud para autenticar a un usuario desde Dynamics 365 for Customer Engagement o una aplicación personalizada al servidor STS. El servidor STS determina si el usuario debe ser autenticado y, si es así, emite un token de SAML firmado y cifrado que contiene la información de autenticación de usuario. El token tiene una vida finita y puede que tenga que actualizarse periódicamente según desde cuando la aplicación esté usando el token. Esto se explica con mayor detalle más adelante en este tema.

Cómo funciona la autenticación de Active Directory

Se envía una solicitud para autenticar a un usuario desde Dynamics 365 Customer Engagement (on-premises) o una aplicación personalizada a Active Directory. La pila de WCF administra el proceso de autenticación de las llamadas del servicio de la organización desde una aplicación, mientras Internet Information Services (IIS) administra la autenticación para una aplicación web.

Escenarios de autenticación no compatibles

El uso de certificados de cliente no es compatible. Si configura el sitio web de Dynamics 365 Customer Engagement para solicitar certificados de cliente de IIS, recibirá errores de autenticación para cualquier aplicación que se hubiera desarrollado con el SDK.

Para obtener más información acerca de métodos de programación no admitidos, consulte Personalizaciones no admitidas.

Clases de autenticación

La siguiente tabla muestra las clases de autenticación primarias disponibles en SDK, describe cuándo usarlas y proporciona vínculos a la documentación adicional relevante.

Clases Uso Documentación relacionada
IServiceConfiguration<TService>, IServiceManagement<TService> Todos los tipos de implementación: local/IFD, en línea (cuenta de Microsoft y Office 365/MOS*)

La mejor opción para las aplicaciones con varios subprocesos		 Autenticar usuarios de Office 365 con servicios web de Dynamics 365 Customer Engagement

Ejemplo: Autenticar usuarios con los servicios web de Dynamics 365 Customer Engagement

Mejorar el rendimiento de la asignación del canal de servicio
DiscoveryServiceProxy, OrganizationServiceProxy Todos los tipos de implementación: local/IFD, en línea (cuenta de Microsoft y Office 365/MOS*) Autenticación mediante las clases del proxy del cliente

Mejorar el rendimiento de la asignación de canales de servicio
Clases de herramientas XRM Todos los tipos de implementación: local/IFD, en línea (cuenta de Microsoft y Office 365/MOS*) Crear aplicaciones cliente de Windows mediante las herramientas XRM
CrmServiceClient Todos los tipos de implementación: local/IFD, en línea (cuenta de Microsoft y Office 365/MOS*) Ejemplo: inicio rápido de conexión simplificada con Microsoft Dataverse

* Entorno de Microsoft Online Services

Propina

En función del escenario de la aplicación, el método recomendado para autenticar una aplicación cliente .NET con cualquier implementación de Dynamics 365 Customer Engagement (on-premises) es usar laclase CrmServiceClient.

No use la clase ServiceClient si está usando ADFS para la autenticación local.

Autenticación mediante las clases del proxy de cliente

Una forma de autenticarse con los servicios web de Dynamics 365 Customer Engagement (on-premises) es mediante las clases de OrganizationServiceProxy y de DiscoveryServiceProxy en las aplicaciones que escribe. El constructor de cuatro parámetros de estas clases admite las implementaciones de Dynamics 365 for Customer Engagement. Estas clases del proxy controlan automáticamente notificaciones o la autenticación de Active Directory y también administran los límites de recursos en el extremo de canal de WCF.

El siguiente código muestra cómo crear una instancia del proxy de servicio de la organización:

using (OrganizationServiceProxy _serviceProxy = new OrganizationServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

El siguiente código muestra cómo crear una instancia del proxy de servicio de detección:

using (DiscoveryServiceProxy _discProxy = new DiscoveryServiceProxy(organizationUri, homeRealmUri, userCredentials, deviceCredentials))

Es importante eliminar correctamente la instancia del proxy de servicio en la aplicación antes de que finalice la aplicación. La instrucción using garantiza que el proxy de servicio se elimine correctamente llamando automáticamente a Dispose en el proxy de servicio cuando sale de ámbito. Sin embargo, para mejorar el rendimiento de la aplicación, se recomienda mantener la instancia del proxy de servicio disponible en la aplicación para la sesión completa de la aplicación en lugar de desecharla y de asignarla a una organización de nuevo en alguna parte del código de aplicación cuando sea necesario. La razón es que crear y autenticar un canal de servicio es una operación costosa (en tiempo). En este caso, cuando haya finalizado con la instancia del proxy de servicio, debe llamar directamente al método Dispose en el proxy antes de que finalice la aplicación.

Las credenciales de dispositivo del dispositivo informático registrado se usan solo al autenticarse con Dynamics 365 for Customer Engagement a través del proveedor de identidad de la cuenta de Microsoft. Para ver código de ejemplo que muestra cómo rellenar los parámetros del constructor del proxy, consulte Ejemplo: Acceder al servicio de detección.

Importante

Para una instalación local o una implementación con conexión a Internet (IFD) de Dynamics 365 for Customer Engagement, las clases del proxy de cliente usan la autenticación basada en notificaciones si un servidor STS está disponible. Si no, se usa la autenticación de Active Directory.

Si desea usar tipos de entidad en tiempo de compilación Dynamics 365 Customer Engagement (on-premises) en el código, debe agregar la siguiente línea de código una vez creada una instancia del proxy de servicio de la organización, pero antes de hacer llamadas al método del servicio web:

_serviceProxy.EnableProxyTypes()

Importante

WCF admite una característica con la que se pueden pedir de forma interactiva al usuario las credenciales de inicio de sesión cuando sea necesario. Esta característica se habilita estableciendo la propiedad SupportInteractive de la clase ClientCredentials. Dichas credenciales se usan en el parámetro de userCredentials que se muestra en el fragmento de código anterior.

Al hacer llamadas de SDK a los servicios web de Dynamics 365 Customer Engagement (on-premises), la propiedad de la operación y los cambios de los datos de entidad realizados por la llamada de SDK pueden cambiarse mediante esta característica de WCF independiente su código.

Dynamics 365 Customer Engagement (on-premises) controla las credenciales proporcionadas en las llamadas de servicio web de la siguiente manera:

  • Si las credenciales no se incluyen en la llamada de servicio de red, la pila de WCF determina qué credenciales usar. En este caso, el valor de propiedad de SupportInteractive se configura automáticamente en false.
    • Si el código suministra explícitamente credenciales, el valor actual de SupportInteractive se pasa a la fábrica de canal de WCF. SupportInteractive se establece en true de manera predeterminada a menos que la cambie explícitamente.
    • Si SupportInteractive se establece en true y las credenciales proporcionadas son erróneas, puede que aparezca un cuadro de diálogo de WCF. Cualquier credencial especificada por el usuario en el cuadro de diálogo se usará en lugar de las proporcionadas en las llamadas del servicio web que la aplicación conlleva.

Supervisar excepciones y errores del canal

El código debe seleccionar las siguientes excepciones y errores. Consulte los ejemplos de C# en la documentación de desarrollador para ver una lista de excepciones adicionales para seleccionar:

Información adicional sobre el token de seguridad (SAML)

El token de SAML que se usa durante la autenticación de usuario se describe más abajo.

Contenido del token de SAML

El token basado en XML de SAML 2.0 contiene una identidad que define una o más notificaciones sobre un usuario. Este token se pasa entre un servidor de un proveedor de identidad (STS) y Dynamics 365 Customer Engagement (on-premises) para la autenticación basada en notificaciones. Las notificaciones de la identidad se han definido de la siguiente manera.

Notificación Usar
Nombre principal de servicio (UPN) Contiene el Id. de usuario en formato dominio/alias en el servidor de destino Dynamics 365 Server.
Nombre Si el usuario autenticado también es un administrador de implementaciones en Dynamics 365 Customer Engagement (on-premises), esta notificación contiene el Id. de administrador de implementaciones en formato dominio/alias en Dynamics 365 Server de destino. Windows Identity Foundation asigna la notificación de Name a la propiedad Identity.name.
Cualquier otra notificación No utilizada por Dynamics 365 Customer Engagement (on-premises).

Tipos de token de seguridad admitidos

Dynamics 365 for Customer Engagement admite dos tipos de tokens SAML:

  • Aplicación web - La aplicación web de Dynamics 365 Customer Engagement (on-premises) recibe un token de portador STS. A este token le falta parte de la información necesaria para que se use una seguridad de capa de transporte (TLS) o una URL (https://) basada en la capa de sockets seguros (SSL) para la protección de seguridad cuando acceda al extremo de WCF.

  • SDK - Una aplicación personalizada recibe un token activo con una clave de prueba que contiene la información necesaria.

Ciclo de vida del token de seguridad

Un token de seguridad tiene una vida identificada por sus propiedades de ValidFrom y de ValidTo. El diseño de aplicaciones debe considerar la posibilidad de que el token pueda expirar, provocando que se lance un ExpiredSecurityTokenException por parte de los servicios web de Dynamics 365 Customer Engagement (on-premises) cuando la solicitud del siguiente mensaje de la aplicación se procesa.

Vea también

Tutorial: registrar una aplicación de Dynamics 365 Customer Engagement (on-premises) con Active Directory
Conectar con Microsoft Office 365 y Dynamics 365 Customer Engagement (on-premises)
Implementar el inicio de sesión único desde una página web ASPX o desde IFRAME
Ejemplo: Autenticar usuarios con los servicios web de Dynamics 365 Customer Engagement