Au cours des derniers mois, Microsoft a progressivement déprécié et désactivé l’authentification basique pour les protocoles Microsoft Exchange Online tels que POP et IMAP, SMTP.
Il est donc urgent de passer à la nouvelle authentification moderne, basée sur OAuth 2.0. A l’heure où sort ce post, vous devez déjà avoir subi des troubles pour permettre à vos applications tiers de collaborer avec les solutions IMAP, POP, SMTP de Microsoft Exchange Online. Cela semble être un changement simple, mais il s’est avéré gênant d’un point de vue de la configuration dans la pratique à certains points.
Tout comme pour Log4Shell, il nous est apparu utile de documenter cette évolution des API d’Authentification de Microsoft et vous faciliter leur mise en œuvre.
Cet article de blog est utile pour tous ceux qui s’occupent de l’accès programmatique aux e-mails en utilisant les API Java javax.mail ou qui utilisent respectivement au sein de leurs flux Talend DI ou ESB les composants tPop, ou cMail pour écouter les e-mails sur IMAP pour les boîtes aux lettres Microsoft Office 365 Exchange Online. Nous présentons l’accès programmatique, les configurations tant du point de vue Azure que de celui de Talend ESB.
 |
REMARQUE : Ce guide couvre le flux Client Credentials Grant, généralement utilisé pour la communication de machine à machine sans interaction avec l’utilisateur. |
ÉTAPE 1 – Enregistrer / configurer l’application dans Azure
L’application Azure gère l’identité et l’interface d’accès aux boîtes mails, auxquelles nous voulons accéder à partir d’applications, ici nous nous intéressons à Java ou Talend en utilisant une authentification moderne avec le flux OAuth2 Client Credentials.
|
REMARQUE : Il s’agit d’un guide pour la mise en place du flux d’octroi d’accréditations client uniquement, qui est généralement utilisé pour la communication de machine à machine, sans interaction avec l’utilisateur. |
Pourquoi ?
Cette configuration vous permet d’obtenir un jeton d’accès en utilisant le flux d’octroi des informations d’identification du client OAuth2 pour votre application enregistrée. Ce jeton d’accès est utilisé comme mot de passe pour la connexion IMAP par la suite. OAuth2 est une norme largement répandue, assez complexe et quelque peu écrasante, avec beaucoup de choses à comprendre dans son intégralité. Cependant, pour ce cas d’utilisation, vous n’avez pas besoin de comprendre les détails. Nous avons simplement besoin du clientId, du clientSecret ou du certificat, et du nom du locataire Azure ou du tenantId.
1. Créer l’application
2. Ajoutez l’autorisation IMAP.AccessAsApp requise.
Depuis Autorisations API, ajoutez l’autorisation IMAP.AccessAsApp. Vous pouvez la trouver sous APIs votre organisation uses > Office 365 Exchange Online.
|
REMARQUE : Cette autorisation nécessite le consentement de l’administrateur. Si vous n’êtes pas l’administrateur, contactez votre administrateur et demandez-lui son accord. Voici à quoi cela devrait ressembler : |
3. Créer le secret du client ou le certificat du client
Pour se connecter à l’enregistrement de cette application via OAuth2, un secret client ou un certificat client (clé publique) est nécessaire.
Pour des raisons de simplicité, nous utilisons ici un secret client.
|
REMARQUE : Faites attention à la date d’expiration du secret du client ! Ou définissez une période personnalisée. Lorsque la clé expire, votre application client ne pourra plus se connecter. |
|
REMARQUE : Copiez et stockez le secret du client juste après sa création dans un endroit sûr, par exemple, un stockage de clés sécurisé. Vous n’y aurez plus accès. |
ÉTAPE 2 – Ajouter les autorisations de la boîte aux lettres à l’aide de la commande PowerShell
C’est la partie la plus compliquée en effet vous devez avoir un administrateur Azure avec vous ou avoir les droits d’administration sur Azure afin d’exécuter les étapes qui suivent. Nous espérons que vous avez les coordonnées de l’administrateur Azure de votre entreprise, au cas où vous ne le seriez pas.
Ensuite, nous allons créer un servicePrincipal et exécuter Add-MailboxPermission pour permettre l’accès à la boîte mail… Ce n’est possible qu’en exécutant “un peu de magie PowerShell”. Pour cela, nous avons besoin d’un Object ID spécial situé à des endroits très différents. Les deux endroits contiennent un Object ID, mais ils sont différents. Cela génère une certaine confusion et par voie de conséquence de la complexité. Il semble que beaucoup n’aient pas compris dès le départ. Nous allons essayer de rendre les choses plus claires.
Nous allons avoir besoin de l’Application (client) ID de la page d’aperçu de l’application, s’il vous plaît IGNOREZ l’Object ID dans cette section. Par contre, récupérez bien l’ENTERPRISE_OBJECT_ID à cet emplacement indiqué ci-dessous :L’ENTERPRISE Object ID peut être trouvé sous Enterprise applications > All applications > Tapez le nom de l’application dans le champ de recherche :
Ne tenez pas compte de l’ID d’objet barré en rouge dans la vue d’ensemble de l’application, mais obtenez plutôt l’ID d’objet d’entreprise, à partir du point d’entrée des applications d’entreprise dans Azure.
C’est parti pour les commandes “magiques” PowerShell :
# Enregistrer le ServicePrincipal de l'application Azure AD dans Exchange :
New-ServicePrincipal -AppId "<APPLICATION_ID>" -ServiceId "<ENTERPRISE_OBJECT_ID>"
# Définir le nom d'affichage du ServicePrincipal nouvellement créé.
Set-ServicePrincipal -Identity "<ENTERPRISE_OBJECT_ID>" -DisplayName "<APP_DISPLAY_NAME>"
# Donnez au ServicePrincipal de l'application l'accès à une boîte mails :
# Add-MailboxPermission -Identity "<EMAIL_ADDRESS>" -User Add-MailboxPermission-Identity "<EMAIL_ADDRESS>" -User "<ENTERPRISE_OBJECT_ID>" -AccessRightsFullAccessVous devrez peut-être d’abord installer certains modules PowerShell pour exécuter ces commandes. La description de Microsoft se trouve ici :
https://www.limilabs.com/blog/oauth2-client-credential-flow-office365-exchange-imap-pop3-smtp
ÉTAPE 3 – L’heure des tests avec Talend ESB !
Pour pouvoir concevoir vos flux d’intégration avec Talend ESB qui dialoguent avec IMAP, POP, SMTP il vous faut des pré-requis :
- Microsoft Authentication Library (MSAL) for Java
- Apache Camel Mail Microsoft Oauth (camel-mail-microsoft-oauth)
- Javax.Mail 1.6.7
|
REMARQUE : Vous aurez aussi besoin de d’autres librairies java dont dépendent celles qui sont listées plus haut. |
|
REMARQUE : Ici, nous avons choisi de réaliser ce test avec Talend ESB 8.0.1 (avec JAva 11) |
Enregistrer le bean « exchangeAuthenticator » avec les différents paramètre attendu par l’authentification OAuth2 de Microsoft Azure pour les mails.
le code généré ressemble à celui-ci pour l’enregistrement du bean :
@BindToRegistry("exchangeAuthenticator")
public MicrosoftExchangeOnlineOAuth2MailAuthenticator exchangeAuthenticator(){
return new MicrosoftExchangeOnlineOAuth2MailAuthenticator(<<tenantId>>, <<clientId>>, <<clientSecret>>, <<emailAddress>>);
}Il vous reste alors à configurer le cMail
from("imaps://outlook.office365.com:993"
+ "?authenticator=#exchangeAuthenticator"
+ "&mail.imaps.auth.mechanisms=XOAUTH2"
+ "&debugMode=true"
+ "&delete=false")Et voilà !
L’intégration de données trouve une certaine complexité dans la manipulation d’un grand nombre de sources de données, et d’API. Ici, nous avons cherché à simplifier l’appropriation de la configuration des API OAuth2 de Microsoft Azure pour Exchange Online.
Synaltic se tient à vos côtés pour vous aider dans la mise en œuvre de vos projets d’intégration de données avec Talend.
|
REMARQUE : vous pouvez aussi avoir besoin de mettre en œuvre l’authentification OAuth2 dans le cadre de vos flux DI avec un composant tPop. Vous trouverez ici toutes les informations utiles :Configurer une application Microsoft Azure pour les protocoles POP et IMAP https://help.talend.com/r/fr-FR/8.0/pop/configuring-an-oauth2-application-for-pop-and-imap |
