Microsoft et sa modern authentication
Si vous réfléchissez à l’utilisation et au passage à Office 365 cet article pourrait vous intéresser ! Effectivement, le passage à Office 365 pose un certain nombre de problématiques dont celle qui nous intéressera ici : l’authentification.
Qu’est-ce que Microsoft entend par modern authentication?
Commençons simplement avec la définition donnée par Microsoft :
La Modern authentication est liée à l’utilisation d’ADAL (Active Directory Authentication Library) pour l’authentification sur les clients Office. ADAL permet l’ouverture à des moyens d’authentification diverses tels que l’authentification multi-facteurs (MFA), l’utilisation d’un fournisseur d’identité basé sur le protocole SAML, l’authentification via smart card ou certificats. De plus, l’utilisation d’ADAL au niveau d’Outlook permet de ne plus utiliser l’authentification basique.
En résumé, la modern authentication de Microsoft est la possibilité d’utiliser des protocoles standards qui ne sont plus “propres” à Microsoft (tel que WS-Federation).
En pratique, qu’est-ce que donne ?
Tout d’abord, il faut savoir que certains prérequis sont essentiels pour l’utilisation d’ADAL. Effectivement, l’utilisation d’ADAL n’est possible qu’avec Office 2013 (release de mars 2015) et les versions suivantes. Ensuite, encore aujourd’hui, pour certains clients comme Skype for Business, il est nécessaire de faire une requête à Microsoft pour qu’il soit activé au niveau du tenant O365 pour que cela puisse être utilisé (Les fonctionnalités autour d’ADAL sont considéré par Microsoft comme étant toujours en preview).
Une nouvelle expérience utilisateur ?
D’un point de vue utilisateur, l’utilisation d’ADAL revient à la présentation de Web View à l’utilisateur dans les phases d’authentification.
De façon simple, lorsque l’on active ADAL, une Web View est utilisée lors de la phase d’authentification pour pouvoir rediriger l’utilisateur (après le remplissage de son login) vers l’authentification configurée au niveau du tenante O365.
Par exemple, dans le cas de l’utilisation d’un fournisseur d’identité SAML, l’utilisateur sera redirigé vers son fournisseur d’identité au sein de la Web View et effectuera son authentification comme habituellement pour accéder à une application Saas ou selon la politique appliquée à Office.
Une fois authentifié, dans le cas de Word par exemple, l’utilisateur a accès à ses documents stockés dans son OneDrive et d’autres contenus liés. L’accès à d’autres services nous montre que Microsoft a implémenté du SSO au niveau de sa suite Office (Attention, il y a des bémols à ce paysage idyllique. Outlook et Skype for business, par exemple, ne profitent pas du SSO implémenté au sein des clients Office. A minima, l’utilisateur sera obligé de remplir à nouveau son login).
Comment se passe le SSO entre les clients Offices et les services Office?
L’article aurait pu s’arrêter sur l’ouverture de Microsoft à d’autres moyens d’authentification via l’utilisation de Web View. Cependant, il est intéressant d’aller un peu plus loin pour voir ce qu’a fait Microsoft pour les interactions entre ses clients lourds et ses services Online.
Oauth, qui a dit Oauth?
Effectivement, Microsoft utilise Oauth pour les interactions entre les clients lourds et les services Online. Pour faire simple, voici en 4 étapes ce qui se passent lors de l’authentification et l’accès aux services Online:
1-L’utilisateur, via Word, souhaite avoir à son OneDrive alors qu’il n’est pas authentifié. Une Web View s’ouvre et redirige l’utilisateur vers le endpoint d’authentification d’Azure AD. (Si nous sommes dans le cas de l’utilisation d’un fournisseur d’identité tierce pour l’authentification (exemple précédent), une fois que l’utilisateur a rempli son login, il est redirigé vers son fournisseur d’identité pour s’authentifier)
2-L’utilisateur effectue son authentification. Une fois cette dernière validée par Azure AD, Azure AD fournit un authorization code à l’application (dans notre cas, Word)
3-Word fait appel à Azure AD pour faire l’échange de l’autorization code contre un access token
4-Word utilise cet access token pour faire des appels aux services Online
Une précision supplémentaire, le client Office (dans notre cas Word) obtient à la fois un access token ayant comme durée de vie 1h et un refresh token ayant comme durée de vie 14 jours pouvant aller jusqu’à 90 jours dans le cas d’une utilisation continue. Après 90 jours, l’utilisateur devra nécessairement ce re-authentifier.
En conclusion, les efforts faits par Microsoft pour permettre une plus grande flexibilité au niveau de l’authentification commencent à aboutir même si Microsoft parle encore de preview.
Quelques liens sur le sujets:
https://msdn.microsoft.com/en-us/office/office365/howto/common-app-authentication-tasks
AuréliConsultant Sécurité
