Planeación de los métodos de autenticación (SharePoint Server 2010)

  • Artículo

 

Se aplica a: SharePoint Foundation 2010, SharePoint Server 2010

Última modificación del tema: 2016-11-30

En este artículo se describen los métodos de autenticación y los modos de autenticación admitidos en Microsoft SharePoint Server 2010. La autenticación es el proceso de validación de la identidad de un usuario. Después de validar la identidad de un usuario, el proceso de autorización determina los sitios, el contenido y demás características a los que puede obtener acceso el usuario. Los modos de autenticación determinan la forma en que las cuentas se usan internamente mediante SharePoint Server 2010.

En este artículo:

  • Métodos de autenticación admitidos

  • Modos de autenticación: clásico o basado en notificaciones

  • Implementación de autenticación de Windows

  • Implementación de autenticación basada en formularios

  • Implementación de autenticación basada en token SAML

  • Elección de autenticación para entornos de LDAP

  • Planeación de zonas para aplicaciones web

  • Arquitectura para los proveedores basados en token SAML

Métodos de autenticación admitidos

SharePoint Server 2010 admite métodos de autenticación que se incluían en versiones anteriores y, además, presenta la autenticación basada en tokens, que se basa en Lenguaje de marcado de aserción de seguridad (SAML) como una opción. En la siguiente tabla se enumeran los métodos de autenticación admitidos.

Método Ejemplos Notas

Windows

  • NTLM

  • Kerberos

  • Anónima

  • Básica

  • Implícita

En este momento, no se admite la autenticación de certificados de Windows.

Autenticación basada en formularios

  • Protocolo ligero de acceso a directorios (LDAP)

  • Base de datos de SQL u otra base de datos

  • Proveedores de roles y pertenencia personalizados o de terceros

Autenticación basada en token SAML

  • Servicios de federación de Active Directory (ADFS) 2.0

  • Proveedor de identidad de terceros

  • Protocolo ligero de acceso a directorios (LDAP)

Solo se admite con SAML 1.1 que usa el perfil pasivo de WS-Federation.

Modos de autenticación: clásico o basado en notificaciones

SharePoint Server 2010 introduce la autenticación basada en notificaciones, que se basa en Windows Identity Foundation (WIF). Puede usar cualquiera de los métodos de autenticación admitidos con la autenticación basada en notificaciones. O bien, puede usar la autenticación de modo clásico, que admite la autenticación de Windows.

Al crear una aplicación web, seleccione uno de los dos modos de autenticación para usar con la aplicación web, ya sea el modo basado en notificaciones o el modo clásico.

Autenticación de modo clásico o basada en notificaciones

Si selecciona el modo clásico, puede implementar la autenticación de Windows y SharePoint Server 2010 trata las cuentas de usuario como cuentas de Servicios de dominio de Active Directory (AD DS).

Si selecciona la autenticación basada en notificaciones, SharePoint Server 2010 cambia automáticamente todas las cuentas de usuario a identidades de notificaciones, lo que da como resultado un token de notificaciones para cada usuario. El token de notificaciones contiene las notificaciones correspondientes al usuario. Las cuentas de Windows se convierten en notificaciones de Windows. Los usuarios de pertenencia basada en formularios se transforman en notificaciones de autenticación basadas en formularios. SharePoint Server 2010 puede usar las notificaciones que se incluyen en los tokens de SAML. Además, los programadores y los administradores de SharePoint pueden aumentar los tokens de usuario con notificaciones adicionales. Por ejemplo, se pueden aumentar las cuentas de Windows y las cuentas basadas en formularios con notificaciones adicionales que usa SharePoint Server 2010.

El siguiente gráfico resume la compatibilidad con tipos de autenticación de cada modo de autenticación.

Tipo Autenticación de modo clásico Autenticación basada en notificaciones

Windows

  • NTLM

  • Kerberos

  • Anónima

  • Básica

  • Implícita

Sí

Sí

Autenticación basada en formularios

  • LDAP

  • Base de datos de SQL u otra base de datos

  • Proveedores de roles y pertenencia personalizados o de terceros

No

Sí

Autenticación basada en token SAML

  • ADFS 2.0

  • Windows Live ID

  • Proveedor de identidad de terceros

  • LDAP

No

Sí

Una granja de servidores de SharePoint Server 2010 puede incluir una combinación de aplicaciones web que usen ambos modos. Los servicios no diferencian entre las cuentas de usuario que son cuentas tradicionales de Windows y las cuentas de notificaciones de Windows. Por lo tanto, un usuario que pertenezca a sitios que están configurados para usar una combinación de los modos de autenticación recibirá resultados de búsqueda que incluyen los resultados de todos los sitios a los que el usuario tiene acceso, independientemente del modo configurado para las aplicaciones web. El usuario no se interpreta como dos cuentas de usuario diferentes. Esto se debe a que los servicios y aplicaciones de servicio usan identidades de notificaciones para la comunicación entre granjas de servidores, independientemente del modo que se ha seleccionado para las aplicaciones web y los usuarios.

Sin embargo, los usuarios que pertenecen a más de un repositorio de usuarios reconocido por las aplicaciones web de SharePoint Server se tratan como cuentas de usuario independientes, según la identidad que usen para iniciar sesión.

Las recomendaciones siguientes le ayudarán a decidir qué modo le conviene seleccionar:

  • Para las nuevas implementaciones de SharePoint Server 2010, use la autenticación basada en notificaciones. Con esta opción, estarán disponibles todos los tipos de autenticación compatibles para las aplicaciones web. No hay ninguna razón práctica para seleccionar la autenticación de modo clásico para las nuevas implementaciones, incluso si el entorno incluye solo cuentas de Windows. La autenticación de Windows se implementa de la misma forma, independientemente del modo seleccionado. No se requiere ningún paso adicional para implementar la autenticación de Windows cuando se usa el modo de autenticación basada en notificaciones.

  • Si va a actualizar una solución de la versión anterior a SharePoint Server 2010 y la solución incluye solo cuentas de Windows, puede usar la autenticación de modo clásico. Esto le permite usar el mismo diseño para las zonas y direcciones URL.

  • Si va a actualizar una solución que requiere la autenticación basada en formularios, la única opción es actualizar a la autenticación basada en notificaciones.

Si va a actualizar desde una versión anterior a SharePoint Server 2010 y selecciona la autenticación basada en notificaciones, tenga en cuenta las siguientes consideraciones:

  • Es posible que se deba actualizar el código personalizado. Los elementos web u otro código personalizado que usa o se basa en identidades de Windows deberá actualizarse. Si el código personalizado usa identidades de Windows, use la autenticación de modo clásico hasta que se actualice el código.

  • La migración de muchos de los usuarios de Windows a identidades de notificaciones lleva tiempo. Cuando se cambia una aplicación web de modo clásico a basada en notificaciones durante el proceso de actualización, debe usar Windows PowerShell para convertir las identidades de Windows a identidades de notificaciones. Este proceso puede ser lento. Asegúrese de dejar suficiente tiempo durante el proceso de actualización para completar esta tarea.

  • Actualmente, las alertas de búsqueda no son compatibles con la autenticación basada en notificaciones.

La autenticación basada en notificaciones se basa en WIF. WIF es un conjunto de clases de .NET Framework que se usa para implementar la identidad basada en notificaciones. La autenticación basada en notificaciones depende de estándares, como WS-Federation y WS-Trust, y de protocolos, como SAML. Para obtener más información acerca de la autenticación basada en notificaciones, vea los siguientes recursos:

No es necesario que sea arquitecto de notificaciones para usar autenticación basada en notificaciones en SharePoint Server 2010. Sin embargo, la implementación de la autenticación basada en tokens de SAML requiere la coordinación con los administradores del entorno basado en notificaciones, como se describe más adelante en este artículo.

Implementación de autenticación de Windows

El proceso de implementación de métodos de autenticación de Windows es similar para ambos modos de autenticación (clásico o basado en notificaciones). Al elegir la autenticación basada en notificaciones para una aplicación web no aumenta la complejidad de la implementación de métodos de autenticación de Windows. Esta sección resume el proceso para cada método.

Autenticación integrada de Windows: Kerberos y NTLM

Tanto el protocolo Kerberos como NTLM son métodos de autenticación integrada de Windows que permiten a los clientes autenticarse sin problemas, sin que se les pida las credenciales. Los usuarios que tienen acceso a sitios de SharePoint desde el Explorador de Windows se autentican con las credenciales bajo las que se ejecuta el proceso de Internet Explorer. De manera predeterminada, estas credenciales son las credenciales con las que el usuario inició sesión en el equipo. Los servicios o aplicaciones que obtienen acceso a SharePoint Server en el modo de autenticación integrada de Windows intentarán autenticarse con las credenciales del subproceso en ejecución, que es la identidad del proceso de manera predeterminada.

NTLM es la forma más sencilla de implementar la autenticación de Windows. Simplemente seleccione esta opción al crear una aplicación web.

El protocolo Kerberos es un protocolo seguro que admite la autenticación de vales. El uso del protocolo Kerberos requiere configuración adicional del entorno. Para habilitar la autenticación Kerberos, los equipos cliente y servidor deben tener una conexión de confianza con el centro de distribución de claves (KDC) del dominio. Para configurar el protocolo Kerberos es necesario configurar nombres principales de servicio (SPN) en AD DS antes de instalar SharePoint Server 2010.

Los pasos siguientes resumen el proceso de configuración de la autenticación Kerberos:

  1. Configure la autenticación Kerberos para comunicaciones de SQL mediante la creación de SPN en AD DS para la cuenta de servicio de SQL Server.

  2. Cree SPN para las aplicaciones web que usarán autenticación Kerberos.

  3. Instale la granja de servidores de SharePoint Server 2010.

  4. Configure servicios específicos dentro de la granja de servidores para usar cuentas específicas.

  5. Cree las aplicaciones web que usarán autenticación Kerberos.

Para obtener más información, vea Planeación de la autenticación Kerberos (SharePoint Server 2010).

Además, para las aplicaciones web con autenticación basada en notificaciones, las notificaciones al servicio de token de Windows deben configurarse para delegación restringida. Para convertir las notificaciones a tokens de Windows, se requiere delegación restringida. Para entornos que incluyan varios bosques, se requiere una confianza bidireccional entre los bosques para usar las notificaciones al servicio de token de Windows. Para obtener más información acerca de cómo configurar este servicio, vea el tema sobre la Configuración de la autenticación Kerberos para las notificaciones al servicio de token de Windows (SharePoint Server 2010)

La autenticación Kerberos permite la delegación de credenciales del cliente para obtener acceso a sistemas de datos back-end, lo que requiere una configuración adicional según el escenario. En la tabla siguiente se proporcionan algunos ejemplos.

Escenario Configuración adicional

Delegación de la identidad de un cliente a un servidor back-end.

Visualización de fuentes RSS en el contenido autenticado.

Configuración de la delegación limitada de Kerberos para los equipos y las cuentas de servicio.

Delegación de la identidad para Microsoft SQL Server Reporting Services (SSRS)

Configuración de SPN para cuentas de SQL Server Reporting Services.

Configuración de la delegación para SQL Server Reporting Services.

Delegación de la identidad para Servicios de Excel en SharePoint

Configuración de la delegación limitada para los servidores que ejecutan Servicios de Excel.

Configuración de la delegación limitada para la cuenta de servicio de Servicios de Excel.

Para obtener más información acerca de la forma de configurar la autenticación Kerberos, incluidos los pasos de configuración para los escenarios comunes, vea el tema sobre cómo configurar la autenticación Kerberos para Productos y Tecnologías de Microsoft SharePoint 2010 (notas del producto) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0xC0A).

Implícita y Básica

La implementación de la autenticación Implícita y Básica requiere la configuración de estos métodos de autenticación directamente en Internet Information Services (IIS).

Implementación de autenticación basada en formularios

La autenticación basada en formularios es un sistema de administración de identidades basado en la autenticación del proveedor de roles y el proveedor de pertenencia de ASP.NET. En SharePoint Server 2010, la autenticación basada en formularios solo está disponible cuando se usa la autenticación basada en notificaciones.

La autenticación basada en formularios se puede usar con las credenciales almacenadas en AD DS, en una base de datos como una base de datos de SQL Server o en un almacén de datos de LDAP como Novell eDirectory, Servicios de directorio Novell (NDS) o Sun ONE. La autenticación basada en formularios permite la autenticación de usuario basada en la validación de la entrada de credenciales desde un formulario de inicio de sesión. Las solicitudes sin autenticar se redirigen a una página de inicio de sesión, donde el usuario debe proporcionar credenciales válidas y enviar el formulario. Si la solicitud se puede autenticar, el sistema emite una cookie con una clave para restablecer la identidad para las solicitudes siguientes.

Si desea usar la autenticación basada en formularios para autenticar usuarios en un sistema de administración de identidades que no está basado en Windows o que es externo, debe registrar el proveedor de pertenencia y el administrador de roles en el archivo Web.config. Registrar el administrador de roles es un nuevo requisito para SharePoint Server 2010. En la versión anterior, esto era opcional. SharePoint Server 2010 usa la interfaz de administrador de roles de ASP.NET estándar para recopilar información de grupo acerca del usuario actual. El proceso de autorización de SharePoint Server 2010 trata cada rol de ASP.NET como un grupo de dominio. Los administradores de roles se registran en el archivo Web.config del mismo modo que se registran los proveedores de pertenencia para la autenticación.

Si desea administrar roles o usuarios de pertenencia desde el sitio web de Administración central de SharePoint, debe registrar el proveedor de pertenencia y el administrador de roles en el archivo Web.config del sitio web de Administración central. También debe registrar el proveedor de pertenencia y el administrador de roles en el archivo Web.config de la aplicación web que hospeda el contenido.

Para obtener más información acerca de cómo configurar la autenticación basada en formularios, vea los siguientes recursos:

Implementación de la autenticación basada en token SAML

La autenticación basada en token SAML requiere la coordinación con los administradores de un entorno basado en notificaciones, ya sea un entorno interno propio o un entorno de socios. AD FS 2.0 es un ejemplo de un entorno basado en notificaciones.

Un entorno basado en notificaciones incluye un servicio de token de seguridad de proveedor de identidad (IP-STS). IP-STS otorga tokens SAML en nombre de los usuarios que se incluyen en el directorio de usuarios asociado. Los tokens pueden incluir cualquier número de notificaciones sobre un usuario, como un nombre de usuario y los grupos a los que pertenece el usuario.

SharePoint Server 2010 aprovecha las notificaciones que se incluyen en los tokens que IP-STS proporciona para autorizar usuarios. En los entornos de notificaciones, una aplicación que acepta tokens de SAML se conoce como un STS de usuario de confianza (RP-STS). Una aplicación de usuario de confianza recibe el token de SAML y usa las notificaciones dentro del token para decidir si se va a otorgar acceso de cliente al recurso solicitado. En Productos de SharePoint 2010, cada aplicación web configurada para usar un proveedor SAML se agrega al servidor de IP-STS como una entrada de RP-STS independiente. Una granja de servidores de SharePoint puede incluir varias entradas de RP-STS.

La implementación de la autenticación basada en token de SAML con Productos de SharePoint 2010 implica los siguientes procesos que requieren planeación avanzada:

  1. Exporte el certificado de firma de tokens de IP-STS. Este certificado se conoce como ImportTrustCertificate. Copie el certificado en un equipo servidor de la granja de servidores de SharePoint Server 2010.

  2. Defina la notificación que se debe usar como identificador único del usuario. Esta se conoce como la notificación de identidad. Muchos ejemplos de este proceso usan el nombre de correo electrónico del usuario como identificador de usuario. Coordine la operación con el administrador de IP-STS para determinar el identificador correcto, ya que solo el propietario de IP-STS conoce el valor en el token que siempre es exclusivo para cada usuario. Determinar el identificador único del usuario es parte del proceso de asignación de notificaciones. Las asignaciones de notificaciones se crean mediante Windows PowerShell.

  3. Defina asignaciones de notificaciones adicionales. Defina las notificaciones adicionales del token entrante que la granja de servidores de SharePoint Server 2010 va a usar. Los roles de usuario son un ejemplo de notificación que se puede usar para los recursos de permisos en la granja de servidores de SharePoint Server 2010. Se descartan todas las notificaciones de un token entrante que no incluyen una asignación.

  4. Cree un nuevo proveedor de autenticación mediante Windows PowerShell para importar el certificado de firma de tokens. Este proceso crea el objeto SPTrustedIdentityTokenIssuer. Durante este proceso, debe especificar la notificación de identidad y las notificaciones adicionales que ha asignado. También debe crear y especificar un dominio asociado a las primeras aplicaciones web de SharePoint que configure para la autenticación basada en token de SAML. Una vez creado el objeto SPTrustedIdentityTokenIssuer, puede crear y agregar más dominios para las aplicaciones web de SharePoint adicionales. De este modo se configuran varias aplicaciones web para que usen el mismo objeto SPTrustedIdentityTokenIssuer.

  5. Para cada dominio que se agrega a SPTrustedIdentityTokenIssuer, debe crear una entrada de RP-STS en IP-STS. Esto puede hacerse antes de crear la aplicación web de SharePoint. No obstante, debe planear la dirección URL antes de crear las aplicaciones web.

  6. Cree una nueva aplicación web de SharePoint y configúrela para usar el proveedor de autenticación recientemente creado. Cuando se selecciona el modo de notificaciones para la aplicación web, el proveedor de autenticación aparece como una opción en Administración central.

Puede configurar varios proveedores de autenticación basados en tokens de SAML. Sin embargo, solo puede usar un certificado de firma de tokens una vez en una granja de servidores. Todos los proveedores configurados aparecen como opciones en Administración central. Las notificaciones procedentes de diferentes entornos de STS de confianza no producen un conflicto.

Si desea implementar la autenticación basada en token de SAML con una compañía asociada y su entorno incluye IP-STS, se recomienda trabajar con el administrador de su entorno de notificaciones interno para establecer una relación de confianza desde el IP-STS interno hasta el STS del asociado. Este enfoque no requiere agregar un proveedor de autenticación adicional a la granja de servidores de SharePoint Server 2010. También permite a los administradores de notificaciones administrar todo el entorno de notificaciones.

Nota

Si usa la autenticación basada en token de SAML con AD FS en una granja de servidores de SharePoint Server 2010 con varios servidores web en una configuración de carga equilibrada, es posible que se produzca un efecto en el rendimiento y la funcionalidad de las vistas de las páginas web cliente. Cuando AD FS proporciona el token de autenticación al cliente, ese token se envía a SharePoint Server 2010 para cada elemento de página con permisos restringidos. Si la solución de carga equilibrada no usa afinidad, cada elemento seguro se autentica en más de un servidor de SharePoint Server 2010, lo que puede provocar el rechazo del token. Una vez rechazado el token, SharePoint Server 2010 redirige el cliente para volver a autenticarlo en el servidor AD FS. Después de esto, un servidor AD FS puede rechazar varias solicitudes si se realizan en un período de tiempo breve. Este comportamiento está diseñado para protegerse contra un ataque por denegación de servicio. Si el rendimiento se ve afectado negativamente o las páginas no se cargan completamente, considere la posibilidad de establecer el equilibrio de carga de la red en una sola afinidad. Esto permite aislar las solicitudes de tokens de SAML en un solo servidor web.

Para obtener más información acerca de cómo configurar la autenticación basada en token de SAML, vea los siguientes recursos:

Elección de la autenticación para los entornos de LDAP

Los entornos de LDAP se pueden implementar mediante la autenticación basada en formularios o la autenticación basada en token de SAML. Se recomienda usar la autenticación basada en formularios, ya que es menos compleja. Sin embargo, si el entorno es compatible con WS-Federation 1.1 y SAML Token 1.1, se recomienda usar SAML. La sincronización de perfiles no es compatible con los proveedores LDAP que no se encuentran asociados a ADFS 2.0.

Planeación de zonas para aplicaciones web

Las zonas representan diferentes rutas de acceso lógicas para obtener acceso a los mismos sitios en una aplicación web. Cada aplicación web puede incluir hasta cinco zonas. Cuando se crea una aplicación web, se crea la zona predeterminada. Para crear zonas adicionales, se debe ampliar la aplicación web y seleccionar uno de los nombres de zona restantes: intranet, extranet, Internet o personalizada.

En las versiones anteriores, las zonas se usan para implementar distintos tipos de autenticación para los usuarios procedentes de redes o proveedores de autenticación diferentes. En la versión actual, la autenticación de notificaciones permite implementar varios tipos de autenticación en la misma zona.

La planeación de las zonas depende del modo que se encuentra seleccionado para una aplicación web. Los modos disponibles son:

  • Clásico: es similar a las versiones anteriores, solo se puede implementar un tipo de autenticación por zona. Sin embargo, en la versión actual, solo la autenticación de Windows se puede implementar cuando se selecciona el modo clásico. Por lo tanto, es posible usar varias zonas solamente para implementar varios tipos de autenticación de Windows o para implementar el mismo tipo de autenticación de Windows en diferentes almacenes de Active Directory.

  • Autenticación de notificaciones: permite implementar varios proveedores de autenticación en una sola zona. También se pueden usar varias zonas.

Implementación de más de un tipo de autenticación en una sola zona

Si se usa la autenticación de notificaciones y es necesario implementar más de un tipo de autenticación, se recomienda implementar varios tipos de autenticación en la zona predeterminada. Esto produce como resultado la misma dirección URL para todos los usuarios.

Cuando se implementan varios tipos de autenticación en la misma zona, se aplican las siguientes restricciones:

  • Solo se puede implementar una versión de la autenticación basada en formularios en una zona.

  • La Administración central permite usar un método Windows Integrado y Básico al mismo tiempo. De lo contrario, no se puede implementar más de un tipo de autenticación de Windows en una zona.

Si se configuran varios proveedores de autenticación basada en token SAML para una granja de servidores, estos proveedores aparecen como opciones al crear una aplicación web o una zona nueva. En la misma zona, se pueden configurar varios proveedores SAML.

En el siguiente diagrama se ilustran varios tipos de autenticación que se implementan en la zona predeterminada para un sitio de colaboración de asociados.

Varios tipos de autenticación en una zona

En el diagrama, los usuarios de almacenes de directorios diferentes obtienen acceso al sitio web asociado mediante la misma dirección URL. Un cuadro de líneas discontinuas que rodea a las compañías asociadas muestra la relación entre el directorio de usuarios y el tipo de autenticación configurado en la zona predeterminada. Para obtener más información acerca de este ejemplo de diseño, vea Ejemplo de diseño: Implementación corporativa (SharePoint Server 2010).

Planeación para el rastreo de contenido

El componente de rastreo requiere obtener acceso al contenido mediante NTLM. Para usar la autenticación NTLM, es necesario configurar al menos una zona. Si la autenticación NTLM no está configurada en la zona predeterminada, el componente de rastreo puede usar una zona diferente que esté configurada para usar la autenticación NTLM.

Implementación de más de una zona

Si tiene previsto implementar más de una zona para las aplicaciones web, siga estas pautas:

  • Use la zona predeterminada para implementar la configuración de autenticación más segura. Si no se puede asociar una solicitud con una zona específica, se aplican la configuración de autenticación y otras directivas de seguridad de la zona predeterminada. La zona predeterminada es la que se crea al crear inicialmente una aplicación web. Normalmente, la configuración de autenticación más segura está diseñada para el acceso de usuarios finales. Por consiguiente, es probable que los usuarios finales tengan acceso a la zona predeterminada.

  • Use el número de zonas mínimo necesario para proporcionar acceso a los usuarios. Cada zona se asocia a nuevo dominio y sitio de IIS para obtener acceso a la aplicación web. Agregue nuevos puntos de acceso sólo cuando sean necesarios.

  • Asegúrese de que al menos una zona esté configurada para usar la autenticación NTLM para el componente de rastreo. No cree una zona dedicada para el componente de indización a menos que sea necesario.

En el siguiente diagrama se ilustran varias zonas que se implementan para incluir diferentes tipos de autenticación para un sitio de colaboración de asociados.

Una zona para cada tipo de autenticación

En el diagrama, la zona predeterminada se usa para los empleados remotos. Cada zona tiene una dirección URL diferente asociada. Los empleados usan una zona diferente cuando trabajan en la oficina o trabajan de forma remota. Para obtener más información acerca de este ejemplo de diseño, vea Ejemplo de diseño: Implementación corporativa (SharePoint Server 2010).

Arquitectura para los proveedores basados en token SAML

La arquitectura para implementar proveedores basados en token SAML incluye los siguientes componentes:

Servicio de token de seguridad de SharePoint   Este servicio crea los tokens SAML que la granja de servidores usa. El servicio se crea y se inicia automáticamente en todos los servidores de la granja. El servicio se usa para la comunicación entre granjas ya que en toda comunicación entre granjas se usa la autenticación de notificaciones. Este servicio también se usa en los métodos de autenticación que se implementan para las aplicaciones web que usan la autenticación de notificaciones, incluida la autenticación de Windows, la autenticación basada en formularios y la autenticación basada en token SAML. Debe configurar el servicio de token de seguridad durante el proceso de implementación. Para obtener más información, vea Configuración del servicio de token de seguridad (SharePoint Server 2010).

Certificado de firma de tokens (ImportTrustCertificate)   Este es el certificado que se exporta de IP-STS. El certificado se copia en un servidor de la granja de servidores. Una vez que se usa este certificado para crear un objeto SPTrustedIdentityTokenIssuer, no se puede volver a usar para crear otro. Si desea usar el certificado para crear un objeto SPTrustedIdentityTokenIssuer diferente, primero debe eliminar el objeto existente. Antes de eliminar el objeto existente, debe desasociarlo de todas las aplicaciones web que puedan estar usándolo.

Notificación de identidad   La notificación de identidad es la notificación de un token SAML que funciona como identificador único del usuario. Solo el propietario de IP-STS conoce el valor en el token que siempre es exclusivo para cada usuario. La notificación de identidad se crea como una asignación de notificaciones habitual durante el proceso de asignación de todas las notificaciones deseadas. La notificación que debe funcionar como la notificación de identidad se determina al crear el objeto SPTrustedIdentityTokenIssuer.

Otras notificaciones   Estas notificaciones están compuestas por notificaciones adicionales de un vale SAML que describen usuarios. Estas notificaciones pueden incluir roles de usuario, grupos de usuarios u otros tipos de notificaciones como la edad. Todas las asignaciones de notificaciones se crean como objetos que se replican en todos los servidores de una granja de servidores de SharePoint Server.

Dominio   En la arquitectura de notificaciones de SharePoint, el identificador URI o la dirección URL que se asocia a una aplicación web de SharePoint configurada para usar un proveedor basado en token SAML representa un dominio. Al crear un proveedor de autenticación basado en SAML en la granja de servidores, debe especificar los dominios, o las direcciones URL de la aplicación web, que desea que IP-STS reconozca, uno cada vez. El primer dominio se especifica al crear el objeto SPTrustedIdentityTokenIssuer. Una vez creado SPTrustedIdentityTokenIssuer, puede agregar dominios adicionales. Los dominios se especifican mediante una sintaxis similar a la siguiente: $realm = "urn:sharepoint:mysites". Después de agregar el dominio a SPTrustedIdentityTokenIssuer, debe crear un RP-STS de confianza con el dominio del servidor de IP-STS. Este proceso consiste en especificar la dirección URL de la aplicación web.

SPTrustedIdentityTokenIssuer   Este es el objeto que se crea en la granja de servidores de SharePoint que incluye los valores necesarios para comunicarse con IP-STS y recibir tokens de IP-STS. Al crear el objeto SPTrustedIdentityTokenIssuer, debe especificar el certificado de firma de tokens que desea usar, el primer dominio, la notificación que representa a la notificación de identidad, y las notificaciones adicionales. Puede asociar un certificado de firma de tokens de un STS a un solo objeto SPTrustedIdentityTokenIssuer. Sin embargo, después de crear el objeto SPTrustedIdentityTokenIssuer, puede agregar más dominios para las aplicaciones web adicionales. Después de agregar un dominio al objeto SPTrustedIdentityTokenIssuer, también debe agregarlo al IP-STS como usuario de confianza. El objeto SPTrustedIdentityTokenIssuer se replica a través de todos los servidores de la granja de servidores de SharePoint Server.

Servicio de token de seguridad de usuario de confianza (RP-STS)   En SharePoint Server 2010, cada aplicación web configurada para usar un proveedor SAML se agrega al servidor de IP-STS como una entrada de RP-STS. Una granja de servidores de SharePoint Server puede incluir varias entradas de RP-STS.

Servicio de token de seguridad de proveedor de identidad (IP-STS)   Este es el servicio de token de seguridad en el entorno de notificaciones que otorga tokens SAML en nombre de los usuarios que se incluyen en el directorio de usuarios asociado.

En el siguiente diagrama se ilustra la arquitectura de notificaciones de Productos de SharePoint 2010.

Componentes de la autenticación de notificaciones de SharePoint

El objeto SPTrustedIdentityTokenIssuer se crea mediante varios parámetros. En el diagrama siguiente se muestran los parámetros clave.

Diseño SPTrustedIdentityTokenIssuer

Tal como se muestra en el diagrama, un objeto SPTrustedIdentityTokenIssuer solamente puede incluir una notificación de identidad, un parámetro SignInURL y un parámetro Wreply. Sin embargo, puede incluir varios dominios y varias asignaciones de notificaciones. El parámetro SignInURL especifica la dirección URL a la que se debe redirigir una solicitud de usuario con el fin de autenticarla en IP-STS. Algunos servidores de IP-STS requieren el parámetro Wreply, que se establece en "true" o "false" y se encuentra en "false" de manera predeterminada. Solamente puede usar el parámetro Wreply si es un requisito de IP-STS.