Proveedor de notificaciones en SharePoint
Proveedores de notificaciones
Un proveedor de notificaciones es SharePoint Server emite notificaciones y las empaqueta en tokens de seguridad, es decir, en el token del usuario. Cuando un usuario inicia sesión en SharePoint Server, el token del usuario se valida y se usa para iniciar sesión en SharePoint.
Un proveedor de notificaciones de SharePoint tiene dos roles: aumento y selección.
Nota:
Para obtener información sobre cómo crear un proveedor de notificaciones, vea Cómo: Crear un proveedor de notificaciones en SharePoint.
Aumento de notificaciones
En el rol de aumento, un proveedor de notificaciones aumenta un token de usuario con notificaciones durante el inicio de sesión. Con el aumento de notificaciones, una aplicación puede aumentar el token del usuario con más notificaciones. Por ejemplo, con inicio de sesión basado en Windows, el servicio de directorios de Active Directory puede aumentar todos los grupos de seguridad de un usuario en el token Windows del usuario. Con el inicio de sesión basado en notificaciones, una aplicación de administración de las relaciones con el cliente (CRM) puede aumentar los roles de una base de datos de CRM. Al incluir estas notificaciones en el token del usuario, los recursos se pueden autorizar a partir de tales notificaciones. Dicho de otro modo, estas notificaciones se pueden usar para saber si un usuario concreto tiene acceso a determinados recursos.
Selección de notificaciones
En el rol de selección, un proveedor de notificaciones proporciona, resuelve, busca y muestra funcionalidades de notificaciones en el selector de personas. La selección de notificaciones permite que una aplicación muestre notificaciones en el selector de personas (por ejemplo, al configurar la seguridad de un sitio o un servicio de SharePoint).
Escenarios de uso de proveedor de notificaciones
Los proveedores de notificaciones se usan para resolver distintos escenarios. A continuación se indican algunos escenarios en los que se usan proveedores de notificaciones a tal fin.
Enumerar, resolver y buscar
En SharePoint Server hay proveedores de notificaciones integrados que permiten enumerar, resolver y buscar proveedores de autenticación integrados. Ejemplos de proveedores de autenticación integrados son Windows Active Directory, la autenticación basada en formularios y los emisores de tokens de lenguaje de marcado de aserción de seguridad (SAML) de confianza (esto es, un servicio de token de seguridad (STS)).
Para un emisor de tokens SAML de confianza, SharePoint Server no ofrece lista ni búsqueda. Cuando un usuario escribe algún valor, SharePoint Server siempre lo resuelve. Esto significa que si escribe adam@contoso.com, el selector de personas acepta el valor. Esto se debe a que no hay ningún estándar del sector que especifique cómo un STS resuelve, implementa la búsqueda o enumera los valores de notificación.
Los usuarios pueden invalidar el proveedor de notificaciones integrado para implementar características personalizadas de búsqueda, resolución de nombres y lista. Esto es muy útil en escenarios como el uso de un emisor de tokens SAML de confianza.
Usuarios autenticados o notificaciones Todos los usuarios
En SharePoint Server, hay algunos proveedores de notificaciones integrados específicos que permiten la compatibilidad de implementación con conceptos como los usuarios autenticados. Esto también se conoce como una notificación de todos los usuarios. Este escenario le permite conceder derechos a todos los usuarios de un proveedor de autenticación determinado.
Nota:
[!NOTA] Un proveedor de autenticación puede ser Windows Active Directory, una autenticación basada en formularios o un emisor de tokens SAML (un STS) de confianza.
En SharePoint Server también existe un proveedor de notificaciones de sistemas que agrega algunas notificaciones internas utilizadas por un servicio de taxonomía. Así, agrega la identidad de granja de servidores y la cuenta de grupo de aplicaciones.
Agregar notificaciones a un token original
Algunos de los proveedores de notificaciones integrados también se usan para agregar las notificaciones del "token" original. Entrecomillamos la palabra "token" porque algunos proveedores de autenticación, como la autenticación basada en formularios (es decir, los proveedores de roles y pertenencia a ASP.NET), no suministran un token real. En estos casos, se debe pensar en el token desde un punto de vista conceptual.
Puede que se necesite agregar más notificaciones al token de notificaciones original de un usuario. En situaciones como esta, puede que sea necesario un proveedor de notificaciones. Así, por ejemplo, es posible que se necesite un proveedor de notificaciones para agregar roles SAP al token de notificaciones original de un usuario.
Identidad no procedente del token original
Imagine un escenario en el que el sistema tiene una serie de requisitos específicos de notificaciones de token y selección de personas. En este escenario, se conoce la identidad del usuario por el identificador único de Microsoft .NET Passport (PUID) y el usuario original. Sin embargo, la información sobre el usuario no proviene del token de usuario original, sino del Active Directory personalizado. Hay más grupos de Active Directory a los que el usuario puede pertenecer y que no están incluidos en el token de usuario original (emitido por Windows Live ID). En este escenario, se puede crear un proveedor de notificaciones acorde a las necesidades específicas del sistema.