Jaa

Office 365 – Mise en place de la Federation Identite – Partie 1

  • Artikkeli

La fédération d'identité a pour but de simplifier la gestion des droits d'accès à des ressources entre deux organisations différentes. Chaque entité s'occupe ainsi de ce qui est dans son domaine de responsabilité, par exemple les comptes pour un client les ressources pour un fournisseur de contenu.

Par exemple si l'on considère l'accès à une librairie en ligne, la fédération d'identité permet à la librairie de gérer les accès selon des critères établis à l'avance et laisser l'organisation cliente gérer les comptes des utilisateurs.

Dans le cas de Office 365, la fédération d'identité permet à une entreprise de déporter les ressources (boites aux lettres, sites Sharepoint, …) tout en gardant la main sur la gestion les comptes des utilisateurs et les politiques associées (politique mots de passe, délégation des droits, coexistence avec un existant, …).

On peut donc schématiser la solution comme suit :

Le client s'authentifie avec son compte sur l'Active Driectory de l'entreprise et peut accéder à sa boite aux lettres ou son site Sharepoint hébergé sur Office 365 sans avoir à se ré-authentifier. Cette approche n'utilisant qu'un seul compte est une vraie solution de SSO (Single Sign On).

Nous allons voir quels sont les composants nécessaires pour mettre en place la fédération d'identité puis nous détaillerons pas à pas les étapes à suivre pour la mettre en place et la publier sur Internet dans le cadre d'une maquette pour que les clients puissent se connecter à leur boite aux lettres aussi bien sur le réseau de l'entreprise qu'en situation de mobilité.

 

Composants nécessaires pour mettre en place la fédération d'identité

Si vous avez décidé de mettre en œuvre la fédération d'identité avec Office 365 pour votre organisation les serveurs suivants seront nécessaires :

  • Un serveur Active Directory avec une seule forêt qui doit être au moins au niveau fonctionnel Windows 2003.
  • Un serveur exécutant la synchronisation d'annuaire. La mise en œuvre de ce service a été vu dans le chapitre précédent.
  • Un serveur ADFS v2 (Active Directory Federation Services)
  • Un serveur TMG (Threat Management Gateway) pour la publication du serveur ADFS sur Internet.

Sans que l'on puisse parler réellement de composant, il est nécessaire d'avoir défini un nom de domaine qui sera utilisé pour la fédération et donc partagé entre l'environnement on-premises et Office 365. Ce nom peut être le nom de votre domaine Active Directory actuel mais peut aussi être différent.

Dans l'exemple que nous allons suivre dans ce document nous utilisons un certificat émis par une autorité de certification publique mais il est possible d'utiliser un certificat émis par une autorité de certification interne pour cette étape.

Si vous voulez mettre en œuvre l'ensemble des fonctionnalités de coexistence riche entre une infrastructure on-premises et Office 365, vous devrez commander un certificat public.

Comment ça marche ?

La fédération d'identité utilise un mécanisme à base de Claims qui sont présentés par l'utilisateur lors d'une tentative d'accès à une ressource (dans le cas d'Office 365, par exemple Exchange Online). Ces Claims sont obtenus par l'utilisateur après de son fournisseur d'identité (dans le cas de notre implémentation l'Active Directory de l'entreprise).

Dans le détail, avec Office 365, voici le fonctionnement de la fédération d'identité.

  1. Le client tente de se connecter à une ressource dans Office 365 :

  1. Le service indique au client qu'il a besoin d'un service ticket signé par la Federation Gateway de Office 365 et qu'il doit aller le chercher à cet emplacement.
  2. Le client se connecte donc sur la Federation Gateway pour obtenir son service ticket.
  3. La Federation Gateway indique au client qu'il doit aller chercher un jeton de logon signé par son serveur STS d'entreprise (Security Tocken Service). Dans notre cas, il s'agit du serveur ADFS v2.

  1. Le client demande un jeton de connexion au serveur ADFS d'entreprise.
  2. Le serveur ADFS contact le serveur Active Directory et obtient un ticket NTLM ou Kerberos et le transforme en jeton SAML qu'il signe.

  1. Le client présente ensuite ce jeton à la Federation Gateway.
  2. La Federation Gateway ouvre le jeton reçu et vérifie que la signature a été faite par l'autorité reconnue lors de la mise en place du trust.
  3. L'identifiant source de l'utilisateur connu de Active Directory est alors remplacé par son identifiant NetID unique dans Office 365. Un nouveau jeton est alors généré et délivré au client.

  1. Le client peut alors présenter ce nouveau jeton à la ressource.

  1. La ressource ouvre le jeton, vérifie la signature et recherche dans son annuaire le NetID de l'utilisateur.
  2. Une fois ces informations trouvées, les droits accès seront appliqués.

Le NetID de l'utilisateur est créé lors de la création des utilisateurs au moment de la synchronisation des annuaires.

La mise en place de la synchronisation d'annuaire est donc bien un pré-requis à la fédération d'identité avec Office 365.

Pour mettre cela en place d'un point de vue concret, nous allons suivre les étapes suivantes :

  1. Installation et configuration on-premises de ADFS v2.0.
  2. Configuration de la relation de confiance et établissement du SSO.
  3. Publication du serveur ADFS sur Internet pour permettre la mobilité.

Suivez les étapes d'installation et configuration de ADFS v2 sur cet article : https://blogs.technet.com/b/dcaro/archive/2011/05/17/office-365-mise-en-place-de-la-federation-identite-partie-2.aspx

Comments

  • Anonymous
    December 18, 2013
    Lors de l’IT Camp « SQL Server /SharePoint/Windows Intune, les scénarios d’usage en mode Cloud hybride