Application uniquement et privilèges élevés dans le modèle de complément SharePoint

  • Article

L’approche que vous adoptez pour élever des privilèges dans votre code est différente dans le nouveau modèle de complément SharePoint et avec un code de confiance totale. Dans un scénario de code de confiance totale/solution de batterie de serveurs classique, l’API RunWithElevatedPrivileges est utilisée avec le code du modèle d’objet côté serveur SharePoint et déployée via des solutions de batterie de serveurs.

Dans un scénario de modèle de compléments SharePoint, l’autorisation AllowAppOnlyPolicy ou un compte de service est utilisé pour autoriser l’utilisateur actif à exécuter des opérations qu’il n’est pas autorisé à effectuer.

Conseils importants

En règle générale, nous donnons les conseils généraux suivants pour l’élévation de privilèges dans le code.

  • AllowAppOnlyPolicy ne fonctionne pas pour :

    • la recherche : si la cible est SharePoint en local. La prise en charge SharePoint Online pour la recherche a été ajoutée (billet de blog) ;

    • les opérations CSOM de profil utilisateur, sauf que l’API de mise à jour en bloc du profil utilisateur peut être utilisée avec les autorisations avec application uniquement ;

    • la mise à jour des entrées de service de taxonomie (écriture) : la lecture fonctionne.

      Remarque

      Dans ces scénarios, vous devez utiliser un compte de service spécifique.

  • AllowAppOnlyPolicy est semblable à RunWithElevatedPrivileges, à quelques différences près.

    • AllowAppOnlyPolicy exécute du code en fonction des autorisations accordées au complément SharePoint, pas au nom d’un autre utilisateur disposant des autorisations appropriées pour effectuer une opération.

Voici un exemple pour renvoyer un jeton de stratégie d’application uniquement et l’utiliser pour créer un objet de contexte.

Uri siteUrl = new Uri(ConfigurationManager.AppSettings["MySiteUrl"]);
try
  {
    //Connect to the give site using App Only token
    string realm = TokenHelper.GetRealmFromTargetUrl(siteUrl);
    var token = TokenHelper.GetAppOnlyAccessToken(TokenHelper.SharePointPrincipal, siteUrl.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(siteUrl.ToString(), token))
    {
      // Perform operations using the app only token access.
    }
  }
  catch (Exception ex)
  {
    Console.WriteLine("Error in execution: " + ex.Message);
  }

  • Lorsque vous utilisez l’autorisation AllowAppOnlyPolicy, n’oubliez pas qu’elle fonctionne uniquement dans des compléments SharePoint hébergés par le fournisseur.

  • AllowAppOnlyPolicy n’exécute pas du code au nom d’un utilisateur et, par conséquent, n’est peut-être pas appropriée pour tous les scénarios.

  • Les comptes de service sont définis dans SharePoint.

    • Dans une location Office 365, selon les fonctionnalités dont dispose votre configuration de code, les comptes de service peuvent nécessiter qu’une licence Office 365 leur soit affectée.

    • Vous pouvez créer des comptes de service en fonction d’un complément SharePoint ou utiliser un seul compte pour tous les compléments SharePoint.

    • Créez des noms clairs et descriptifs pour les comptes de service de façon à pouvoir identifier facilement les opérations qu’ils exécutent.

      Par exemple : si votre complément SharePoint modifie les éléments de liste, la colonne Modifié par relative aux éléments de liste affiche le nom du compte de service associé au complément SharePoint.

  • Lors de l’authentification avec des comptes de service, vous devez récupérer un nom d’utilisateur et un mot de passe pour le compte de service.

    • L’extrait de code ci-dessous illustre l’utilisation d’un nom d’utilisateur et d’un mot de passe pour s’authentifier.

    • Veillez à bien enregistrer et récupérer le nom d’utilisateur et le mot de passe de manière sécurisée.

      using (ClientContext context = new ClientContext("https://tenancy.sharepoint.com"))
{

  // Use default authentication mode
  context.AuthenticationMode = ClientAuthenticationMode.Default;
  // Specify the credentials for the account that will execute the request
  context.Credentials = new SharePointOnlineCredentials("User Name", "Password");
}

Options pour élever le niveau des autorisations

Vous disposez de deux options pour élever le niveau des autorisations.

  • OAuth (AllowAppOnlyPolicy)
    • S2S (sous-option)
    • ACS (sous-option)
  • Compte de service
    • Code hébergé à distance (exemple : Azure WebJob)

Importante

L’utilisation d’Azure ACS (Access Control Services) pour SharePoint Online a été mise hors service depuis le 27 novembre 2023, consultez l’annonce de mise hors service complète pour en savoir plus. L’utilisation d’Azure ACS en dehors du contexte de SharePoint a déjà été mise hors service le 7 novembre 2018 et est maintenant en fin de vie.

La mise hors service signifie que la fonctionnalité ne recevra aucun nouvel investissement, mais qu’elle est toujours prise en charge. La fin de vie signifie que la fonctionnalité sera abandonnée et qu’elle n’est plus disponible.

OAuth (AllowAppOnlyPolicy)

Dans cette option, l’autorisation AllowAppOnlyPolicy est définie sur True dans l’élément AppPermissionRequests et les autorisations sont définies dans le manifeste du complément SharePoint. OAuth sert à renvoyer les jetons d’accès pour autoriser le complément SharePoint à exécuter des opérations pour lesquelles il dispose d’autorisations.

Sous-option S2S

La sous-option S2S fonctionne uniquement dans des environnements SharePoint en local.

Lors de l’authentification via OAuth dans un scénario S2S, la méthode TokenHelper::GetS2SAccessTokenWithWindowsIdentity sert à renvoyer le jeton d’accès pour le complément SharePoint. Le jeton d’accès permet au complément SharePoint d’effectuer les opérations pour lesquelles ce dernier dispose d’autorisations dans le manifeste du complément SharePoint.

Cette option n’exécute pas du code au nom d’un utilisateur et, par conséquent, n’est peut-être pas appropriée pour tous les scénarios.

Quand est-elle adaptée ?

Lorsque vous devez élever le niveau des privilèges dans un scénario S2S SharePoint, il s’agit d’une bonne option, car elle fonctionne avec S2S et est très facile à implémenter.

Prise en main

L’article suivant explique comment utiliser AllowAppOnlyPolicy avec S2S.

Sous-option ACS

La sous-option ACS fonctionne en local et dans les environnements Office 365 SharePoint.

Lors de l’authentification via OAuth dans un scénario ACS, la méthode TokenHelper::GetAppOnlyAccessTokenmethod sert à renvoyer le jeton d’accès pour le complément SharePoint. Ensuite, la méthode TokenHelper::GetClientContextWithAccessToken est appelée pour renvoyer le contexte client nécessaire afin d’effectuer les opérations que le complément SharePoint est autorisé à faire en fonction des autorisations accordées dans le manifeste du complément SharePoint.

Cette option n’exécute pas du code au nom d’un utilisateur et, par conséquent, n’est peut-être pas appropriée pour tous les scénarios.

Quand est-elle adaptée ?

Lorsque vous devez élever le niveau des privilèges dans un scénario ACS SharePoint, il s’agit d’une bonne option, car elle fonctionne avec ACS et est très facile à implémenter. Cette option est une bonne solution lorsque vous avez un environnement SharePoint en local qui possède une approbation établie avec ACS. C’est la seule option OAuth disponible quand vous avez un environnement Office 365 SharePoint.

Prise en main

L’article suivant explique comment utiliser AllowAppOnlyPolicy avec ACS.

Importante

Le contrôle d’accès Azure (ACS), un service d’Azure Active Directory (Azure AD), ne sera plus disponible à partir du 7 novembre 2018. Ce retrait n?a aucune incidence sur le mod?le de compl?ments SharePoint, qui utilise lehttps://accounts.accesscontrol.windows.net nom d?h?te (qui n?est pas affect? par ce retrait). Pour plus d’informations, voir Conséquences du retrait du contrôle d’accès Azure pour les compléments SharePoint.

Compte de service

Dans ce modèle, la classe SharePointOnlineCredentials sert à établir le contexte d’un utilisateur qui exécute le code.

Quand est-elle adaptée ?

Lorsque vous avez besoin d’exécuter du code au nom d’un utilisateur spécifique (compte de service), il s’agit d’une bonne option, car elle effectue des actions sur les autorisations de l’utilisateur (compte de service) et du complément SharePoint.

Prise en main

L’article suivant montre comment la classe SharePointOnlineCredentials est utilisée pour établir le contexte d’un utilisateur qui exécute le code.

S’applique à

  • Office 365 multi-locataire (MT).
  • Office 365 dédiés (D) partiellement
  • SharePoint 2013 en local : partiellement

Les modèles pour les versions dédiées et en local sont identiques au complément SharePoint technique du modèle, mais il existe des différences sur les technologies qui peuvent être utilisées.