1. Le contexte : 

Imaginons un client « Grand groupe à dimension internationale » désireux d’offrir à tout ses collaborateurs dans le monde un accès à Microsoft O365 ; Skype for Business, Yammer, SharePoint, Exchange Online ; mais également à toute la galaxie d’applications Saas existante sur le marché, le tout bien entendu en mode d’authentification transparente Single Sign On (SSO).

2. Les contraintes : 

Coté client en terme de contrainte c’est relativement « simple » : une multitude d’environnements Active Directory : Une forêt de ressource, plusieurs forêts de comptes et enfin un grand nombre d’entités à travers le monde possédant leur propre forêt Active directory indépendante (donc leur propre règles de gestion), n’ayant aucun trusts Active Directory avec les autres entités du groupe et pour certaines une connexion limitée sur Internet.

3. La solution : 

La première option serait de partir sur une solution Microsoft afin de déployer une architecture AADConnect/ADFS redondante permettant de connecter tout ce beau monde : donc nous aurions suivant les cas d’usages besoin éventuellement d’un AD “tête de pont” réconciliant toutes les identités du groupe, d’un AADConnect centralisé ayant un accès à minima en lecture à l’ensemble des forêts du groupe pour réaliser le provisioning des identités (en mode Saas pourquoi pas), une ferme – voire plusieurs ? 🙂 – ADFS/proxy ADFS avec des trusts AD bidirectionnels de partout pour l’authentification… C’est possible ? Oui… Compliqué ? Aussi… Rapide ?  🙂

La deuxième option serait d’utiliser OKTA.

OKTA est une solution IDaaS (Identity as a Service) autrement dit une solution de gestion d’identité hébergée dans le cloud.

Soyons clairs, OKTA ne couvre pas tout le spectre de l’IAM et se concentre essentiellement sur les fonctionnalités liées à la consommation d’applications Saas : O365, Saleforces, Google, AWS, etc.

OKTA propose les fonctionnalités suivantes :

• Un Référentiel unique des utilisateurs appelé Universal Directory, représentant l’annuaire de consolidation de l’ensemble de vos identités,
• Du Provisioning permettant d’aligner et consolider l’Universal Directory vis-à-vis des autres sources d’annuaires et des diverses applications Saas,
• De l’Authentification, simple ou multiple via les fonctionnalités natives OKTA MFA,
• Du Single Sign-On (SSO) permettant d’améliorer l’expérience utilisateur,
• De Fédération pour profiter du SSO sécurisé via des protocoles standardisés,
• Une Gestion des mots de passe pour réinitialisation en mode self-service,
• De Délégation pour l’administration de la solution.

En revanche peu ou pas de gestion de Rôles, gestion des Autorisations et de Gouvernance.

4. Techniquement : 

Techniquement, OKTA permet de provisionner des identités en provenance de multiples annuaires Active Directory ou LDAP dans son Universal Directory. Il est ensuite possible de réconcilier et transformer ses identités au travers de profils et de règles de « mapping » pour consommer les quelques 5000 applications Saas pré-câblées proposées via les protocoles standardisés de Fédération : SAML 1.0/2.0, WSFed, OAuth2 & OIDC.

L’Universal Directory est un Identity provider (IDP) :

Dans le cas d’usage d’un raccordement O365, OKTA peut remplacer les composants Microsoft suivants :

• DirSync/AADSync/AADConnect pour la synchronisation des identités
• ADFS pour l’établissement de la fédération d’identité et donc l’authentification

Toutefois, Il existe une limitation, OKTA n’est pas capable de synchroniser les comptes désactivés dans une topologie « Forêts de ressources / Forêt de comptes ». Dans ce cas de topologie complexe, le composant Microsoft de synchronisation sera donc conservé et OKTA sera uniquement en charge de l’authentification.

En termes de ressource, pour intégrer un environnement Active Directory, il est obligatoire de déployer à minima un unique agent sur un serveur membre. Cet agent nommé OKTA AD Agent aura pour tâche principale la réalisation du provisioning des identités, la synchronisation des attributs et l’authentification en mode « Common Sign On » CSO c.-à-d. l’utilisateur doit indiquer son « Login + mot de passe ».

L’authentification SSO nécessite le déploiement d’un deuxième Agent nommé OKTA Desktop SSO ou IWA Web APP. Le fonctionnement de l’Agent OKTA Dekstop SSO repose sur une implémentation du composant Microsoft IIS et l’Authentification Intégrée Windows (IWA). Notons que les 2 agents peuvent très bien être installés sur le même serveur.

Toutes les communications entre le Cloud OKTA et l’environnement cible se fait en HTTPS dans le sens OKTA AD agent => Cloud OKTA. C’est une unique connexion sortante d’une durée de 30 secondes durant laquelle l’Agent OKTA AD récupère toute les exécutions en attente (Provisioning, synchronisation des attributs, AuthN, etc.) dans le cloud OKTA. A l’issue des 30 secondes, la connexion est arrêtée et une nouvelle est initiée, cette mécanique se nomme le « HTTP long pooling ».

OKTA supporte nativement les trusts Windows permettant dans les topologies complexes multi-forêt/Domaine le déploiement d’un seul serveur hébergeant l’OKTA AD agent & OKTA IWA Web APP pour réaliser l’ensemble des opérations. Bien entendu il est recommandé pour assurer la redondance et la résilience de déployer plusieurs instances des services OKTA => A minima 2 VMs hébergeant l’agent OKTA AD & IWA.

Le dernier schéma présente une vue topologie dite “complexe” d’une Grande Entreprise constituée de multiples entités, avec l’Universal Directory, consommant de l’O365 ou toutes autres applications Saas raccordées sur OKTA, avec si besoin une touche de MFA*

* Le MFA s’applique au niveau de l’accès au cloud OKTA et/ou au niveau des applications raccordées. Le MFA est configuré au travers de « Sign on policy », les facteurs associés sont la localisation de l’utilisateur (Zone IP), l’appartenance à un groupe OKTA/Windows et le type d’authentification. Dès lors que les conditions de la « Sign on policy » sont satisfaites il est possible de déclencher un second facteur d’authentification => MFA.

OKTA supporte les facteurs d’authentification suivants :

5. Conclusion : 

Question : OKTA est-il capable de répondre aux cas d’usages « complexes » d’un grand groupe à dimension Internationale ?

Réponse : Oui 🙂 

Stéphane

Consultant Sécurité