Identité Workspace

L’identité principale de l’espace de travail d’un utilisateur autorise l’accès à tous les flux de ressources d’espace de travail, y compris les microapplications, les applications mobiles, les applications virtuelles, les postes de travail virtuels et le contenu. Citrix Workspace permet aux organisations de choisir le fournisseur d’identité principal de l’utilisateur.

Fournisseur d’identité (IdP)

Un fournisseur d’identité est l’autorité finale de l’identité de l’utilisateur. Le fournisseur d’identité est responsable des stratégies visant à protéger et à sécuriser l’identité de l’utilisateur, ce qui inclut les stratégies de mot de passe, les stratégies d’authentification multifacteur et les stratégies de verrouillage.

Avant l’ère du cloud, les organisations avaient une seule option pour un fournisseur d’identité : Windows Active Directory. Mais maintenant, presque tous les systèmes ou services nécessitant un compte utilisateur unique agissent comme un fournisseur d’identité. Facebook, LinkedIn, Twitter, Workday et Google sont tous des fournisseurs d’identité car chacun est l’autorité finale sur l’identité d’un utilisateur au sein de son service. En outre, une recommandation de sécurité commune, rarement suivie, consiste à utiliser des mots de passe différents pour chaque identité afin de limiter l’impact d’un mot de passe volé.

L’approche traditionnelle de l’identité offre l’une des pires expériences utilisateur imaginables. Les utilisateurs sont constamment mis au défi de s’authentifier. Les utilisateurs sont obligés de se souvenir de mots de passe uniques et complexes pour chaque service. Les utilisateurs passent un temps précieux à réinitialiser les mots de passe et à déverrouiller leurs comptes en raison des informations d’identification oubliées.

Citrix Workspace offre une meilleure alternative au statu quo. Citrix Workspace permet à chaque organisation de choisir une identité principale à partir d’une liste croissante d’options, qui inclut actuellement.

  • Windows Active Directory
  • Azure Active Directory
  • Okta
  • Citrix Gateway

Identité de l'espace de travail

Citrix Workspace s’appuie sur le micro-service Identity Broker pour gérer l’authentification auprès du fournisseur d’identité configuré. Une authentification réussie de l’espace de travail permet au flux de ressources µ-service de créer une liste de ressources autorisées à la disposition de l’utilisateur.

Cependant, beaucoup de ces services ont, ou nécessitent une identité différente de l’identité principale de l’espace de travail de l’utilisateur, car ils utilisent un fournisseur d’identité différent. Le service µ-Single Sign-on traduit l’identité principale de l’espace de travail de l’utilisateur en une identité spécifique à la ressource en utilisant des approches appropriées telles que :

  • SAML
  • Kerberos
  • Formulaires
  • Cartes à puce virtuelles

L’approche Citrix Workspace des identités primaires et secondaires crée une expérience dans laquelle les utilisateurs s’authentifient physiquement une fois et que tous les défis d’authentification suivants sont automatiquement satisfaits.

Courtage d’identité

Un fournisseur d’identité et la base de données d’identité associée sont l’autorité finale pour l’identité d’un utilisateur. Cependant, chaque fournisseur d’identité est différent. Chaque fournisseur d’identité intègre différents paramètres, stratégies et critères pour l’identité d’un utilisateur.

Dans Citrix Workspace, le service µ-service identités redirige la demande d’authentification principale vers le fournisseur d’identité configuré. Une fois que la demande d’authentification est transférée au fournisseur d’identité, les stratégies d’authentification, au sein du fournisseur d’identité, dictent la manière dont l’utilisateur doit s’authentifier, ce qui inclut souvent des stratégies d’authentification multifacteur.

Une fois que le fournisseur d’identité a réussi à authentifier l’utilisateur, le service de broker d’identité µ-reçoit une réponse d’authentification réussie. L’avantage de cette approche est que les organisations peuvent modifier les stratégies d’authentification au sein du fournisseur d’identité sans affecter Citrix Workspace.

En plus d’une réponse d’authentification réussie de la part du fournisseur d’identité, le service de broker d’identité µ-service reçoit et traduit les informations uniques du fournisseur d’identité en un ensemble standard de revendications concernant l’utilisateur.

Les revendications concernant un utilisateur sont simplement des informations identifiant l’utilisateur, qui peuvent être un UPN, un SID, un GUID, un e-mail ou tout autre contenu dans la base de données du fournisseur d’identité. Les revendications permettent à Citrix Workspace de générer une liste de ressources et de services auxquels l’utilisateur est autorisé à accéder. Par exemple, si l’identité principale de l’utilisateur est un ID Google, Citrix Workspace utilise l’ID Google pour contrôler l’autorisation d’autres ressources et services non liés à Google ID, tels que Workday, SAP, Windows, Slack et d’autres. Dit d’une autre façon, avec Citrix Workspace, les utilisateurs peuvent utiliser un identifiant Google unique pour se connecter à chaque ressource autorisée, y compris Windows.

Dans Citrix Workspace, le service identity broker µ-continue de se développer pour inclure des options supplémentaires pour le fournisseur d’identité principal. Le service identity broker µ-comprend des fournisseurs d’identité qui peuvent être disponibles à partir d’un emplacement local ou le service identity broker µ-service peut utiliser des fournisseurs d’identité basés sur le cloud. Le diagramme suivant fournit une vue d’ensemble de la plate-forme d’identité Citrix Workspace et de toutes les options actuelles du fournisseur d’identité, qui sont décrites plus loin en détail.

![(Présentation de l’identité de l’espace de travail)]/en-us/tech-zone/learn/media/tech-briefs_workspace-identity_identity-brokering.png

Chacun des fournisseurs d’identité est unique ; mais à la fin, chaque fournisseur d’identité indique à Citrix Workspace quelques choses sur l’utilisateur :

  1. Le nom d’utilisateur
  2. L’utilisateur s’est authentifié avec succès
  3. Réclamations concernant l’utilisateur

Pour mieux comprendre les détails de chaque fournisseur d’identité, consultez les sections suivantes sur les fournisseurs d’identité principaux

  • Active Directory
  • Active Directory avec TOTP
  • Azure Active Directory
  • Citrix Gateway
  • Okta
  • Google

Active Directory

Une fois configuré, les utilisateurs peuvent s’authentifier auprès de Citrix Workspace à l’aide des informations d’identification Active Directory.

(/en-us/tech-zone/learn/media/tech-briefs_workspace-identity_active-directory-idp.png)![IdP Active Directory]

Pour intégrer Citrix Workspace à un domaine Active Directory local, Workspace doit pouvoir communiquer avec un contrôleur de domaine. En déployant un ensemble hautement disponible de connecteurs cloud dans l’environnement local, les connecteurs cloud établissent un canal de contrôle sortant avec l’abonnement Citrix Cloud de l’organisation. Le canal de contrôle sortant permet à Citrix Workspace de tunnels de communication en toute sécurité, via le port 443, avec des composants locaux sans nécessiter de modifications de port de pare-feu entrant.

Le connecteur de nuage inclut un service de fournisseur AD qui permet à Citrix Workspace de lire les informations d’utilisateur et de groupe à partir du domaine Active Directory. Lorsqu’un utilisateur s’authentifie auprès de Citrix Workspace, les informations d’identification sont envoyées au contrôleur de domaine local via le service AD Provider du connecteur cloud.

Ports Active Directory

Active Directory avec TOTP

Pour de nombreuses organisations, fournir un accès aux services d’application et de bureau avec un nom d’utilisateur et un mot de passe ne fournit pas une sécurité adéquate. Citrix Workspace intègre un TOTP Mot de passe unique basé sur le temps (cloud livré) fournissant une authentification multifacteur en introduisant un « quelque chose que vous avez », qui est le jeton TOTP, avec le « quelque chose que vous savez », qui est le mot de passe.

TOTP génère un code aléatoire à 6 chiffres qui change toutes les 30 secondes. Ce code est basé sur une clé secrète qui est partagée entre l’application mobile de l’utilisateur et l’infrastructure principale. La clé secrète est le facteur « quelque chose que vous avez » pour l’authentification multifacteur. Pour générer le code aléatoire, un algorithme de hachage sécurisé standard est appliqué à la clé secrète et à l’heure actuelle. Pour s’authentifier, le code de l’application mobile est comparé au code de l’infrastructure backend.

Pour s’inscrire au service TOTP, chaque utilisateur crée et installe une clé secrète pré-partagée dans l’application d’authentification sur un appareil mobile.

Active Directory avec enregistrement TOTP

Une fois que l’utilisateur s’est inscrit avec succès auprès du micro-service TOTP, l’utilisateur doit utiliser le jeton, avec ses informations d’identification Active Directory, pour s’authentifier avec succès auprès de Citrix Workspace.

Active Directory avec authentification TOTP

Étant donné que TOTP est intégré en tant que fonctionnalité dans Citrix Workspace, la complexité de la configuration et de la maintenance d’une solution de type TOTP dans un environnement local est supprimée. Grâce à cette fonctionnalité dans Citrix Workspace, les administrateurs activent le service et les utilisateurs enregistrent les périphériques.

Il y a quelques éléments à prendre en compte lors de l’activation de l’authentification multifactorielle basée sur Totp :

  • Apps d’authentification : TOTP utilise un algorithme standard pour générer le jeton basé sur le temps. Les utilisateurs peuvent utiliser n’importe quel nombre d’applications mobiles pour générer les jetons, notamment : Citrix SSO, Microsoft Authenticator et d’autres.
  • Nombre de jetons : les utilisateurs sont autorisés à un jeton (clé) par compte d’utilisateur.
  • Nombre de périphériques : Bien que les utilisateurs soient limités à un seul jeton (clé), les utilisateurs peuvent installer le jeton sur plusieurs appareils. Cependant, l’installation doit se faire pendant la phase d’enregistrement car les utilisateurs ne sont pas en mesure de révéler le code QR ou la clé secrète une fois l’enregistrement terminé.
  • Remplacement de l’appareil : chaque fois qu’un utilisateur remplace son appareil mobile, il doit l’enregistrer auprès du service TOTP. Lorsque l’utilisateur passe à nouveau par le processus d’enregistrement TOTP, l’ancienne clé secrète est supprimée. Tout périphérique utilisant l’ancienne clé secrète ne parvient pas à générer le jeton correct, ce qui entraîne l’échec de l’authentification Workspace.
  • Réinitialisation des jetons : les administrateurs peuvent réinitialiser manuellement le jeton d’un utilisateur. Une fois réinitialisé, les utilisateurs ne peuvent pas terminer l’authentification sans réenregistrer avec le service TOTP.
  • Déploiement : comme toutes les modifications de configuration de gestion des identités et des accès, l’activation de TOTP sur un abonnement Workspace a un impact sur tous les utilisateurs. Lorsque cette option est activée, toute nouvelle tentative d’authentification échoue jusqu’à ce que l’utilisateur s’inscrit avec succès auprès du service TOTP.

Le Vidéo TOTP Tech Insight fournit des détails supplémentaires sur l’expérience utilisateur et administrateur.

Azure Active Directory

Citrix Workspace permet aux utilisateurs de s’authentifier avec un compte Azure Active Directory. L’authentification peut être aussi simple qu’un nom d’utilisateur et un mot de passe ou utiliser toutes les stratégies d’authentification multifacteurs disponibles dans Azure Active Directory. L’intégration entre Citrix Workspace et Azure Active Directory entraîne la gestion du processus d’authentification par Azure Active Directory tout en renvoyant un jeton d’identité pour l’utilisateur.

(/en-us/tech-zone/learn/media/tech-briefs_workspace-identity_azure-active-directory-idp.png)![IdP Azure Active Directory]

Pour intégrer Citrix Workspace et Azure Active Directory, Citrix Workspace crée automatiquement une application d’entreprise dans Azure et définit les autorisations correctes. Ces autorisations sont les suivantes (capacités en lecture seule) :

  • Se connecter et lire le profil utilisateur
  • Lire les profils de base de tous les utilisateurs
  • Lire les profils complets de tous les utilisateurs
  • Lire les données d’annuaire
  • Lire tous les groupes

Azure Active Directory authentifie l’utilisateur. Une fois l’utilisateur authentifié avec succès, Azure fournit à Citrix Workspace un jeton d’identité Azure incluant des revendications sur l’utilisateur afin de les identifier de manière unique dans le répertoire correct.

Citrix Workspace utilise les revendications Azure Active Directory pour autoriser l’utilisateur à accéder aux ressources et aux services dans Citrix Workspace.

Autoriser l’accès à une ressource nécessite une seule « source de vérité ». La source de la vérité est l’autorité finale sur les décisions d’autorisation. Lorsque vous utilisez Azure Active Directory comme annuaire principal des utilisateurs, le type de ressource Workspace dicte la source de vérité.

  • Service de collaboration de contenu : pour les fichiers utilisateur et le contenu, le Service de Content Collaboration est la source de vérité. Lorsque Azure Active Directory est le fournisseur d’identité pour Workspace, une identité Azure Active Directory et le compte Content Collaboration doivent utiliser la même adresse e-mail. Pour les informations sur l’appartenance à un groupe, le service Content Collaboration est la source de vérité. Les informations d’appartenance au groupe sont basées sur l’adresse e-mail de l’utilisateur.
  • Service de Endpoint Management : pour les applications mobiles, le service Endpoint Management utilise Active Directory comme source de vérité. Lorsque Azure Active Directory est le fournisseur d’identité pour Workspace, une identité Azure Active Directory doit contenir des revendications Active Directory spécifiques (SID, UPN et ImmutableID qui ne change pas). Ces revendications associent une identité Azure Active Directory à une identité Active Directory. Si le service Endpoint Management utilise l’appartenance à un groupe, Active Directory est la source de vérité.
  • Service de passerelle : pour les applications SaaS et Web, le service de passerelle utilise Azure Active Directory comme source de vérité. Le service de passerelle peut utiliser des comptes d’utilisateurs Azure Active Directory ou un appartenance à un groupe d’utilisateurs Azure Active Directory pour autoriser l’accès aux ressources.
  • Service Microapps : pour les applications microapplications, le service Microapps utilise Azure Active Directory comme source de vérité. Le service Microapps peut utiliser des comptes d’utilisateurs Azure Active Directory ou un membre d’un groupe d’utilisateurs Azure Active Directory pour autoriser l’accès aux ressources.
  • Citrix Virtual Apps and Desktops Service : Étant donné que les ressources Windows (VDI) requièrent une identité utilisateur basée sur Active Directory, la source de la vérité dépend de l’intégration sous-jacente Active Directory et Azure Active Directory.
    • Les identités utilisateur Azure Active Directory doivent contenir des revendications Active Directory spécifiques (SID, UPN et ImmutableID qui ne change pas). Ces revendications associent une identité Azure Active Directory à une identité Active Directory. Pour une identité utilisateur spécifique, Azure Active Directory est la source de vérité.
    • Si les décisions d’autorisation sont basées sur l’appartenance à un groupe, la source de vérité est Active Directory. Workspace envoie ensuite des demandes d’appartenance à un groupe à Active Directory via le connecteur cloud.

Le processus de liaison des paramètres Active Directory avec un ID Azure Active Directory est grandement simplifié avec l’utilisation de l’outil de synchronisation Azure Active Directory.

Le Vidéo Azure Active Directory Tech Insight fournit des détails supplémentaires sur la configuration de l’administrateur et l’expérience utilisateur lors de l’utilisation d’une YubiKey FIDO2.

Citrix Gateway

Les utilisateurs peuvent s’authentifier auprès de Citrix Workspace à l’aide d’un Citrix Gateway local. L’authentification Citrix Gateway prend en charge des stratégies d’authentification simples qui utilisent une source unique pour l’authentification utilisateur, comme Active Directory, ainsi que des stratégies d’authentification en cascade plus complexes qui reposent sur plusieurs fournisseurs et stratégies d’authentification.

L’intégration entre Citrix Workspace et Citrix Gateway entraîne la gestion du processus d’authentification initial par Citrix Gateway. Une fois que Citrix Gateway a validé l’authentification de l’utilisateur, Workspace valide les informations d’identification Active Directory avant de générer une liste de services et de ressources autorisés.

IdP Citrix Gateway

Pour intégrer Citrix Workspace et Citrix Gateway, une stratégie d’IdP OAuth doit être créée dans Citrix Gateway local, qui est un protocole d’authentification basé sur la spécification OAuth 2.0. Citrix Workspace se connecte à l’URL Citrix Gateway unique de l’organisation pour accéder à l’application OpenID Connect en référençant l’ID client de l’application, qui est protégé par une clé secrète partagée.

L’application OpenID Connect, configurée sur Citrix Gateway, utilise les stratégies d’authentification avancées liées au serveur virtuel d’authentification pour authentifier l’utilisateur. Une fois l’utilisateur authentifié avec succès auprès de Citrix Gateway, Citrix Gateway renvoie les informations d’identification Active Directory de l’utilisateur à Citrix Workspace.

Le Vidéo d’information sur Citrix Gateway Tech fournit des détails supplémentaires sur la configuration de l’administrateur et l’expérience utilisateur.

Grâce à l’utilisation de nFactor, Citrix Gateway permet aux organisations de créer un flux d’authentification plus dynamique, en tenant compte de caractéristiques telles que l’appartenance à un groupe d’utilisateurs, la propriété des appareils et l’emplacement des utilisateurs.

Dans un exemple, en utilisant la configuration la plus basique, les organisations peuvent intégrer Citrix Gateway avec Citrix Workspace pour fournir une authentification à Active Directory.

Citrix Gateway - Active Directory

Ce type de configuration nécessite une stratégie d’IdP OAuth configurée avec Citrix Workspace et une stratégie LDAP configurée pour un domaine Active Directory local. Toutefois, cette stratégie d’authentification de base peut être réalisée sans utiliser Citrix Gateway.

Dans de nombreuses organisations, les utilisateurs doivent s’authentifier par rapport à un déploiement RADIUS, comme DUO, avant de s’authentifier auprès d’Active Directory, ce qui contribue à protéger les informations d’identification Active Directory.

Citrix Gateway - DUO

Cette configuration nécessite la stratégie d’authentification pour valider d’abord une authentification RADIUS. En cas de succès, le flux d’authentification continue au facteur d’authentification suivant, à savoir l’authentification LDAP.

Avec Citrix Gateway, les organisations peuvent implémenter l’authentification contextuelle, dans laquelle le flux d’authentification de l’utilisateur dépend du contexte utilisateur actuel. Par exemple, une organisation peut implémenter différentes stratégies d’authentification pour les appareils appartenant à l’entreprise par rapport aux utilisateurs.

Citrix Gateway - Certificats

Dans cette configuration, Citrix Workspace envoie la demande d’authentification à Citrix Gateway. Citrix Gateway demande un certificat client, qui n’est disponible que sur les appareils appartenant à l’entreprise. Si le certificat est disponible et valide, l’utilisateur fournit simplement un mot de passe Active Directory. Toutefois, si le certificat n’est pas valide ou n’existe pas, ce qui serait le cas pour une machine appartenant à un utilisateur, Citrix Gateway met l’utilisateur au défi de fournir un code TOTP suivi des informations d’identification Active Directory.

Un autre exemple d’authentification contextuelle fournit différentes stratégies d’authentification basées sur l’appartenance à un groupe Active Directory.

Citrix Gateway - Groupes d'utilisateurs

Les utilisateurs qui interagissent avec des données financières, des données personnelles ou des données de propriété intellectuelle doivent se heurter à des politiques d’authentification plus strictes, comme le montre le groupe 2 dans le diagramme.

Lors de l’utilisation d’un Citrix Gateway local en tant que fournisseur d’identité, les utilisateurs peuvent utiliser l’authentification basée sur le push avec Citrix Workspace, comme indiqué dans le Vidéo d’authentification Push Tech Insight.

Quel que soit le type de stratégie d’authentification configuré, une fois que l’utilisateur a validé son identité avec succès, Citrix Gateway doit répondre à la demande Citrix Workspace initiale avec les informations d’identification Active Directory de l’utilisateur. Pour que Citrix Workspace termine le processus d’authentification et génère une liste de ressources autorisées, chaque compte d’utilisateur Active Directory doit avoir les paramètres suivants définis :

  • Adresse e-mail
  • Nom d’affichage
  • Nom commun
  • sAMAccountName
  • Nom d’utilisateur principal
  • Identificateur d’objet (OID)
  • Identifiant de sécurité (SID)

Okta

Lorsqu’il est configuré, les utilisateurs peuvent s’authentifier auprès de Citrix Workspace à l’aide des informations d’identification Okta. L’authentification peut être aussi simple qu’un nom d’utilisateur et un mot de passe ou utiliser toutes les stratégies d’authentification multifacteurs disponibles dans Okta. L’intégration entre Citrix Workspace et Okta entraîne la gestion du processus d’authentification par Okta tout en renvoyant un jeton d’identité et d’accès pour l’utilisateur.

IdP Okta

Pour intégrer Citrix Workspace et Okta, une application OpenID Connect doit être créée dans Okta. Citrix Workspace se connecte à l’URL Okta unique de l’organisation pour accéder à l’application OpenID Connect en référençant l’ID client de l’application, qui est protégé par une clé secrète partagée.

L’application OpenID Connect authentifie l’utilisateur. Une fois l’utilisateur authentifié avec succès auprès d’Okta, Okta fournit à Citrix Workspace deux jetons de sécurité :

  • Token d’accès : jeton prouvant que l’utilisateur a l’autorisation d’accéder à la ressource Okta (application OpenID Connect), éliminant ainsi le besoin de réauthentifier continuellement.
  • Jeton d’identité : jeton prouvant l’identité de l’utilisateur. Le jeton d’identité contient des revendications (informations) sur l’utilisateur authentifié. Le jeton est codé pour prouver qu’il n’a pas été falsifié.

Ces jetons permettent à Citrix Workspace d’accéder à l’application OpenID Connect et de générer une liste de ressources autorisées en fonction de l’identité Okta de l’utilisateur.

Autoriser l’accès à une ressource nécessite une seule « source de vérité ». La source de la vérité est l’autorité finale sur les décisions d’autorisation. Lorsque vous utilisez Okta comme répertoire d’utilisateurs principal, le type de ressource Workspace dicte la source de la vérité.

  • Service de collaboration de contenu : pour les fichiers utilisateur et le contenu, le Service de Content Collaboration est la source de vérité. Lorsque Okta est le fournisseur d’identité principal pour Workspace, une identité Okta et le compte Content Collaboration doivent utiliser la même adresse e-mail. Pour les informations sur l’appartenance à un groupe, le service Content Collaboration est la source de vérité. Les informations d’appartenance au groupe sont basées sur l’adresse e-mail de l’utilisateur. Dans ce scénario, Okta n’est utilisé que comme fournisseur d’identité pour Workspace.
  • Service de Endpoint Management : pour les applications mobiles, le service Endpoint Management utilise Active Directory comme source de vérité. Lorsque Okta est le fournisseur d’identité principal pour Workspace, une identité Okta doit contenir des revendications Active Directory spécifiques (SID, UPN et GUID). Ces revendications associent une identité Okta à une identité Active Directory. Si le service Endpoint Management utilise l’appartenance à un groupe, Active Directory est la source de vérité.
  • Service de passerelle : pour les applications SaaS et Web, le service de passerelle utilise Okta comme source de vérité. Le service Gateway peut utiliser des comptes d’utilisateurs Okta ou un membre d’un groupe d’utilisateurs Okta pour autoriser l’accès aux ressources.
  • Service Microapps : pour les applications de microapplications, le service Microapps utilise Okta comme source de vérité. Le Service Microapps peut utiliser des comptes d’utilisateur Okta ou un membre d’un groupe d’utilisateurs Okta pour autoriser l’accès aux ressources.
  • Citrix Virtual Apps and Desktops Service : Étant donné que les ressources Windows (VDI) requièrent une identité utilisateur basée sur Active Directory, la source de la vérité dépend de l’intégration sous-jacente Active Directory et Okta.
    • Les identités utilisateur Okta doivent contenir des revendications Active Directory spécifiques (SID, UPN et GUID). Ces revendications associent une identité Okta à une identité Active Directory. Pour une identité utilisateur spécifique, Okta est la source de la vérité.
    • Si les décisions d’autorisation sont basées sur l’appartenance à un groupe, la source de vérité est basée sur les paramètres de synchronisation entre Active Directory et Okta. Si un groupe Active Directory est synchronisé avec Okta et inclut des revendications Active Directory (SID), Okta devient la source de vérité pour les groupes utilisant l’attribut ObjectSid. Cet attribut Okta n’est renvoyé que pour les groupes Active Directory tels que définis par le Spécifications Okta. Les groupes Okta natifs n’auront pas cet ensemble d’attributs, ce qui fait qu’Active Directory deviendra la source de vérité. Workspace envoie ensuite des demandes d’appartenance à un groupe à Active Directory via le connecteur cloud.

Le processus de liaison des paramètres Active Directory avec un ID Okta est grandement simplifié avec l’utilisation de l’outil de synchronisation Okta Active Directory. Les revendications Active Directory doivent respecter la norme d’attribution de noms suivante dans Okta.

Okta - Paramètres

La configuration et la configuration d’Okta en tant que fournisseur d’identité sont détaillées dans le Vidéo Okta Tech Insight.

Identité Workspace