> Tech > Office 365, Principe de fonctionnement de l’authentification fédérée

Office 365, Principe de fonctionnement de l’authentification fédérée

Tech - Par Renaud ROSSET - Publié le 01 octobre 2012
email

En fonction du service Office 365 que vous voulez utiliser, il y a deux fonctionnements liés à l’authentification fédérée.

Office 365, Principe de fonctionnement de l’authentification fédérée

Si vous souhaitez utiliser le client Web ou Lync

’authentification fonctionne sous le mode  « client actif ». Lorsque l’utilisateur s’authentifie sur son poste de travail en utilisant son compte et mot de passe Active Directory, le Sign-In Assistant se connecte directement au serveur ADFS de l’entreprise. Il lui demande un jeton qui est ensuite stocké sur le poste de travail.

Quand l’utilisateur choisit ensuite de se connecter à Office 365 au moyen d’un explorateur internet ou de lancer son client Lync, le service Office 365 demande au client de lui fournir un jeton car il voit que le domaine est fédéré. Le client, qui a précédemment récupéré un jeton au moyen de Sign-In Assistant, présente le jeton au service d’authentification d’Office 365 qui le vérifie et lui donne accès au service demandé.

Si vous souhaitez vous connecter à Office 365 au moyen d’Outlook, ActiveSync, IMAP ou Entourage

L’authentification est alors appelée « passive ». A la différence de l’expérience du « client actif », ces logiciels ne savent pas exploiter le jeton récupéré par le Sign-In assistant. Nous ne rentrons pas dans les détails techniques de ce non support, mais sachez que cela demande une modification de la couche réseau de l’OS, des clients et de composants dans Office 365. Il était prévu de le faire, mais cela a été reporté sans date connue à ce jour. Prenons le cas d’un utilisateur qui souhaite se connecter à Office 365 au moyen de son Windows Phone, c’est-à-dire, en utilisant ActiveSync. Dans la configuration d’ActiveSync, l’utilisateur a entré son UPN et son mot de passe.

Quand il effectue une connexion à sa boîte aux lettres hébergées à Office 365, son UPN et son mot de passe sont envoyés au service d’authentification d’Office 365. Ce service détermine au moyen de la partie droite de l’UPN, que le domaine utilisé est un domaine fédéré : il a donc besoin d’un jeton provenant de l’entreprise de l’utilisateur. Office 365 va donc demander lui-même ce jeton en se faisant passer pour l’utilisateur, en utilisant son UPN et son mot de passe.

Pour cela, il prend la partir droite de l’UPN, recherche dans sa configuration le domaine fédéré correspondant à cet UPN et y trouve l’URL d’accès au service ADFS de l’entreprise (cette URL a été configurée lors de la déclaration du domaine fédéré). ADFS récupère la requête provenant d’Office 365, valide auprès d’Active Directory que les informations existent et sont correctes, et renvoie un jeton au service d’authentification d’Office 365, qui validera l’accès.

L’utilisateur pourra ainsi accéder à ses informations de messagerie. Si vous utilisez un client Outlook, la première fois que l’utilisateur le lancera, Outlook lui demandera son UPN et mot de passe, qui seront envoyés à Office 365 pour que ce dernier puisse récupérer le jeton à la place d’Outlook, qui ne sait pas le faire ; le principe étant le même que ce que nous avons décrit pour la connexion ActiveSync. Afin d’éviter que l’utilisateur ne doive entrer son UPN/mot de passe à chaque lancement d’Outlook, il est possible de demander à Outlook de le stocker. Le mot de passe ne sera alors redemandé à l’utilisateur que lors du prochain changement de mot de passe dans Active Directory.

Téléchargez cette ressource

Guide des Solutions Cloud & Services Managés Simplifiés

Guide des Solutions Cloud & Services Managés Simplifiés

Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.

Tech - Par Renaud ROSSET - Publié le 01 octobre 2012