Creare applicazioni SharePoint Embedded

  • 6 minuti

Gli sviluppatori possono creare applicazioni che usano le potenti funzionalità di gestione di file e documenti in SharePoint tramite SharePoint Embedded. Questi tipi di applicazioni hanno due componenti distinti.

  • Un componente è responsabile dell'esecuzione di operazioni CRUD su SharePoint Embedded usando le API Microsoft Graph.
  • L'altro componente implementa l'interfaccia per consentire agli utenti di utilizzare e archiviare i documenti archiviati in SharePoint Embedded.

Introduzione a SharePoint Embedded

SharePoint Embedded offre agli sviluppatori un modo più rapido per creare applicazioni incentrate su file e documenti. SharePoint Embedded è basato su SharePoint. Gli sviluppatori possono integrare le stesse potenti funzionalità di file e documenti offerte da SharePoint nelle proprie applicazioni personalizzate.

Un altro modo per esaminare SharePoint Embedded è che l'applicazione personalizzata usa SharePoint per tutte le funzionalità di archiviazione e collaborazione dei documenti. In questo modo, SharePoint Embedded viene usato come "API headless" per il sistema di archiviazione documenti di SharePoint.

I documenti dell'app rimangono nel tenant di Microsoft 365

Quando un consumer installa/registra un'applicazione SharePoint Embedded nel tenant di Microsoft 365, SharePoint Embedded crea un'altra partizione di SharePoint. Questa partizione di archiviazione non ha un'interfaccia utente, ma i documenti nella partizione sono accessibili solo tramite API. Ciò significa che tutti i documenti saranno accessibili all'ISV o all'applicazione dello sviluppatore, ma i documenti risiederanno solo nel tenant di Microsoft 365 del consumer.

Le impostazioni di Microsoft 365 consumer si applicano ai documenti dell'app

Tutti i documenti archiviati nella partizione di SharePoint creata dall'app SharePoint Embedded si trovano nel tenant di Microsoft 365 del consumer e pertanto sono soggetti alle impostazioni del tenant microsoft 365 del consumer.

Informazioni sui diversi tipi di autorizzazioni dell'app e sul flusso On-Behalf-Of

Quando si creano applicazioni per le API REST di accesso come Microsoft Graph e SharePoint Online, attività diverse richiedono tipi di accesso diversi. A tale scopo, OAuth v2.0 è uno standard aperto per l'autorizzazione usata per l'accesso alle API, inclusi Microsoft Graph e SharePoint Online. Fornisce alle applicazioni l'accesso delegato alle risorse protette per conto di un utente. Sono inclusi due tipi di autorizzazioni: App+User (noto anche come Delegato) e App-Only (o Application).

  • Autorizzazioni app+utente (o delegate): questo modello riguarda un modello di autorizzazione a due parti. L'applicazione esegue attività e chiama le API per conto di un utente connesso. L'applicazione ottiene le autorizzazioni delegate dall'utente che vi accede, ereditando i privilegi dell'utente, incluse eventuali restrizioni, ad esempio non essere in grado di accedere a determinati dati o di eseguire determinate azioni. Queste riflettono le attività che l'utente ha consentito all'app di eseguire per conto proprio durante la sessione.

    Ad esempio, a un'app potrebbe essere concessa l'autorizzazione per inviare un messaggio di posta elettronica per conto di un utente, ma se l'utente non dispone dell'autorizzazione per inviare un messaggio di posta elettronica, l'app non sarà in grado di inviarlo.

    Questo tipo di autorizzazione viene spesso usato quando si vuole che l'app funzioni come farebbe l'utente connesso, negli scenari dell'applicazione in cui l'interazione è per conto di un utente e le autorizzazioni devono variare in base all'utente che concede il consenso.

  • Autorizzazioni solo app (o applicazione): le autorizzazioni solo app, al contrario, vengono usate quando un'app deve accedere alle risorse in modo indipendente da un utente. L'applicazione ottiene le autorizzazioni concesse direttamente a se stessa, indipendentemente dalle autorizzazioni utente. Consente all'applicazione di accedere al servizio API con la propria identità e i propri privilegi. Questo è ideale per i servizi in background o i daemon eseguiti indipendentemente da una sessione utente.

Ad esempio, se si dispone di un'applicazione che deve accedere a tutti i file in una raccolta documenti, anche quelli che non sono condivisi con alcun utente, le autorizzazioni solo app sarebbero la scelta giusta.

Le autorizzazioni dell'applicazione possono essere concesse solo da un amministratore perché spesso concedono privilegi più elevati.

Oltre a queste due opzioni, è possibile usare un terzo flusso OAuth 2.0 On-Behalf-Of (noto anche come flusso OBO ) quando un'applicazione deve eseguire un'attività per conto dell'utente. Ecco come funziona l'intero flusso OBO:

  1. Un'applicazione client esegue l'autenticazione nel server di autorizzazione (ad esempio Microsoft Entra ID) e richiede un token di accesso per un'API, ad esempio il server API del progetto.
  2. L'utente accede e consente all'applicazione di agire per suo conto.
  3. L'applicazione client riceve un token di accesso e un token di aggiornamento che rappresenta la sessione dell'utente.
  4. Quando l'applicazione client deve chiamare un altro servizio, ad esempio SharePoint Online, per conto dell'utente, invia il token di accesso ottenuto in precedenza nell'intestazione Authorization HTTP.
  5. L'API sul lato server convalida il token di accesso ed elabora la richiesta. Se deve chiamare un altro servizio (ad esempio SharePoint Online) per conto dell'utente, recupera un token da Microsoft Entra ID presentando questo token già ottenuto.
  6. Microsoft Entra ID rilascia un "nuovo" token di accesso per SharePoint Online che il server API del progetto può ora usare per chiamare SharePoint Online.

In uno scenario pratico che riguarda Microsoft Graph o SharePoint Online, quando un utente vuole che un'app accinga a accedere al calendario, non è ideale avere l'accesso dell'applicazione per ogni singola operazione. Con il flusso OBO, invece, l'utente deve eseguire l'autenticazione una sola volta e l'applicazione eseguirà tutte le operazioni autorizzate per suo conto.

Di conseguenza, il flusso OBO semplifica l'esperienza utente e migliora la sicurezza del sistema assicurando che le autorizzazioni vengano convalidate ogni volta che viene eseguita una catena di chiamate.

Riepilogo

In questa sezione sono stati completati i passaggi iniziali per creare un'applicazione Web che eseguirà operazioni CRUD in un contenitore SharePoint Embedded.