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).

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

2 comentarios en “SharePoint 2013: Flujo de autenticación en aplicaciones (I)!”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *