Fourniture personnalisée Office 365

Découvrez comment configurer la fourniture personnalisée de Microsoft Office 365.

La configuration par défaut d’Office 365 inclut Active Directory et DirSync/Microsoft Entra ID Sync Services, qui synchronisent et provisionnent les utilisateurs AD dans votre Microsoft Entra ID pour SSO. Dans cette configuration, Auth0 est le fournisseur d’identité, nous fournissons l’authentification unique (SSO) pour ces utilisateurs.

Mais que se passe-t-il si vous souhaitez permettre à des sous-traitants, des partenaires ou même des clients d’accéder à votre environnement Office 365 (par exemple, SharePoint)? Dans ce cas, l’approche par défaut n’est pas optimale, car ces utilisateurs devront être créés dans votre environnement Entra ID. Au lieu de cela, vous devez personnaliser la fourniture des utilisateurs Entra ID à l’aide de Règles d’Auth0.

La fourniture personnalisée vous permet de créer des utilisateurs dans Microsoft Entra ID (et donc Office 365) tout comme ils se connectent à partir de n’importe quelle connexion disponible dans Auth0. (Dans ce cas, votre règle prend en charge la tâche DirSync pour tout type de connexion où DirSync ne fonctionnerait pas). Cette configuration vous permet d’offrir une variété d’options de connexion (y compris Facebook, LinkedIn, Google Workspace) à votre environnement Office 365.

​

Prérequis

Avant de pouvoir configurer la fourniture personnalisée, vous devez :

• Configurer Office 365 : Enregistrer un domaine personnalisé et configurer Office 365 en tant qu’application tierce dans Auth0.

​

Configurer Microsoft Entra ID

La fourniture personnalisé utilise la Graph API de Microsoft Entra ID pour provisionner de nouveaux utilisateurs dans Microsoft Entra ID. Pour accéder à la Graph API de Microsoft Entra ID, vous devez créer une application dans le répertoire Microsoft Entra ID qui a été associé à l’abonnement Office 365 :

1. Connectez-vous au Portail Azure.

2. Choisissez Microsoft Entra ID dans la navigation de gauche.

3. Sélectionnez Enregistrements d’applications dans le nouveau menu.

4. Cliquez sur Enregistrement d’une nouvelle application.

5. Remplissez le formulaire :

   1. Saisissez un nom pour l’application (par exemple « Fourniture Auth0 »).
   2. Sélectionnez Web app/API comme type d’application.
   3. Insérez une URL de connexion. Vous pouvez saisir n’importe quelle URL valide; celle-ci ne sera pas vraiment utilisée.

6. L’application récemment créée sera indiquée dans la liste Enregistrements d’applications. Sélectionnez-la.

7. Dans le volet Réglages (Microsoft appelle ces sections des « volets »), choisissez Touches.

8. Saisissez une Description (comme Fourniture Auth0) et choisissez une Durée pour la nouvelle clé. Si vous choisissez d’émettre une clé non permanente, notez la date d’expiration et créez un rappel pour remplacer la clé par une nouvelle avant qu’elle n’expire.

9. Cliquez sur pour enregistrer la clé, puis copiez la Clé d’application. Cette clé ne sera affichée qu’une seule fois; elle est nécessaire pour la règle Auth0.

10. Choisissez Autorisations requises, et cliquez sur Ajouter dans la nouvelle lame.

11. Sélectionnez l’API Microsoft Graph, puis cochez Lire et écrire des données de répertoire sous Autorisations d’application.

12. De retour dans Autorisations requises, cliquez sur le bouton Autoriser les autorisations, puis cliquez sur Oui pour accorder les autorisations demandées.

​

Créer la règle de fourniture de Microsoft Entra ID

La règle suivante illustre le processus de fourniture :

1. Si l’utilisateur provient de la connexion AD, ignorer le processus de fourniture (il sera pris en charge par DirSync).
2. Si l’utilisateur a déjà été provisionné dans Microsoft Entra ID, il suffit de poursuivre la transaction de connexion.
3. Utilisez l’ID et la clé client Entra ID pour obtenir un jeton d’accès à l’API Graph.
4. Créez un utilisateur dans Microsoft Entra ID.
5. Attribuez une licence à l’utilisateur.
6. Poursuivez la transaction de connexion.

Le nom d’utilisateur est généré par la fonction createAzureADUser qui, par défaut, génère un nom d’utilisateur au format [e-mail]. Vous pouvez modifier cette valeur à votre guise; assurez-vous simplement qu’elle est unique pour tous vos utilisateurs.

Assurez-vous de définir les valeurs correctes pour les valeurs AUTH0_OFFICE365_CLIENT_ID, AAD_CUSTOM_DOMAIN, AAD_DOMAIN, AAD_APPLICATION_ID et AAD_APPLICATION_API_KEY dans votre objet de configuration pour que les valeurs soient disponibles dans le code de votre règle. Pour en savoir plus, lisez Configuration du magasin pour les règles.

Dans le code, vous verrez également que la règle attendra environ 15 secondes après la fourniture de l’utilisateur. En effet, il faut quelques secondes avant que l’utilisateur fourni soit disponible pour Office 365.

function (user, context, callback) {
  // Require the Node.js packages that we are going to use.
  // Check this website for a complete list of the packages available:
  // https://auth0-extensions.github.io/canirequire/
  var rp = require('request-promise');
  var uuidv4 = require('uuid');

  // The name of your Active Directory connection (if using one)
  var AUTH0_AD_CONNECTION = 'Travel0AD';
  // The client_id of your Office 365 SSO integration
  // You can get it from the URL when editing the SSO integration,
  // it will look like
  // https://manage.auth0.com/#/externalapps/{the_client_id}/settings
  var AUTH0_OFFICE365_CLIENT_ID = configuration.AUTH0_OFFICE365_CLIENT_ID;
  // The main domain of our company.
  var YOUR_COMPANY_DOMAIN = 'mycompanyurl.com';
  // Your Azure AD domain.
  var AAD_DOMAIN = configuration.AAD_DOMAIN;
  // The Application ID generated while creating the Azure AD app.
  var AAD_APPLICATION_ID = configuration.AAD_APPLICATION_ID;
  // The generated API key for the Azure AD app.
  var AAD_APPLICATION_API_KEY = configuration.AAD_APPLICATION_API_KEY;
  // The location of the users that are going to access Microsoft products.
  var AAD_USAGE_LOCATION = 'US';
  // Azure AD doesn't recognize the user instantly, it needs a few seconds
  var AAD_USER_CREATE_DELAY = 15000;
  // The key that represents the license that we want to give the new user.
  // Take a look in the following URL for a list of the existing licenses:
  // https://gist.github.com/Lillecarl/3c4727e6dcd1334467e0
  var OFFICE365_KEY = 'O365_BUSINESS';

  // Only execute this rule for the Office 365 SSO integration.
  if (context.clientID !== AUTH0_OFFICE365_CLIENT_ID) {
    return callback(null, user, context);
  }

  // Skip custom provisioning for AD users.
  if (context.connection === AUTH0_AD_CONNECTION) {
    return callback(null, user, context);
  }

  // If the user is already provisioned on Microsoft AD, we skip
  // the rest of this rule
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.office365Provisioned) {
    return connectWithUser();
  }

  // Global variables that we will use in the different steps while
  // provisioning a new user.
  var token;
  var userPrincipalName;
  var mailNickname = user.email.split('@')[0];
  var uuid = uuidv4.v4();
  var immutableId = new Buffer(uuid).toString('base64');
  var userId;

  // All the steps performed to provision new Microsoft AD users.
  // The definition of each function are below.
  getAzureADToken()
    .then(createAzureADUser)
    .then(getAvailableLicenses)
    .then(assignOffice365License)
    .then(saveUserMetadata)
    .then(waitCreateDelay)
    .then(connectWithUser)
    .catch(callback);

  // Requests an Access Token to interact with Windows Graph API.
  function getAzureADToken() {
    var options = {
      method: 'POST',
      url: 'https://login.windows.net/' + AAD_DOMAIN + '/oauth2/token?api-version=1.5',
      headers: {
        'Content-type': 'application/json',
        },
      json: true,
      form: {
        client_id: AAD_APPLICATION_ID,
        client_secret: AAD_APPLICATION_API_KEY,
        grant_type: 'client_credentials',
        resource: 'https://graph.windows.net'
      },
    };

    return rp(options);
  }

  // Gets the Access Token requested above and assembles a new request
  // to provision the new Microsoft AD user.
  function createAzureADUser(response) {
    token = response.access_token;
    userPrincipalName = 'auth0-' + uuid + '@' + YOUR_COMPANY_DOMAIN;

    var options = {
      url: 'https://graph.windows.net/' + AAD_DOMAIN + '/users?api-version=1.6',
      headers: {
        'Content-type': 'application/json',
        'Authorization': 'Bearer ' + token
      },
      json: true,
      body: {
        accountEnabled: true,
        displayName: user.nickname,
        mailNickname: mailNickname,
        userPrincipalName: userPrincipalName,
        passwordProfile: {
          password: immutableId,
          forceChangePasswordNextLogin: false
        },
        immutableId: immutableId,
        usageLocation: AAD_USAGE_LOCATION
      },
    };

    return rp(options);
  }

  // After provisioning the user, we issue a request to get the list
  // of available Microsoft products licenses.
  function getAvailableLicenses(response) {
    userId = response.objectId;
    var options = {
      url: 'https://graph.windows.net/' + AAD_DOMAIN + '/subscribedSkus?api-version=1.6',
      json: true,
      headers: {
        'Content-type': 'application/json',
        'Authorization': 'Bearer ' + token
      }
    };
    return rp(options);
  }

  // With the licenses list, we iterate over it to get the id (skuId) of the
  // license that we want to give to the new user (office 365 in this case).
  // We also issue a new request to the Graph API to tie the user and the
  // license together.
  function assignOffice365License(response) {
    var office365License;

    for (var i = 0; i < response.value.length; i++) {
      if (response.value[i].skuPartNumber === OFFICE365_KEY) {
        office365License = response.value[i].skuId;
        break;
      }
    }

    var options = {
      url: ' https://graph.windows.net/' + AAD_DOMAIN + '/users/' + userId + '/assignLicense?api-version=1.6',
      headers: {
        'Content-type': 'application/json',
        'Authorization': 'Bearer ' + token
      },
      json: true,
      body: {
        'addLicenses': [
          {
            'disabledPlans': [],
            'skuId': office365License
          }
        ],
        'removeLicenses': []
      }
    };
    return rp(options);
  }

  // After provisioning the user and giving a license to them, we record
  // (on Auth) that this Google Workspace user has already been provisioned. We
  // also record the user's principal username and immutableId to properly
  // redirect them on future logins.
  function saveUserMetadata() {
    user.app_metadata = user.app_metadata || {};

    user.app_metadata.office365Provisioned = true;
    user.app_metadata.office365UPN = userPrincipalName;
    user.app_metadata.office365ImmutableId = immutableId;

    return auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
  }

  // As mentioned, Windows Graph API needs around 10 seconds to finish
  // provisioning new users (even though it returns ok straight away)
  function waitCreateDelay() {
    return new Promise(function (resolve) {
      setTimeout(function() {
        resolve();
      }, AAD_USER_CREATE_DELAY);
    });
  }

  // Adds the principal username and immutableId to the user object and ends
  // the rule.
  function connectWithUser() {
    user.upn = user.app_metadata.office365UPN;
    user.inmutableid = user.app_metadata.office365ImmutableId;
      return callback(null, user, context);
  }
}

Ce code montre le processus de provisionnement d’un nouvel utilisateur, mais vous pouvez également l’adapter pour synchroniser les métadonnées d’utilisateurs existants.

​

Expérience utilisateur

La manière la plus simple pour vos utilisateurs externes de s’authentifier est d’utiliser la connexion initiée par le fournisseur d’identité.

Vous devez rediriger vos utilisateurs vers l’URL suivante (par exemple, en utilisant un « lien intelligent » comme https://office.travel0.com) :

https://{yourDomain}/login?client=AUTH0_OFFICE365_CLIENT_ID&protocol=wsfed&state=&redirect_uri=&

Cela leur montrera la page de connexion Auth0, après quoi ils seront redirigés vers Office 365. Il sera important d’expliquer aux utilisateurs externes que c’est la seule façon de s’authentifier, car la page de connexion à Office 365 ne prend pas en charge la détection de domaine vital pour ces utilisateurs externes. Cela signifie également que, lorsqu’ils essaient d’ouvrir un lien, ils doivent d’abord visiter le lien intelligent avant de pouvoir accéder au lien qu’ils ont essayé d’ouvrir.

Dans cet exemple, Travel0 a activé quelques comptes sociaux et une connexion de base de données pour son application tierce Office 365 dans Auth0.

​

Lien profond

Certaines implémentations peuvent nécessiter des liens profonds (par exemple, vers SharePoint Online). Dans ce cas, un lien intelligent doit être créé, à partir de la page de connexion à Office 365 :

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr={yourCustomDomain}&wreply={deepLink}

Le premier paramètre, {yourCustomDomain}, doit être le domaine que vous avez configuré dans Microsoft Entra ID pour l’authentification unique (SSO) (par exemple, travel0.com). En spécifiant ce domaine comme whr, Microsoft Entra ID saura qu’il doit rediriger vers Auth0 au lieu d’afficher la page de connexion.

Le paramètre DEEP_LINK doit être une URL codée dans Office 365 (par exemple, une page dans SharePoint Online ou Exchange).

URL d’exemple :

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=travel0.com&wreply=https%3A%2F%2Ftravel0%2Esharepoint%2Ecom