Paramètres WICBox avec la fonctionnalité OAuth2
Cher client WIC,
Microsoft a décidé de désactiver définitivement l'authentification de base et d'exiger que toutes les applications et tous les utilisateurs utilisent la méthode sécurisée OAuth2.0 pour s'authentifier sur les serveurs de messagerie. Ceci tant pour la lecture que pour l'envoi de courriers électroniques.
Initialement, la lecture des courriers électroniques via l'authentification de base est inactivée. Pour migrer l'envoi de courriers électroniques vers la nouvelle intégration OAuth2.0, on disposera d’une période de transition de trois mois.
Pour l'envoi de courriers électroniques, la future version de WIC (v4.9.9) sera publiée afin de résoudre le problème dans WIC. Cette version sera officiellement lancée dans le courant du mois d'octobre.
Pour la lecture des courriers, la période de transition est plus courte et nous sommes censés commencer à organiser la transition immédiatement. Nous avons déjà reçu de nombreux messages contradictoires à ce sujet, mais nous supposons actuellement que le fonctionnement sera directement interrompu à partir du 01/10/2022. Cela a un impact important sur le fonctionnement de WICBOX. En tant qu'utilisateur de WICBOX et également de la suite Office365 de Microsoft, vous devez passer à l'authentification OAuth2.0. sur WICBOX.
Pour guider cette transition, nous avons préparé ce document afin de faciliter autant que possible les étapes de ce processus de conversion. L'étape 5 en particulier est une étape importante pour que vous, en tant que client, puissiez travailler.
Étape 1 : version minimale de WIC 4.9.6
Comme nous ne voulons pas vous transférer une toute nouvelle version sans plus, nous avons choisi de rester rétrocompatible avec certaines versions précédentes de WIC. Nous vous demandons donc d’effectuer au moins une mise à niveau de WIC à la version 4.9.6 (la version 4.9.6.20 est la dernière version spécifique de cette série).
Pour votre information, la version qui peut actuellement être déployée est notre nouvelle version 4.9.8.
Étape 2 : configuration : WicGlobal.config
Par ailleurs, nos applications WIC utilisent un fichier de configuration global dans lequel nous avons dû ajouter une nouvelle clé de configuration pour cette conversion. Celle-ci n'est pas disponible dans WICMan parce que nous ne souhaitons pas qu’elle puisse être manipulée sans plus. C'est à KPD qu’il incombe de réaliser cette configuration. Il s'agit d'une configuration permettant de spécifier le nombre de courriers électroniques qui pourront être traités par cycle d’exécution. Cela vise à éviter que, pour les boîtes aux lettres volumineuses, le traitement ne soit plus long que ne le permet la nouvelle authentification. La valeur maximale est de 1 000. L'estimation qui est faite correspond au nombre de courriers électroniques arrivant toutes les 5 minutes dans la boîte aux lettres globale de WICBOX. Par défaut, nous allons fixer cette valeur à 100. Si le client estime que cela est insuffisant, il peut contacter notre service d'assistance, plus précisément l'équipe WIC.
Étape 3 : nouveaux paramètres WIC
Selon la version qui est ou sera installée, un certain nombre de paramètres doivent être configurés dans WICMan. Si ces paramètres n'existent pas encore, KPD veillera à ce qu'ils soient fournis.
- WICBOX_MAILCLIENT_SCOPE
- WICBOX_MAILCLIENT_CLIENTID
- WICBOX_MAILCLIENT_CLIENTSECRET
- WICBOX_MAILCLIENT_TENANTID
- WICBOX_MAILCLIENT_USERNAME
- WICBOX_MAILCLIENT_PASSWORD
- Conversion ACCOUNTMODE -> WICBOXACCOUNTMODE
- Méthode WICBOX
(Scripts nº : 40201575.sql / 40201577.sql / 40201578.sql)
Étape 4 : WICBOX = Tâche planifiée
WICBOX est une application qui est déclenchée à partir d'une tâche planifiée. Cette tâche doit être arrêtée avant que la nouvelle WICBOX ne puisse être installée. Si KPD dispose de droits suffisants, cette étape sera également effectuée par nos soins lors du processus de mise à jour.
Étape 5 : configuration de l'environnement Azure
Le service Azure pour Office365 doit être adapté. Il faut créer une application « WICBox » dans laquelle il faut saisir le ClientId et le TenantId.
- Allez à votre « page d'accueil Azure »
- Cliquez sur « Azure Active Directory »
- Cliquez sur « + Add » (Ajouter) => « App registration » (Enregistrement de l’application) (voir Capture d’écran 1)
- Choisissez un nom (WICBox), le reste peut rester tel quel (voir Capture d’écran nº 2)
- Cliquez sur « Register » (Enregistrer)
- Dans l'écran d'aperçu de cette nouvelle application, vous pouvez trouver le Client Id (identique à l'Application Id) et le Tenant Id (identique au Directory Id).
- Un client secret n'est pas nécessaire, à moins que l’on ne souhaite travailler via les « Application permissions » (Autorisations de l’application) plutôt que via les « Delegated permissions » (Autorisations déléguées). Voir tout en bas pour connaître la différence entre les deux.
Capture d'écran nº 1
Capture d'écran nº 2
- Dans Azure, le paramètre « Authentification/Allow public client flows » (Authentification/Autoriser les flux de clients publics) doit être activé pour cette application. Pour ce faire, cliquez sur « Authentification » à gauche dans l'écran d'aperçu de l'application (voir Capture d'écran nº 3)
Capture d'écran nº 3
- Dans Azure, sous « API permissions » (autorisations API), cette application doit obtenir l’autorisation « Microsoft Graph » « Mail.ReadWrite » de type « Delegated » (ou « Application », voir tout en bas pour connaître la différence), qui doit être approuvée par l'administrateur via « Grant admin consent ». Pour ce faire, cliquez sur « API Permissions » à gauche et cliquez sur « + Add permission » (voir Capture d’écran nº 4. Note : cette capture d'écran affiche beaucoup plus d’autorisations que celles requises pour WICBox)
Capture d'écran nº 4
Étape 6 : nouveau paramètre – à remplir
Paramètre |
Valeur |
Option alternative : Autorisations de l'application |
WICBOX_MAILCLIENT_SCOPE |
Mail.ReadWrite |
|
WICBOX_MAILCLIENT_CLIENTID |
ClientID d'Azure |
vide |
WICBOX_MAILCLIENT_CLIENTSECRET |
vide |
ClientSecret d'Azure |
WICBOX_MAILCLIENT_TENANTID |
TenantID d'Azure |
|
WICBOX_MAILCLIENT_USERNAME |
Identique à WICBOXUsername |
|
WICBOX_MAILCLIENT_PASSWORD |
Identique à WICBOXPassword |
vide |
Méthode WICBOX |
OAuth2 |
|
Option alternative – Autorisations de l'application au lieu d’autorisations déléguées
On peut également choisir de travailler via les « Application Permissions » plutôt que via les « Delegated Permissions ».
Pour cela, un « Client Secret » doit être ajouté à l'application dans Azure. Cette valeur doit alors être saisie dans le paramètre WICBOX_MAILCLIENT_CLIENTSECRET (le paramètre WICBOX_MAILCLIENT_PASSWORD peut dès lors être laissé vide puisqu’il n'est pas utilisé). Dans Azure, cette application doit ensuite recevoir l'autorisation « Microsoft Graph » « Mail.ReadWrite » de type « Application » sous « API permissions», laquelle devra être approuvée par l'administrateur via « Grant admin consent ».
La principale différence entre les deux peut être résumée comme suit :
Delegated Permissions : l'application demande une authentification via son ClientId et le nom d'utilisateur/mot de passe d'une boîte aux lettres et a seulement l'autorisation de lire les courriers électroniques de sa propre boîte aux lettres. L'application ne peut normalement pas accéder à d'autres boîtes aux lettres (cela peut éventuellement être configuré par l'administrateur, mais cela ne relève pas de notre compétence). Si WICBOXMETHOD est configuré sur « MULTIPLE », l'authentification/autorisation devra à nouveau être effectuée via le nom d'utilisateur/mot de passe du projet lui-même (et donc pas via les WICBOX_MAILCLIENT_USERNAME et WICBOX_MAILCLIENT_PASSWORD ).
Application Permissions : l'application demande une authentification via son ClientId et son ClientSecret, puis demande l'accès à une ou plusieurs boîtes aux lettres. Dans le cas de « SINGLE », il s’agit de la boîte aux lettres de l'utilisateur dans le paramètre WICBOX_MAILCLIENT_USERNAME. Toutefois, selon moi, l'application peut alors accéder par défaut à TOUTES les boîtes aux lettres de ce TenantId, à moins que cela ne soit explicitement interdit par une politique, qui peut être définie par l'administrateur (mais cela ne relève pas de notre compétence). Si WICBOXMETHOD est configuré sur « MULTIPLE », l'authentification/autorisation ne sera faite qu'une seule fois pour l'application elle-même, mais une autre boîte aux lettres (celle du projet lui-même, et donc pas celle qui figure dans WICBOX_MAILCLIENT_USERNAME) sera également demandée chaque fois pour lire les courriers électroniques.
Pour information, si WICBOXMETHOD est configuré sur « MIX », l'application appliquera d'abord le code de « SINGLE » et ensuite celui de « MULTIPLE », mais avec une liste de projets légèrement modifiée (condition WHERE différente) par rapport à l’option unique de « SINGLE » ou « MULTIPLE ».
Pour WICBox, il n'y a aucune différence fonctionnelle entre « Application Permissions » et « Delegated Permissions ». C'est purement une question de configuration d'Azure et de WICBox. À mon avis, l’option « Delegated permissions » pourrait être le choix le plus simple si l’on travaille en « SINGLE », tandis que l’option « Application Permissions » pourrait être préférable si l’on travaille en « MULTIPLE ».
