Modelo de apps en detalle (III): High-Trust

En los primeros dos posts de esta serie hemos visto la evolución del código personalizado en SharePoint y la arquitectura básica del modelo de apps. También hemos visto a grandes rasgos como la app se autentica con SharePoint utilizando Azure Access Control Service (ACS) como intermediario.

Las apps en SharePoint Online funcionan con este método de autorización de las apps, llamado low-trust.

Modelo Low-Trust: SharePoint + app + ACS

En este modelo, SharePoint es el responsable de pasar un token de contexto a la app, cuando hace la redirección a ella. La app valida el token de contexto y lo intercambia por un token de acceso, haciendo una llamada a ACS. Fijaos que el modelo low-trust deja a la app como un mero transmisor de tokens entre SharePoint y ACS. Por eso mismo se llama de "baja confianza". La app no puede añadir ni quitar nada de la información de autenticación y autorización. Todo esto viene dado en el token inicial que se le pasa a la app desde SharePoint.

Este modelo es muy útil para apps públicas sobre las que no tenemos ningún control. Por ello es el modelo usado para la SharePoint Store y las apps disponibles en SharePoint Online. En los entornos on-premise corporativos, este modelo requiere dar conectividad a Internet a los servidores de SharePoint y los servidores de las apps así como establecer una relación de confianza entre SharePoint on-premise y el servicio ACS de Azure.

Modelo High-Trust: SharePoint + app

En los entornos corporativos on-premise de SharePoint, podemos usar otro modelo de autorización y autenticación de las apps, en el que SharePoint establece una relación de confianza con la app y delega en ella la autenticación del usuario. Este modelo es el llamado high-trust o de alta confianza. También se le llama S2S (Server-to-Server).

No hay que confundir el modelo de high-trust con full-trust. Full-trust es el código personalizado de servidor de SharePoint que desplegamos en la GAC, y por lo que tiene todos los permisos que tiene SharePoint. Una app high-trust tendrá como mucho los permisos que se le han otorgado durante su instalación, ni más ni menos, idéntico al caso de las low-trust apps.

Entonces, ¿por qué se llama "de alta confianza"? Es así debido a que no hay un intermediario (como ACS) y que SharePoint se fía de la app para que le construya el token de acceso adecuado.

Para que el modelo high-trust funcione, tenemos que habilitar una relación de confianza entre la app y SharePoint. Esto se consigue utilizando un certificado digital. La parte pública de este certificado se registra en SharePoint como "trusted token issuer" o emisor de tokens de confianza. En el caso de las low-trust apps, el único "emisor de tokens de confianza" es el ACS. La parte privada del certificado se usará en la app para firmar los tokens emitidios por ella.

Al ser la app un emisor de tokens de confianza, SharePoint aceptará los tokens que ella misma construya. Previamente los validará con la clave pública del certificado, lo que comprueba que no han estados modificados durante el tránsito. Luego, aplicará los permisos que tiene la app en SharePoint (que se le han dado al instalarla) e incluirá la información del usuario actual (que está contenida en el token de acceso que construye la app).

Fijaos que la app puede construir el token de acceso para cualquier usuario. Esta es la parte en la que nos tenemos que "fiar" de la app. Sin embargo, el ámbito de actuación de la app está limitado a los permisos que se le han dado al instalar, así que aunque la app puede "falsear" la información del usuario (como decir que viene de parte de la cuenta del sistema), como mucho puede hacer lo que se le permite a la app, sin poder saltárselo.

Vayamos a ver el "baile" de conversación entre SharePoint y una app high-trust al abrir la app desde el navegador.

1. El usuario abre una página de SharePoint y clica en el enlace de la app.
2. SharePoint hace la redirección a la URL de la app (respuesta 302 de HTTP). No incluye ningún token de contexto (como en el caso de las low-trust apps).
3. El navegador realiza la petición a la URL de MiApp.com como respuesta a la redirección.
4. La aplicación recibe la petición HTTP. Para acceder a SharePoint mediante CSOM o REST, la aplicación necesita un token de acceso. La aplicación construye el token de acceso y lo firma con la clave privada de su certificado. Incluye este token en la petición a SharePoint.
5. SharePoint comprueba la validez del token de acceso con la clave pública del certificado de la aplicación y devuelve los datos que la aplicación le ha pedido.
6. La aplicación renderiza el HTML que se va a visualizar y lo devuelve al navegador.

Construyendo los tokens de acceso

La misma clase auxiliar TokenHelper.cs que usamos en las apps de ASP.NET contiene los métodos para construir los tokens de acceso de high-trust apps. Si miramos el código fuente del mismomiramos el código fuente del mismo, veremos dos métodos:

• GetS2SAccessTokenWithWindowsIdentity
• GetS2SClientContextWithWindowsIdentity

El primer método devuelve un token de acceso para un usuario concreto, firmado con la clave privada del certificado de la app. El segundo devuelve un contexto de SharePoint CSOM (ClientContext) inicializado para un usuario concreto.

El usuario se le pasa como parámetro al método, y es una instancia de WindowsIdentity. Internamente, la clase TokenHelper convierte este usuario en un conjunto de claims y construye el token con estos claims. Este detalle de implementación obliga a que la app esté alojada con la autenticación Windows habilitada, ya que sin ella la app no podría obtener una instancia de WindowsIdentity. Sin embargo, es posible cambiar la clase TokenHelper para que expida tokens con un ClaimsIdentity (identidad procedente de claims) si usamos ADFS o algún otro proveedor de identidad (STS) compatible con credenciales SAML. Lo veremos en uno de los próximos posts.

Pero, ¿cómo sabe TokenHelper donde está el certificado para firmar? Bueno, se lo tenemos que decir nosotros usando el fichero web.config. Hay que añadir unas entradas adicionales, a parte de las obligatorias para la app (como el ID de la app y su URI), especificando una ruta de certificado y una contraseña para firmar con la clave privada. Además, el application pool de la app tiene que tener permisos suficientes sobre la carpeta donde se halla el certificado.

Resumen

Hemos visto como las apps high-trust simplifican la autorización y autenticación en un entorno on-premise. En el próximo post veremos como configurar un entorno de SharePoint on-premise y haremos una app high-trust desde cero.