SharePoint 2013: Flujo de autenticación en aplicaciones (I)!

Hace unos meses os comentaba el concepto de autorización en aplicaciones que introduce el nuevo modelo de aplicaciones de SharePoint, hablábamos también sobre los ámbitos y permisos de aplicación por ámbito y en general lo que implica “autorizar” a una aplicación para que actúe en nombre de un usuario. En este post, vamos a ver cuál es el flujo normal de autenticación en aplicaciones teniendo en cuenta:

  • Los opciones de autorización qué se permiten en SharePoint 2013.
  • Los tipos de aplicaciones que podemos tener.
  • Los requerimientos qué se necesitan para poder hacer uso del modelo de autorización (AuthZ) de SharePoint 2013.

Os recuerdo qué SharePoint 2013 permite qué además de los usuarios, se puedan autenticar aplicaciones, es decir, les está dando una ideantidad. El flujo de autenticación es el que se muestra en la siguiente figura (Nota: Lo podéis encontrar en los materiales de los traininig de desarrollo e IT de Microsoft para SharePoint 2013).

image

Y ahora al lio:

  • En primer lugar, vamos a recordar los tipos de aplicaciones que podemos crear:
    • SharePoint-Hosted, es decir, residen y se ejecutan en un sitio de SharePoint aislado.
    • Auto-Hosted, es decir, las aplicaciones residen y se ejecutan en Windows Azure. En este caso, SharePoint Online es un simple punto de acceso a dichas aplicaciones.
    • Provider-Hosted, es decir, las aplicaciones residen y se ejecutan en una infraestructura de nube pública como puede ser Windows Azure, de nube propietaria o bien en un entorno de hosting.
  • ¿Qué opciones de autorización se permiten en SharePoint 2013?
    • Sólo Usuario, es decir, se utiliza autenticación por medio de usuario y contraseña. Esta opción aplica a los tres modelos.
    • Usuario y Aplicación , es decir, se usa OAuth como protocolo de autenticación. Esta opción aplica a aplicaciones Auto-Hosted y Provider-Hosted.
    • Sólo Aplicación, es decir, de nuevo se hace uso de OAuth. Esta opción aplica a aplicaciones Auto-Hosted y Provider-Hosted.
    • Anónimo (sin OAuth), y que aplica a cualquier modelo.
  • ¿Cuáles son los requerimientos para poder establecer una identidad en una aplicación? El requerimiento fundamental es qué la aplicación web “Host” esté configurada con autenticación basada en Claims.

Visto esto, vamos a explicar con más detalle el flujo de autenticación de SharePoint 2013 de la figura diferenciado entre peticiones realizadas por un usuario y peticiones realizadas por una aplicación:

Peticiones de usuario

  • Cuando SharePoint 2013 recibe una petición entrante qué requiere autenticación, lo primero que hace es comprobar si dicha petición contiene un token SAML con la identidad del usuario.
  • Si encuentra dicho token, SharePoint asume que la petición procede de un usuario y no de una aplicación.
  • A continuación, analiza la URL de la petición para determinar si se trata de una URL estándar de un sitio de SharePoint o se trata de una URL de aplicación:
    • En el caso de una URL estándar, el flujo de autenticación y autorización que tiene lugar es el mismo que ya conocíamos para SharePoint 2010.
    • En el caso de una URL de aplicación, SharePoint 2013 inicia el contexto de llamada para la identidad del usuario y para la identidad de la aplicación.´

Peticiones de aplicación

  • En este caso, la petición entrante no contiene un token SAML, por lo que SharePoint 2013 interpreta que no ha sido un usuario quien ha iniciado la petición.
  • A continuación, SharePoint inspecciona la petición para ver si contiene un token de seguridad que identifique a la aplicación. Este token en aplicaciones de tipo Autohosted se crea usando OAuth y usando los elementos que provee Office 365 para su uso (ACS, Azure Control Service). En el caso de una aplicaicón Provider-Hosted, la idea es la misma: se necesita un token OAuth válido y posiblemente hacer configuraciones extra entre servidores (S2S, Sever to Server).
  • En cualquiera de los dos escenarios, SharePoint 2013 usa el token de seguridad para establecer un contexto de llamada al menos para la aplicación (opcionalmente para el usuario).