Privilèges élevés
Utilisez la stratégie d’application uniquement ou les comptes de service pour élever les privilèges dans les SharePoint ou d’autres solutions hébergées à distance.
S’applique à : apps for SharePoint | SharePoint 2013 | SharePoint Les | SharePoint En ligne
Plusieurs méthodes sont utilisées pour élever les privilèges dans les compléments et solutions de batterie de serveurs SharePoint. Les solutions de batterie de serveurs élèvent les privilèges à l’aide de RunWithElevatedPrivileges(SPSecurity.CodeToRunElevated), qui appartient au modèle objet SharePoint côté serveur. Les compléments SharePoint se servent de la stratégie application uniquement ou comptes de service.
Vous souhaitez peut-être utiliser des privilèges élevés dans votre add-in lorsque :
Votre compl?ment effectue des actions pour les utilisateurs que les utilisateurs n’ont pas les autorisations individuelles adéquates pour effectuer. Les administrateurs peuvent ne pas attribuer certaines autorisations aux utilisateurs, car le niveau d’autorisation est trop élevé.
Votre organisation peut, par exemple, implémenter une solution de mise en service de collection de sites personnalisée que les utilisateurs doivent utiliser pour créer des collections de sites. Votre organisation peut spécifier que toutes les nouvelles collections de sites doivent être associées à certaines listes, types de contenu ou champs. Si les utilisateurs créent eux-mêmes des collections de sites, ils peuvent ou non se souvenir de créer ces objets dans leur nouvelle collection de sites. Dans ce scénario, les utilisateurs créent des collections de sites à l’aide du module, mais les utilisateurs ne sont pas individuellement autorisés à créer des collections de sites.
Votre add-in n’agit pour le compte d’aucun utilisateur ; par exemple, un processus de gouvernance ou de gestion.
Autorisation de stratégie d’application uniquement
La stratégie d’application uniquement utilise OAuth pour authentifier votre application. Lorsque votre application utilise la stratégie d’application uniquement, SharePoint vérifie uniquement les autorisations du principal de l’application. Voici les autorisations qui ont été accordées au add-in. L’autorisation réussit si le add-in dispose des autorisations suffisantes pour effectuer la tâche, quelles que soient les autorisations associées à l’utilisateur actuel. Lorsque l’autorisation réussit, un jeton d’accès est renvoyé à votre add-in. Votre add-in utilisera ce jeton d’accès pour effectuer les opérations requises par votre code.
Pour plus d’informations, voir types de stratégie d’autorisation d’application SharePoint 2013.
Notes
La stratégie d’application uniquement est disponible uniquement pour les applications hébergées par un fournisseur. SharePoint qui accèdent au site web hôte doivent utiliser la stratégie utilisateur+application.
Les avantages de l’utilisation de la stratégie d’application uniquement dans votre application sont les suivants :
Vous n’avez pas besoin d’accorder une licence utilisateur distincte. Les comptes de service nécessitent une licence utilisateur distincte.
Vous obtenez un contrôle plus granulaire des autorisations que celui disponible avec les comptes de service. Par exemple, vous pouvez appliquer des autorisations FullControl sur votre site web, ce qui n’est pas possible lorsque vous utilisez des comptes de service.
Vous ne pouvez pas utiliser la stratégie d’application uniquement avec les API suivantes :
Profil utilisateur
Rechercher
Taxonomie (s’applique uniquement aux scénarios qui écrivent dans le service de métadonnées gérées)
Pour utiliser la stratégie d’application uniquement, vous devez d’abord accorder des autorisations au module à l’aide d’appinv.aspx. Le code suivant de AppManifest.xml indique comment définir la stratégie d’application uniquement et les autorisations pour votre application.
<AppPermissionRequests AllowAppOnlyPolicy="true">
<AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web" Right="FullControl" />
</AppPermissionRequests>
L’utilisation de la stratégie d’application uniquement nécessite que votre application utilise l’autorisation à faible niveau de confiance ou à haut niveau de confiance. La stratégie n’est pas disponible avec la bibliothèque JavaScript SharePoint domaine, qui est un troisième moyen d’obtenir un accès autorisé à SharePoint ressources.
Conseil
Pour autoriser l’utilisation de l’accès application uniquement pour l’écriture dans le magasin de termes de taxonomie, vous devez explicitement ajouter l’identité en tant qu’administrateur de magasin de termes dans l’interface utilisateur d’administration du magasin de termes de app@sharepoint taxonomie. Cela accorde les autorisations nécessaires à l’identité d’application uniquement pour les opérations d’écriture. Vous n’avez pas besoin d’effectuer cette étape pour les opérations de lecture.
Autorisation à faible niveau de confiance
Votre add-in peut utiliser l’autorisation à faible niveau de confiance lorsque vous utilisez le service de contrôle d’accès Microsoft Azure (ACS) pour établir une relation d’approbation entre votre add-in hébergé par un fournisseur et votre site Office 365 ou votre batterie de serveurs SharePoint sur site. Pour plus d’informations, voir Trois systèmes d’autorisation pour SharePoint 2013.
Important
Azure Access Control (ACS), a service of Azure Active Directory (Azure AD), will be retired on November 7, 2018. This retirement does not impact the SharePoint Add-in model, which uses the https://accounts.accesscontrol.windows.net hostname (which is not impacted by this retirement). For more information, see Impact of Azure Access Control retirement for SharePoint Add-ins.
Pour obtenir une référence à l’objet ClientContext, votre add-in doit :
Obtenez le jeton d’accès à l’aide de TokenHelper.GetAppOnlyAccessToken.
Utilisez TokenHelper.GetClientContextWithAccessToken pour obtenir l’objet ClientContext.
Notes
Le fichier TokenHelper est un code source généré par les Outils de développement Microsoft Office pour Visual Studio. Il n’existe aucune documentation de référence, mais il existe des commentaires complets dans la classe TokenHelper. Pour voir les commentaires de code, créez un add-in hébergé par un fournisseur dans Visual Studio.
Notes
Le code fourni dans cet article est fourni tel quel, sans garantie, qu’elle soit express ou implicite, y compris les garanties implicites d’aptitude à un usage particulier, de qualité marchande ou de non-contrefaçon.
Uri siteUrl = new Uri(ConfigurationManager.AppSettings["MySiteUrl"]);
try
{
// Connect to a site using an 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 on the ClientContext object, which uses the app-only token.
}
}
catch (Exception ex)
{
Console.WriteLine("Error in execution: " + ex.Message);
}
Autorisation à haut niveau de confiance
Si votre add-in utilise le système d’autorisation à haut niveau de confiance (également appelé protocole S2S), il appelle une autre méthode TokenHelper : TokenHelper.GetS2SAccessTokenWithWindowsIdentity.
Important : TokenHelper.GetS2SAccessTokenWithWindowsIdentity est utilisé pour les appels d’application uniquement et utilisateur+application. Le deuxième paramètre de la méthode, qui contient l’identité de l’utilisateur, détermine la stratégie utilisée. Passez la valeur Null pour utiliser la stratégie d’application uniquement.
Comptes de service
Utilisez les comptes de service pour élever les privilèges de votre application uniquement lorsque la stratégie d’application uniquement ne fournit pas les autorisations suffisantes pour effectuer votre tâche. En outre, dans certains scénarios, un compte d’utilisateur est requis. Par exemple, vous devez utiliser des comptes de service lorsque votre code fonctionne avec l’une des applications de service SharePoint suivantes :
Service de profil utilisateur utilisant le modèle objet côté client (CSOM)
Service de métadonnées gérées
Recherche
Lorsque vous envisagez d’utiliser des comptes de service dans votre add-in, prenons en compte les considérations suivantes :
Les comptes de service nécessitent une licence utilisateur distincte.
Créez un compte de service par add-in ou utilisez un compte de service pour tous les SharePoint votre environnement.
Vous devez fournir le nom d’utilisateur et le mot de passe pendant l’autorisation. Assurez-vous que les informations d’identification du compte de service sont stockées ou récupérées en toute sécurité.
Pour que votre module puisse effectuer une action sur un site, les comptes de service doivent d’abord être autorisés à accéder au site.
Notes
Les add-ins achetés dans le Office store ne peuvent pas utiliser de comptes de service.
Le code suivant montre comment s’authentifier à l’aide de SharePointOnlineCredentials avec un compte de service.
using (ClientContext context = new ClientContext("https://contoso.sharepoint.com"))
{
// Use default authentication mode.
context.AuthenticationMode = ClientAuthenticationMode.Default;
// Specify the credentials for the service account.
context.Credentials = new SharePointOnlineCredentials("User Name", "Password");
}
Voir aussi
- Développement Office 365 et recommandations de solutions de modèles et pratiques.
- Types de stratégie d’autorisation des SharePoint 2013.
- Utilisez un site Office 365 SharePoint pour autoriser les add-ins hébergéspar un fournisseur sur un site SharePoint local.