Table of contents
TOC
Réduire la table des matières
Développer la table des matières
Dernière mise à jour: 20/06/2018

Création d'applications de service et de démon sous Office 365

S'applique à : Office 365

Les applications de serveur Web et de périphérique nécessitent généralement qu'un utilisateur se connecte, autorise l'application à accéder à ses informations dans Office 365 et à les utiliser. Le protocole sous-jacent qui permet d'obtenir l'accès s'appuie sur le flux d'octroi du code d'autorisation OAuth2. Dans l'une des étapes exécutées lors de l'emission du flux OAuth2, l'application obtient une paire de jetons d'accès/d'actualisation représentant une délégation que l'utilisateur individuel accorde à l'application qui reçoit ainsi un ensemble d'autorisations. Avant que l'application puisse accéder aux données d'un utilisateur, elle doit obtenir un jeton d'actualisation/d'accès pour chaque utilisateur. Afin d'y parvenir, l'utilisateur doit se connecter à l'application au moins une fois.

Cette opération n'est pas possible pour les applications exécutées en arrière-plan, notamment l'application de démon et l'application de service. Ces applications nécessitent un accès sans connexion préalable de l'utilisateur. OAuth2 fournit le flux d'octroi des informations d'identification client pour ces types d'applications et Office 365 prend en charge l'utilisation de ce flux.

Lors de l'utilisation de ce flux, l'application présente ses informations d'identification client au point de terminaison d'émission de jetons OAuth2 et obtient en retour un jeton d'accès qui représente l'application elle-même sans qu'aucune information utilisateur ne soit nécessaire. Dans un tel cas, le jeton utilisé est appelé jeton d'accès d'application.

Il n'est pas nécessaire que l'application obtienne un jeton d'actualisation, car lorsque le jeton d'accès expire, il retourne simplement au point d'extrémité d'émission de jeton OAuth2 qui en émet un nouveau. En outre, comme le jeton de l'application ne comporte pas d'informations utilisateur, l'application doit spécifier l'utilisateur pendant l'appel de l'API et lorsqu'elle utilise ce jeton.

Définition des autorisations

Pour configurer votre application de manière à ce qu'elle puisse accepter les jetons de l'application uniquement, vous devez au préalable spécifier les autorisations dont votre application a besoin. Ces autorisations doivent etre spécifiées pendant l'inscription d'application dans le portail de gestion Azure de Microsoft Azure Active Directory (Azure AD). Sélectionnez le type d'autorisations d'application, car elles sont directement affectées à l'application. Voir la figure 1 présentant la capture d'écran de la section des autorisations d'inscription de l'application Azure AD.

Figure 1. Configuration des autorisations d'application dans Azure ADLa capture d'écran montre les autorisations de l'application dans la console de gestion Azure.

Remarque Lorsque vous enregistrez l'application dans Azure AD, vous devez sélectionner la catégorieApplication Web et/ou API Web, car les autorisations d'applications uniquement ne sont pas disponibles pour les applications client natives.

Une fois les autorisations spécifiées pendant l'inscription d'application, l'application peut demander que le consentement soit disponible dans une autre organisation Office 365. Les autorisations d'application doivent être approuvées par un administrateur client Office 365. En effet, ces applications sont assez puissantes pour accéder aux données dans une organisation Office 365. Par exemple, une application de service avec l'autorisation Mail.Read qui acquiert des jetons d'accès via le flux d'informations d'identification client peut lire le courrier dans n'importe quelle boîte aux lettres dans une organisation Office 365.

En raison de l'accès étendu à ces applications, les applications doivent également utiliser un certificat X.509 comportant une paire de clés publique/privée pour obtenir un jeton d'accès. L'utilisation de clés symétriques simples n'est pas autorisée. Bien que l'application soit capable d'obtenir un jeton d'accès à l'aide d'une clé symétrique, l'API renverra un message d'erreur accès refusé pour ces jetons d'accès. Les certificats X.509 auto-émis sont acceptés, mais l'application doit enregistrer le certificat public X.509 avec la définition de l'application dans Azure AD. L'application conserve ensuite la clé privée et l'utilise pour se faire authentifier auprès du point de terminaison d'émission de jeton.

Vous implémentez le flux de consentement de la même manière que le flux d'octroi de code d'autorisation en envoyant une requête au point de terminaison d'autorisation OAuth2. Cependant, une fois que le point de terminaison d'autorisation a été redirigé vers l'application avec un code d'autorisation, le code restant peut être ignoré. Pour obtenir des jetons, seules les informations d'identification du client sont nécessaires. Vous pouvez créer une expérience telle que « Inscrire mon organisation » dans votre application pour obtenir le consentement initial unique. Ce qu'il faut retenir ici est que vous devez fournir un consentement unique lors de la configuration de l'application de démon ou de service. Une fois le consentement donné, l'application pourra obtenir des jetons d'accès et commencer à appeler les API Office 365.

Vous pouvez révoquer le consentement accordée aux applications de service comme toutes les autres applications installées par un administrateur client Office 365. L'administrateur a le choix entre se rendre sur le portail de gestion Azure pour rechercher l'application dans la vue Application, la sélectionner et la supprimer, ou bien utiliser la commandeRemove-MSOLServicePrincipal cmdlet à partir du module Azure AD pour Windows PowerShell.

Acquisition d'un jeton d'accès avec le flux d'informations d'identification du client

Lorsque vous demandez des jetons d'application uniquement, vous devez utiliser un point de terminaison d'émission de jeton spécifique au client. Si vous utilisez le point de terminaison commun (indépendant du client), une erreur est renvoyée.

Pendant le processus de consentement, lorsque le point de terminaison d'autorisation est atteint et qu'un code est envoyé par redirection vers l'application, votre application peut demander un jeton d'identification avec le code. Ce jeton qui est de type JSON comprend l'ID de client sous forme de revendication tid, vous n'aurez juste qu'à l'analyser pour obtenir l'ID du point de terminaison spécifique au client.

Ce qui suit est une méthode qui permet de déclencher le consentement au moyen d'une requête du flux hybride OpenID Connect:

GET https://login.microsoftonline.com/common/oauth2/authorize?state=e82ea723-7112-472c-94d4-6e66c0ca52b6&response_type=code+id_token&scope=openid&nonce=c328d2df-43d1-4e4d-a884-7cfb492beadc&client_id=0308CDD9-874D-4F87-85E0-A0DA7E05F999&redirect_uri=https:%2f%2flocalhost:44304%2fHome%2f&resource=https:%2f%2fgraph.windows.net%2f&prompt=admin_consent&response_mode=form_post HTTP/1.1

Cette requête fournit le flux de consentement à votre application et redirige le code et le jeton d'identification dans une requête POST. Votre application peut ignorer le code et obtenir le jeton d'identification à partir des données de formulaire reçues. Pour plus d'informations sur le mode de réponse post-formulaire, voir Spécifications d'OpenID.

Sous ASP.Net, vous pouvez récupérer le jeton d'identification via Request.Form ["id_token"] sur la page de redirection, en recherchant l'ID de client dans la revendication tid sous id_token.

Obtention du jeton d'application uniquement

L'extrait de code suivant montre comment utiliser la bibliothèque client Azure AD pour obtenir un jeton d'application uniquement via le flux d'informations d'identification client :

//need to address the tenant specific authority/token issuing endpoint
//https://login.microsoftonline.com/<tenant-id>/oauth2/authorize
//retrieved tenantID from ID token for the app during consent flow (authorize flow)
string authority = appConfig.AuthorizationUri.Replace("common", tenantId);
AuthenticationContext authenticationContext = new AuthenticationContext(authority,false);
string certfile = Server.MapPath(appConfig.ClientCertificatePfx);
X509Certificate2 cert = new X509Certificate(certfile,appConfig.ClientCertificatePfxPassword, X509KeyStorageFlags.MachineKeySet);
ClientAssertionCertificate cac = new ClientAssertionCertificate(appConfig.ClientId, cert);
var authenticationResult = await authenticationContext.AcquireTokenAsync(resource, cac);
return authenticationResult.AccessToken;

Dans cet exemple, l'application maintient la clé privée dans un répertoire bien protégé sur le serveur Web sous forme de fichier PFX. Toutefois, il est préférable de conserver la clé privée dans un stockage plus sécurisé à l'instar de celui dédié aux certificats Windows du compte d'ordinateur. Pour obtenir un exemple complet d'une application Web utilisant le flux d'informations d'identification client, voir l' exemple o365api-as-apponly-webapp.

Configuration d'un certificat public X.509 pour votre application

Cette dernière partie présente comment configurer un certificat public X.509 pour votre application. Comme cela n'est pas exposé dans l'interface utilisateur du portail de gestion Azure, vous devez le configurer en modifiant manuellement le manifeste de l'application. Pour ce faire, vous devez :

  • Créer un certificat auto-émis si vous n'avez pas encore un certificat X.509.

  • Récupérer la valeur du certificat encodé en base64 et l'empreinte numérique d'un fichier de certificat public .cer X509 à l'aide de Windows PowerShell.

  • Télécharger le certificat via le fichier manifeste de l'application. Vous pouvez utiliser l' outil makecert.exe, inclus dans les outils .NET Frameworkpour générer un certificat auto-émis.

Génération d'un certificat auto-émis au moyen de l'outil makecert.exe :

  1. À partir de la ligne de commande, tapez et exécutez

    makecert -r -pe -n "CN=MyCompanyName MyAppName Cert" -b 12/15/2014 -e 12/15/2016 -ss my -len 2048

  2. Ouvrez le composant logiciel enfichable Certificatsde la console de gestion et connectez-vous à votre compte d'utilisateur.

  3. Trouvez le nouveau certificat dans le dossier Personnelet exportez-le vers un fichier CER codé en base64.

    Remarque : assurez-vous que la longueur de la clé soit d'au moins 2048 bits lors de la génération du certificat X.509. Les raccourcis clavier ne sont pas acceptés en tant que clés valides.

Pour obtenir la valeur CERT encodée en base64 et l'empreinte numérique à partir d'un fichier de certificat public .cer X509

  1. Dans l'invite Windows PowerShell, tapez et exécutez les applets de commande suivantes :

    $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
    $cer.Import("mycer.cer")
    $bin = $cer.GetRawCertData()
    $base64Value = [System.Convert]::ToBase64String($bin)
    $bin = $cer.GetCertHash()
    $base64Thumbprint = [System.Convert]::ToBase64String($bin)
    $keyid = [System.Guid]::NewGuid().ToString()
    

    Remarque : cette étape montre comment utiliser Windows PowerShell pour obtenir les propriétés d'un certificat x.509. D'autres plateformes fournissent des outils similaires permettant de récupérer les propriétés des certificats.

  2. Stockez les valeurs pour $base64Thumbprint, $base64Value et $keyid, car vous en aurez besoin lorsque vous téléchargerez le certificat pour la prochaine série d'étapes.

Téléchargez le certificat via le fichier manifeste de l'application

  1. Connectez-vous auportail de gestion Microsoft Azure.

  2. Cliquez sur Active Directory dans le menu de gauche, puis cliquez sur le répertoire désiré.

  3. Dans le menu supérieur, cliquez sur Applications, puis cliquez sur l'application que vous souhaitez configurer. La page deDémarrage rapideapparaîtra avec l'authentification unique et d'autres informations de configuration.

  4. Cliquez sur Gérer le manifeste dans la barre de commande ensuite sélectionnez Télécharger le manifeste.

  5. Ouvrez le fichier téléchargé pour le modifier et remplacez la propriété vide KeyCredentialspar le fichier JSON suivant :

    "keyCredentials": [
    {
      "customKeyIdentifier": "$base64Thumbprint_from_above",
      "keyId": "$keyid_from_above",
      "type": "AsymmetricX509Cert",
      "usage": "Verify",
      "value":  "$base64Value_from_above"
     }
    ], 
    

    par exemple :

    "keyCredentials": [
     {
       "customKeyIdentifier": "ieF43L8nkyw/PEHjWvj+PkWebXk=",
       "keyId": "2d6d849e-3e9e-46cd-b5ed-0f9e30d078cc",
       "type": "AsymmetricX509Cert",
       "usage": "Verify",
       "value": "MIICWjCCAgSgAwIBA***omitted for brevity***qoD4dmgJqZmXDfFyQ"
     }
    ],
    

    La propriété KeyCredentialsest une collection qui permet de télécharger plusieurs certificats X.509 pour des scénarios de transfert ou de supprimer des certificats pour des scénarios de compromis.

  6. Enregistrez vos modifications et téléchargez le fichier manifeste de l'application mis à jour en cliquant sur Gérer le manifeste dans la barre de commande, puis sélectionnez Télécharger le manifeste, naviguez jusqu'à votre fichier manifeste mis à jour et sélectionnez-le.

© 2018 Microsoft