Crear complementos de SharePoint que usan la autorización de elevada confianza

  • Artículo

Un complemento de elevada confianza es una Complemento de SharePoint hospedada por el proveedor que se instala en una granja local de SharePoint. No se puede instalar en Microsoft SharePoint Online ni vender en la Tienda Office. Un complemento de elevada confianza usa un certificado en lugar de un token de contexto para establecer la confianza.

Nota:

En este tema le explicamos el sistema de autorización de baja confianza para complementos de SharePoint. Si quiere información práctica sobre la creación e implementación de complementos de elevada confianza, vea los temas siguientes:

En SharePoint, el servicio de token de seguridad (STS) proporciona tokens de acceso para la autenticación de servidor a servidor. El servicio STS habilita tokens de acceso temporal para tener acceso a otros servicios de aplicaciones tales como Exchange, Lync y complementos de SharePoint. Un administrador de granjas establece la confianza entre SharePoint y la otra aplicación o el otro complemento mediante cmdlets de Windows PowerShell y un certificado. Cada certificado que se usa debe ser de confianza para SharePoint mediante el New-SPTrustedRootAuthority cmdlet . Además, cada certificado debe registrarse con SharePoint como emisor de tokens mediante el cmdlet New-SPTrustedSecurityTokenIssuer.

Nota:

El servicio STS no tiene como finalidad la autenticación de usuarios. Por lo que no verá el servicio STS en la página de inicio de sesión de usuario, en la sección Proveedor de autenticación de Administración central ni en el Selector de personas de SharePoint.

Dos tipos de emisores de tokens

La aplicación web remota de un complemento de SharePoint de elevada confianza se enlaza a un certificado digital. (Para obtener información sobre cómo hacerlo, vea los dos temas vinculados anteriormente). La aplicación web remota usa el certificado para firmar los tokens de acceso que incluye en todas las solicitudes a SharePoint. La aplicación web firma el token con la clave privada del certificado y SharePoint lo valida con la clave pública del certificado. El certificado ha de estar registrado como emisor de tokens de confianza para que SharePoint confíe en los tokens que emite.

Existen dos tipos de emisores de tokens: algunos solo pueden emitir tokens para un complemento concreto de SharePoint; otros, denominados agentes de confianza, pueden emitir tokens para varios complementos de SharePoint.

A efectos prácticos, los administradores de la granja de SharePoint determinan el tipo de emisor de token que se crea con los modificadores y valores de parámetro que usan con el cmdlet New-SPTrustedSecurityTokenIssuer. Para crear un emisor de token que sea un agente de confianza, agregue el modificador -IsTrustBroker a la línea de comandos y use un valor único (que no sea el identificador de cliente del complemento) para el parámetro -Name. Este es un ejemplo modificado.

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

Para crear un emisor de tokens que no sea un agente, no se usa el modificador -IsTrustBroker. Hay otra diferencia. El valor del parámetro -RegisteredIssuerName siempre tiene el formato de dos GUID separados por el carácter "@"; GUID@GUID. El GUID de la derecha siempre es el identificador del kerberos de autenticación de la granja de SharePoint (o la suscripción a sitios). El GUID de la izquierda es siempre el identificador específico de un emisor de tokens.

Cuando se crea un emisor de tokens de agente de confianza es un GUID aleatorio. Pero, cuando se crea un emisor de tokens que no sea agente, el GUID específico del emisor debe tener el mismo GUID que se usa como identificador de cliente del complemento de SharePoint. Este parámetro proporciona un nombre para el emisor. También le indica a SharePoint qué complemento de SharePoint es el único para el que el certificado puede emitir tokens. Este es un ejemplo parcial:

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

Normalmente, el cmdlet New-SPTrustedSecurityTokenIssuer se usa en un script que realiza otras tareas para configurar SharePoint con complementos de elevada confianza. Para obtener más información sobre estos scripts y ejemplos completos del cmdlet New-SPTrustedSecurityTokenIssuer, vea Scripts de configuración de elevada confianza para SharePoint.

Decidir entre usar un certificado o varios para complementos de SharePoint de elevada confianza

El administrador de red y de SharePoint tiene dos estrategias básicas entre las que elegir al obtener y administrar certificados para su uso por complementos de SharePoint de elevada confianza:

  • Usar el mismo certificado para varios complementos de SharePoint.

  • Usar un certificado distinto para cada Complemento de SharePoint.

En esta sección se describen las ventajas y los inconvenientes de cada estrategia.

La ventaja de usar el mismo certificado para varios complementos de SharePoint estriba en que un administrador tiene menos certificados que administrar y en los que confiar. El inconveniente de este enfoque es que, si se encuentra en una situación en la que quiere romper la relación de confianza con un determinado complemento de SharePoint, la única forma que tiene el administrador de hacerlo consiste en quitar el certificado como emisor de tokens o como entidad de certificación raíz. Pero al hacerlo, también rompe la relación de confianza con los demás complementos de SharePoint que usan el mismo certificado, lo que hace que todos dejen de funcionar.

Para que los complementos de SharePoint de confianza vuelvan a funcionar, el administrador tendría que crear un New-SPTrustedSecurityTokenIssuer objeto con un nuevo certificado e incluir la -IsTrustBroker marca. Habrá que registrar el nuevo certificado con cada servidor que hospede cualquiera de los complementos de confianza y cada uno de esos complementos tendrá que enlazarse al nuevo certificado.

La ventaja de usar un solo certificado por complemento es que resulta más fácil romper la relación de confianza con un complemento concreto, ya que los certificados que usan los complementos que siguen siendo de confianza no se ven afectados cuando el administrador rompe la relación de confianza con el certificado del único complemento. El inconveniente de esta estrategia estriba en que un administrador tiene más certificados que adquirir y hay que configurar SharePoint para que use cada uno de ellos, lo que puede hacerse con un script reutilizable, tal y como se muestra en Scripts de configuración de elevada confianza para SharePoint.

Los certificados son entidades de certificación raíz en SharePoint

Como se menciona brevemente al principio de este artículo, los administradores de granja de SharePoint tienen que convertir el certificado de la aplicación web remota del complemento de elevada confianza en una entidad de certificación raíz de confianza de SharePoint, así como en un emisor de tokens de confianza. De hecho, cuando hay una jerarquía de entidades de certificación que emiten certificados detrás del certificado de la aplicación web, todos los certificados de la cadena deben agregarse a la lista de entidades de certificación raíz de confianza de SharePoint.

Cada certificado de la cadena se agrega a la lista de entidades raíz de confianza de SharePoint con una llamada del New-SPTrustedRootAuthority cmdlet . Supongamos, por ejemplo, que el certificado de la aplicación web es un certificado de dominio que lo emite una entidad de certificación de dominios de empresa de la LAN, y que su certificado, a su vez, lo emitió una entidad de certificación independiente de primer nivel de la LAN. En este escenario, los certificados de la CA de primer nivel, la CA intermedia y la aplicación web deben agregarse a la lista de SharePoint de entidades de certificación raíz de confianza. Esto se puede hacer con el siguiente código de Windows PowerShell.

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate

Los certificados intermedios y raíz deben agregarse una sola vez en una granja de SharePoint. Normalmente, se agrega el certificado de la aplicación web en un script independiente que realiza otras tareas de configuración, como la llamada a New-SPTrustedSecurityTokenIssuer. Para obtener ejemplos, vea Scripts de configuración de elevada confianza para SharePoint.

Si el certificado de la aplicación web es autofirmado, como podría ser el caso cuando el complemento se está desarrollando y depurando, no existe ninguna cadena de certificados y solo hay que agregar el certificado de la aplicación web a la lista de entidades de certificación raíz.

Para obtener más información, vea la entrada de blog sobre el error que indica que la raíz de la cadena de certificados no es de confianza con autenticación de notificaciones. Pase por alto la sección sobre la exportación del certificado desde los Servicios de federación de Active Directory (AD FS), dando por supuesto que el certificado se creó para los complementos de elevada confianza por otros medios; por ejemplo, con un certificado comercial emitido por una entidad de certificación, un certificado autofirmado o un certificado emitido por el dominio.

La aplicación web tiene que saber que se trata de un emisor de tokens

El componente de aplicación web remota del complemento de SharePoint se enlaza a su certificado digital. Esto es suficiente para los fines tradicionales de los certificados: identificar de forma segura la aplicación web y codificar las solicitudes y respuestas HTTP.

Aunque, en un complemento de SharePoint de elevada confianza, el certificado tiene la tarea adicional de ser el "emisor" oficial de los tokens de acceso que la aplicación web envía a SharePoint. Para esta finalidad, la aplicación web tiene que conocer el identificador del emisor del certificado que se usa al registrar el certificado como emisor de tokens con SharePoint. La aplicación web obtiene este identificador de la sección appSettings del archivo Web.config, donde existe una clave denominada IssuerId.

En Empaquetar y publicar complementos de SharePoint de elevada confianza encontrará instrucciones sobre cómo el desarrollador del complemento establece este valor y cómo el certificado se enlaza a la aplicación web en IIS.

Tenga en cuenta que si el cliente usa la estrategia de tener un certificado independiente para cada complemento de SharePoint de elevada confianza, el valor de ClientId se usa también como valor de IssuerId. Este no es el caso cuando varios complementos comparten el mismo certificado, ya que cada complemento de SharePoint ha de tener su propio identificador de cliente único, pero el identificador del emisor es el identificador de un objeto SPTrustedSecurityTokenIssuer.

A continuación, verá un ejemplo de una sección appSettings para una Complemento de SharePoint de elevada confianza. En este ejemplo, varios complementos comparten un certificado, de modo que el IssuerId no es el mismo que el ClientId. Observe que no hay ninguna clave ClientSecret en una Complemento de SharePoint de elevada confianza.

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

Nota:

En el ejemplo anterior se supone que el certificado está almacenado en el sistema de archivos. Esto es aceptable para desarrollo y depuración. En un complemento de SharePoint de elevada confianza de producción, el certificado suele almacenarse en el Almacén de certificados de Windows y las claves ClientSigningCertificatePath y ClientSigningCertificatePassword suelen reemplazarse normalmente por una clave ClientSigningCertificateSerialNumber.

Responsabilidades del personal de TI en el sistema de elevada confianza

Los desarrolladores tienen que comprender los requisitos para la seguridad de las aplicaciones que se han descrito anteriormente, pero los profesionales de TI serán los encargados de implementar la infraestructura necesaria para ello. Los profesionales de TI deben planear los siguientes requisitos operativos:

  • Crear o comprar uno o más certificados que se usarán para los complementos de SharePoint de confianza.

  • Asegurarse de que los certificados se almacenan de forma segura en los servidores de aplicaciones web. El uso del sistema operativo Windows implica almacenar los certificados en el Almacén de certificados de Windows.

  • Administrar la distribución de dichos certificados a los desarrolladores que compilan complementos de SharePoint.

  • Realizar un seguimiento de dónde se distribuye cada certificado, tanto para los complementos que lo usen como para los desarrolladores que hayan recibido una copia. Si se tiene que revocar un certificado, el personal de TI debe trabajar con cada desarrollador para organizar una transición administrada a un nuevo certificado.

Ver también