Creación de aplicaciones de SharePoint Embedded

  • 6 minutos

Los desarrolladores pueden crear aplicaciones que usen las eficaces funcionalidades de administración de archivos y documentos en SharePoint a través de SharePoint Embedded. Estos tipos de aplicaciones tienen dos componentes distintos.

  • Un componente es responsable de realizar operaciones CRUD en SharePoint Embedded mediante las API de Microsoft Graph.
  • El otro componente implementa la interfaz para que los usuarios consuman y almacenen los documentos almacenados en SharePoint Embedded.

Introducción a SharePoint Embedded

SharePoint Embedded proporciona una manera más rápida para que los desarrolladores creen aplicaciones centradas en archivos y documentos. SharePoint Embedded tiene tecnología de SharePoint. Los desarrolladores pueden integrar las mismas funcionalidades eficaces de archivos y documentos que SharePoint tiene para ofrecer en sus propias aplicaciones personalizadas.

Otra manera de ver SharePoint Embedded es que la aplicación personalizada usa SharePoint para todas las características de almacenamiento de documentos y colaboración. Esto usa eficazmente SharePoint Embedded como una "API sin cabeza" para el sistema de almacenamiento de documentos de SharePoint.

Los documentos de la aplicación permanecen en su inquilino de Microsoft 365

Cuando un consumidor instala o registra una aplicación de SharePoint Embedded en su inquilino de Microsoft 365, SharePoint Embedded crea otra partición de SharePoint. Esta partición de almacenamiento no tiene una interfaz de usuario, pero en su lugar, los documentos de la partición solo son accesibles a través de las API. Esto significa que todos los documentos serán accesibles para el ISV o la aplicación del desarrollador, pero los documentos solo residirán en el inquilino de Microsoft 365 del consumidor.

La configuración de Consumidor de Microsoft 365 se aplica a los documentos de la aplicación

Todos los documentos almacenados en la partición de SharePoint creada por la aplicación de SharePoint Embedded están en el inquilino de Microsoft 365 del consumidor y, por tanto, están sujetos a la configuración del inquilino de Microsoft 365 del consumidor.

Descripción de los distintos tipos de permisos de aplicación y el flujo en nombre de

Al crear aplicaciones para que accedan a las API REST como Microsoft Graph y SharePoint Online, las distintas tareas requieren diferentes tipos de acceso. Para solucionar este problema, OAuth v2.0 es un estándar abierto para la autorización que se usa para el acceso a la API, incluidos Microsoft Graph y SharePoint Online. Proporciona a las aplicaciones acceso delegado a recursos protegidos en nombre de un usuario. Esto incluye dos tipos de permisos: App+User (también conocido como Delegado) y App-Only (o Application).

  • Permisos de aplicación y usuario (o delegado): este modelo se trata de un modelo de permisos de dos partes. La aplicación realiza tareas y llama a las API en nombre de un usuario que ha iniciado sesión. La aplicación obtiene permisos delegados del usuario que inicia sesión en ella, heredando los privilegios que tiene el usuario, incluidas las restricciones como no poder acceder a determinados datos o realizar ciertas acciones. Estos reflejan las tareas que el usuario ha permitido que la aplicación realice en su nombre durante su sesión.

    Por ejemplo, se podría conceder permiso a una aplicación para enviar un correo electrónico en nombre de un usuario, pero si el usuario no tiene permiso para enviar un correo electrónico, la aplicación tampoco podrá enviarlo.

    Este tipo de permiso se usa a menudo cuando quieres que la aplicación funcione como lo haría el usuario que inició sesión, en escenarios de aplicación en los que la interacción es en nombre de un usuario y los permisos deben variar según el usuario que concede el consentimiento.

  • Permisos de solo aplicación (o aplicación): los permisos de solo aplicación, por el contrario, se usan cuando una aplicación necesita acceder a los recursos independientemente de un usuario. La aplicación obtiene los permisos que se conceden directamente a sí misma, independientemente de los permisos de usuario. Permite que la aplicación acceda al servicio de API con su propia identidad y privilegios. Esto es ideal para los servicios en segundo plano o los demonios que se ejecutan independientemente de una sesión de usuario.

Por ejemplo, si tiene una aplicación que necesita acceder a todos los archivos de una biblioteca de documentos, incluso aquellos que no se comparten con ningún usuario, los permisos de solo aplicación serían la opción correcta.

Los permisos de aplicación solo pueden ser consentidos por un administrador porque a menudo conceden privilegios más altos.

Además de estas dos opciones, se puede usar un tercer flujo de OAuth 2.0, On-Behalf-Of (también conocido como flujo OBO ) cuando una aplicación necesita realizar una tarea en nombre del usuario. Este es el funcionamiento de todo el flujo de OBO:

  1. Una aplicación cliente se autentica en el servidor de autorización (como Microsoft Entra ID) y solicita un token de acceso para una API (como el servidor de API de nuestro proyecto).
  2. El usuario inicia sesión y permite que la aplicación actúe en su nombre.
  3. La aplicación cliente recibe un token de acceso y un token de actualización que representa la sesión del usuario.
  4. Cuando la aplicación cliente necesita llamar a otro servicio, como SharePoint Online, en nombre del usuario, envía el token de acceso que obtuvo anteriormente en el Authorization encabezado HTTP.
  5. Nuestra API del lado servidor valida el token de acceso y procesa la solicitud. Si necesita llamar a otro servicio (como SharePoint Online) en nombre del usuario, captura un token de Microsoft Entra ID mediante la presentación de este token ya obtenido.
  6. Microsoft Entra ID emite un token de acceso "nuevo" para SharePoint Online que el servidor de API de nuestro proyecto ahora puede usar para llamar a SharePoint Online.

En un escenario práctico en el que se trabaja con Microsoft Graph o SharePoint Online, cuando un usuario quiere que una aplicación acceda a su calendario, no es ideal que la aplicación inicie sesión para cada operación individual. En su lugar, con el flujo OBO, el usuario solo necesita autenticarse una vez y la aplicación realizará todas las operaciones autorizadas en su nombre.

Por lo tanto, el flujo de OBO simplifica la experiencia del usuario y mejora la seguridad del sistema al garantizar que los permisos se validan cada vez que se realiza una cadena de llamadas.

Resumen

En esta sección, ha completado los pasos iniciales para crear una aplicación web que realizará operaciones CRUD en un contenedor incrustado de SharePoint.