Active Directory y autenticación basada en notificaciones
Publicado: enero de 2017
Se aplica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
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 Microsoft Dynamics 365 (en línea y local)) o en modo activo (cuando WS-Trust se usa con clientes 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 servidor Microsoft Dynamics 365. Todas las ediciones de Microsoft Dynamics 365 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. Para obtener más información, consulte el tema siguiente en la documentación de implementación y administración de Dynamics 365:TechNet: Configuración de IFD para Microsoft Dynamics CRM 2015.
En este tema
Escenarios de autenticación compatibles
Escenarios de autenticación no compatibles
Clases de autenticación
Autenticación mediante las clases del proxy de cliente
Supervisar excepciones y errores del canal
Información adicional sobre el token de seguridad (SAML)
Escenarios de autenticación compatibles
Microsoft Dynamics 365 admite los siguientes escenarios de autenticación para cada tipo de implementación.
Implementación |
Modelo de autenticación |
|---|---|
Microsoft Dynamics 365 (online) |
Autenticación basada en notificaciones o de Active Directory (mediante federación) |
Microsoft Dynamics 365 local |
Autenticación basada en notificaciones o de Active Directory |
Microsoft Dynamics 365 Implementación con conexión a Internet (IFD) |
Autenticación basada en notificaciones o de Active Directory |
Cómo funciona la autenticación basada en notificaciones
Se envía una solicitud para autenticar a un usuario desde Microsoft Dynamics 365 o Microsoft Dynamics 365 (online) 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 Microsoft Dynamics 365 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 con SDK de Microsoft Dynamics 365. Si configura el sitio web de Microsoft Dynamics 365 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 los métodos de programación no admitidos adicionales 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 los servicios web de Microsoft Dynamics 365 (online) Ejemplo: Autenticar usuarios con los servicios web de Microsoft Dynamics 365 |
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 de cliente |
|
Todos los tipos de implementación: local/IFD, en línea (Cuenta de Microsoft y Office 365/MOS*) |
Conexión simplificada a Microsoft Dynamics CRM Ejemplo: tutorial de conexión simplificada con Microsoft Dynamics 365 |
|
ServerConnection |
Todos los tipos de implementación: local/IFD, en línea (Cuenta de Microsoft y Office 365/MOS*) Usar para aplicaciones de prueba de consola y código de ejemplo. Diseñado para mejorar la facilidad de uso al ejecutar el código de ejemplo de SDK y demostrar el uso de las clases de autenticación. Contiene código de resultado de la consola. |
*Entorno de Microsoft Online Services
Autenticación mediante las clases del proxy de cliente
Una forma de autenticarse con los servicios web de Microsoft Dynamics 365 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 Microsoft Dynamics 365 (en línea y local). 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 Microsoft Dynamics 365 (online) a través del proveedor de identidad de 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 Microsoft Dynamics 365, las clases del proxy de cliente usan la autenticación basada en notificaciones si un servidor STS está disponible. De lo contrario, se usa la autenticación de Active Directory.
Si desea usar tipos de entidad en tiempo de compilación Microsoft Dynamics 365 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()
.jpeg "System_CAPS_security") Seguridad Nota |
|---|
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 Microsoft Dynamics 365, 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. Microsoft Dynamics 365 controla las credenciales proporcionadas en las llamadas de servicio web de la siguiente manera:
|
Supervisar excepciones y errores del canal
El código debe seleccionar las siguientes excepciones y errores. Consulte los ejemplos de C# en SDK de Microsoft Dynamics 365 para ver una lista de excepciones adicionales para seleccionar:
Para obtener más información, consulte la .NET Frameworkdocumentación de WCF sobre cómo supervisar las excepciones y errores de WCF. Consulte Usar el ejemplo y el código auxiliar para ver código de ejemplo adicional.
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 Microsoft Dynamics 365 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 Microsoft Dynamics 365. |
Nombre |
Si el usuario autenticado también es un administrador de implementaciones en Microsoft Dynamics 365, esta notificación contiene el Id. del administrador de implementaciones en formato dominio\alias en el servidor de destino Microsoft Dynamics 365.Windows Identity Foundation asigna la notificación de Name a la propiedad Identity.name. |
Cualquier otra notificación |
No utilizada por Microsoft Dynamics 365. |
Tipos de token de seguridad admitidos
Microsoft Dynamics 365 (en línea y local) admite dos tipos de token de SAML:
Aplicación web - La aplicación web de Microsoft Dynamics 365 recibe un token de portador STS. A este token le falta la información necesaria para que una URL basada en Seguridad de la capa de transporte (TLS) o Capa de sockets seguros (SSL)(https://) se utilice para la protección de seguridad al acceder 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 Microsoft Dynamics 365 cuando la solicitud del siguiente mensaje de la aplicación se procesa.
Ver también
Tutorial: Registrar una aplicación de Dynamics 365 con Active Directory
Conexión con Microsoft Office 365 y Microsoft Dynamics 365 (online)
Implemente el inicio de sesión único de una página Web o un IFRAME de ASPX
Ejemplo: Autenticar usuarios con los servicios web de Microsoft Dynamics 365
Microsoft Dynamics 365
© 2017 Microsoft. Todos los derechos reservados. Copyright