Configuración de la confianza OAuth entre granjas de servidores en SharePoint 2013

Artículo original publicado el lunes, 23 de julio de 2012

Una de las cosas de las que probablemente oirá hablar en SharePoint 2013, y sobre la que puede que yo acabe escribiendo bastante, es OAuth. En SharePoint 2013, OAuth se utiliza para establecer una confianza entre dos aplicaciones con el fin de establecer la identidad de una entidad de seguridad (de usuario o de aplicación). En SharePoint se usan confianzas OAuth entre SharePoint y otras aplicaciones como Exchange o Lync, con ACS o desarrolladores de aplicaciones individuales que usen el nuevo modelo de aplicaciones en la nube, o incluso entre granjas de servidores de SharePoint distintas como la característica de índice de SharePoint remoto usada en Búsqueda.

 

Lo que OAuth NO hace es servir como proveedor de autenticación para los usuarios; tendrá que seguir usando su New-SPTrustedIdentityTokenIssuer para crear estas relaciones de confianza con sus proveedores de identidades. Para las confianzas OAuth, tenemos un nuevo cmdlet con un nombre similar, el New-SPTrustedSecurityTokenIssuer. Cuando establecemos este tipo de relación de confianza con un emisor de tokens de seguridad, lo llamamos una confianza S2S, que, por sus siglas en inglés, significa “de servidor a servidor”. Recuerde este acrónimo, ya que lo verá bastante en SharePoint 2013. En esta publicación hablaré sobre algunos de los requisitos concretos para crear este protocolo de confianza.

 

En primer lugar, cabe destacar que muchas de las características que necesitan una confianza S2S establecen esta confianza por sí mismas. Es posible que se haga mediante la activación de características, o bien que los equipos de características le proporcionen un cmdlet o script de PowerShell ejecutable que creará la confianza durante el proceso de activación de su característica. En algunas ocasiones, sin embargo, será necesario que lo haga usted, y eso es lo que se trata en este artículo.

 

Una de las primeras cosas que debe hacer es averiguar si usará SSL o no. En SharePoint 2013, la mayoría de las veces se utiliza SSL. Lo comento porque hay muchos escenarios que usan OAuth en SharePoint 2013, y cuando lo hace, se transfiere una cookie con un token de acceso. Este token de acceso es como una llave que abre la puerta a los datos. Un certificado firma el token de acceso para que nadie que cree su propio token de acceso lo pueda burlar, pero seguro que no quiere que esté a la vista de todos, con todas sus letras, porque alguien podría seleccionar esa cookie y utilizar su duración al reproducirla. SSL le protege de este ataque del mismo modo que si usara SSL con un sitio de autenticación basado en formularios con el mismo propósito. Dicho esto, todavía hay razones por las que podría querer ejecutar sus sitios en HTTP: se encuentra en un entorno de prueba, está creando un entorno para desarrolladores, está trabajando únicamente en una red interna y no cree que exista ningún riesgo, etc. No estoy aquí para juzgar, sino para explicar.J

 

PASO 1: Configure el STS

Hay dos valores en la configuración del servicio de token de seguridad (STS) de SharePoint que quizás desee ajustar si no va a usar SSL. Con este cmdlet puede obtener todos los ajustes de configuración del STS: Get-SPSecurityTokenServiceConfig. Existen dos maneras de establecer una relación de confianza: con un certificado o usando un extremo de metadatos OAuth nuevo que tienen todas las granjas de servidores de SharePoint. Este último es el método más sencillo, siempre que dicho extremo no disponga de seguridad SSL cuando tenga que establecer como verdadera la propiedad AllowMetadataOverHttp del STS de SharePoint. Si no planea ejecutar sus aplicaciones web en SSL, será necesario que también establezca la propiedad AllowOAuthOverHttp como verdadera. A continuación puede ver un breve PowerShell que muestra cómo configurar estas propiedades:

 

$c = Get-SPSecurityTokenServiceConfig

$c.AllowMetadataOverHttp = $true

$c.AllowOAuthOverHttp= $true

$c.Update()

 

PASO 2: Cree la confianza

Una vez que haya configurado el STS según se indica, nos centraremos en cómo establecer la relación de confianza entre dos granjas de servidores. Como ya he mencionado, todas las granjas de servidores de SharePoint tienen un extremo de metadatos que se usan para proporcionar información y el certificado de firma de tokens de acceso. Este extremo de metadatos se encuentra en /_layouts/15/metadata/json/1. Si trata de obtener acceso a él en un navegador, se le pedirá si quiere guardarlo, acción que puede hacer para examinarlo. Cuando lo abra en el bloc de notas, observará que se trata de una simple carga JSON. Verá que incluye el identificador de nombre del STS (al que llama “issuer”) y una versión serializada del certificado de firma de tokens (al que describe como "value" de la clave “x509certificate”). Si se fija un poco más, verá que el emisor ("issuer") es el nombre del servicio + “@” + valores del dominio. Además, enlaza con la propiedad NameIdentifier del STS. Esta información es importante, como verá más adelante.

 

Para el ejemplo siguiente, imaginemos que FARM_B (granja de servidores B) necesita crear una confianza con las llamadas de FARM_A (granja de servidores A) porque FARM_A usará FARM_B como índice de SharePoint remoto. Además, FARM_A tiene una aplicación web en https://FARM_A. Para crear la relación de confianza, tendríamos que ejecutar el cmdlet New-SPTrustedSecurityTokenIssuer en un servidor de FARM_B de este modo (después explicaré por qué he utilizado “$i = “):

 

$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description "FARM_A description" -IsTrustBroker:$false -MetadataEndPoint "https://FARM_A/_layouts/15/metadata/json/1"

 

Ahora supongamos que va a configurar una relación de confianza con una granja solo de servicios. Como no desea crear una aplicación web, una colección de sitios y un certificado SSL para poder crear la confianza a partir de ellos, puede seguir otro procedimiento con el que establecer la relación de confianza con el cmdlet New-SPTrustedSecurityTokenIssuer. Con este segundo método, puede proporcionar simplemente el certificado de firma de tokens y el identificador de nombres. Puede conseguir el certificado de firma de tokens del mismo modo que en SharePoint 2010: vaya a un servidor de la granja, ejecute el MMC y agregue el complemento Certificados para el equipo local. Observe el nodo de Certificados de SharePoint: el primero que aparece en la lista es el que nos interesa. Guárdelo en la unidad local sin la clave privada como un archivo .cer. Para establecer la relación de confianza, necesita el certificado y el atributo NameIdentifier del STS descrito anteriormente. En este caso, el cmdlet se mostraría así (asumiendo que ha copiado el certificado STS en un archivo con el nombre C:\sts.cer en un servidor de FARM_B):

 

$i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "FARM_A description" -IsTrustBroker:$false

 

PASO 3: Confíe en la firma de tokens

De igual manera que con un SPTrustedIdentityTokenIssuer, es necesario que agregue la confianza que utilizó para firmar tokens OAuth a la lista de entidades de certificación raíz de confianza de SharePoint. De nuevo, tiene dos opciones para hacerlo: si crea la confianza mediante el extremo de metadatos, puede establecer la confianza de esta manera:

 

New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint https://FARM_A/_layouts/15/metadata/json/1/rootcertificate

 

Otra manera de hacerlo es crearla y agregarla a las entidades de certificación raíz de confianza como lo haría en SharePoint 2010:

 

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")

New-SPTrustedRootAuthority -Name "Token Signing Root CA Certificate" -Certificate $root

 

Respecto a la confianza, ya ha realizado los pasos necesarios: ha establecido la confianza y ahora puede crear entidades de seguridad de aplicación a partir de ella. La forma en que la utilizará depende de la aplicación; si se trata de un índice de SharePoint remoto, continúe leyendo para completar el escenario.

 

PASO 4: Cree una entidad de seguridad de aplicación (ejemplo válido solo para un índice de SharePoint remoto):

Este procedimiento consta de dos pasos: la obtención de una entidad de seguridad de aplicación y la asignación de derechos. Recuerde el ejemplo anterior, en el que FARM_B necesitaba confiar en las llamadas de FARM_A, ya que ahora recibirá consultas del índice de SharePoint remoto. Por tanto, para mi entidad de seguridad de aplicación necesito conseguir una referencia a la aplicación web de FARM_B que FARM_A utilizará. Cuando tenga esa referencia, podré conceder a FARM_A los derechos necesarios para utilizarla.

 

Para obtener una referencia a la entidad de seguridad de aplicación, utilice el cmdlet de esta manera:

 

$p = Get-SPAppPrincipal -Site https://FARM_B -NameIdentifier $i.NameId

 

IMPORTANTE: Hay una cosa que se debe tener en cuenta y que creo que es especialmente común en SharePoint 2013 beta. Es posible que salgan errores extraños en PowerShell cuando trata de obtener el SPAppPrincipal. He descubierto que si la memoria disponible de su servidor baja del 5%, todas las llamadas de WCF fallan. Como este cmdlet de PowerShell llama a un extremo de aplicación de servicio que se hospeda como un WCF, el cmdlet Get-SPAppPrincipal falla cuando tiene poca memoria. Puede comprobar si esta es la causa de su problema en el registro de la aplicación, en el Visor de eventos de Windows. A mí me ha ocurrido muchas veces, así que probablemente le pase a otros también.

 

Como he descrito anteriormente en la publicación, al final conseguí utilizar la variable $i para seleccionar el NameIdentifier del STS de FARM_A. Ahora que cuento con una referencia a la entidad de seguridad de aplicación para la aplicación web de FARM_B, puedo concederle derechos de este modo:

 

Set-SPAppPrincipalPermission -Site https://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl

 

Y eso es todo: todas las opciones y métodos para crear una confianza OAuth entre dos granjas de servidores de SharePoint. Seguiré profundizando en OAuth, en sus usos y en los problemas de los que hay que estar al corriente en este blog.

Esta entrada de blog es una traducción. Puede consultar el artículo original en Setting Up an OAuth Trust Between Farms in SharePoint 2013