Fédération d’identité et SSO : les fondamentaux

Dans de nombreuses organisations de logiciels, des termes tels que l’authentification, SSO et SAML sont assez souvent entendus. Certes, de nombreuses personnes s’enfuiront en entendant ces termes, essayant d’éviter de faire tout travail lié à l’authentification.

Dans cet article, nous allons passer en revue les principes fondamentaux de SSO et plonger dans SAML et OIDC, vous aidant à comprendre pourquoi il s’agit d’un sujet si courant et vous permettant de participer à la prochaine conversation à ce sujet !

Qu’est-ce que le SSO et pourquoi en avons-nous besoin ?

Nous connaissons tous l’écran et les écrans suivants :

La technologie derrière eux s’appelle SSO (Single Sign On). Comme son nom l’indique, SSO est une méthode d’authentification qui permet à l’utilisateur de se connecter une seule fois (c’est-à-dire en saisissant son mot de passe) et de se connecter à plusieurs applications.

Cette méthode d’authentification est très courante pour les individus (c’est-à-dire, se connecter à un compte Google) et les organisations de toute taille (c’est-à-dire, se connecter à GitHub ou Jira à l’aide du déploiement Okta de votre organisation). Pour les utilisateurs individuels, il présente l’avantage de la commodité – les utilisateurs n’ont besoin de se connecter qu’une seule fois et ils n’ont besoin de se souvenir que d’un ensemble d’informations d’identification.

Pour les organisations, en particulier les administrateurs informatiques, le SSO a l’avantage de permettre un contrôle central de la méthode d’authentification. Par exemple, ils peuvent activer l’authentification à deux facteurs, ajouter des exigences sur la force du mot de passe ou utiliser une carte à puce pour se connecter. Les organisations déployant SSO peuvent également bénéficier d’un magasin d’utilisateurs géré de manière centralisée ; par exemple, lorsqu’un employé quitte l’organisation, une seule identité doit être supprimée.

Dans les exemples ci-dessus, l’application utilisée pour se connecter et le service d’authentification sont développés indépendamment. Pour que cela fonctionne, les deux parties doivent avoir une méthode de communication convenue (un protocole). Les applications qui souhaitent bénéficier du SSO, ainsi que des services d’authentification SSO, mettront alors en œuvre leur côté de ce protocole.

Comment sont construits les systèmes SSO

Un système SSO se compose de deux types de parties :

• SP (fournisseur de services) — L’application que l’utilisateur essaie d’approcher. Il existe généralement plusieurs fournisseurs de services dans un écosystème SSO.

• IDP (fournisseur d’identité) — Un système qui authentifie les utilisateurs, gère les sessions de connexion des utilisateurs et est capable de relayer les informations sur l’identité et les sessions des utilisateurs aux SP. En termes simples, un IDP propose l’authentification des utilisateurs en tant que service, c’est-à-dire Okta, Azure Active Directory, Google, etc.

Un exemple simple de SSO est un utilisateur qui navigue sur eBay (SP) et qui est invité à s’authentifier via son compte Google (IDP) lors de la connexion.

Étant donné que le SP autorise l’accès à des ressources potentiellement sensibles en fonction des informations qu’il reçoit de l’IDP, il doit faire confiance à l’IDP. Le SP a besoin d’un moyen de limiter les IDP avec lesquels il est prêt à travailler pour garantir l’authenticité des informations qu’il reçoit. Cette relation de confiance est généralement basée sur des signatures numériques émises par l’IDP et vérifiées par le SP, souvent à l’aide d’un certificat PKI. Peu importe la signification utilisée tant que le SP peut être certain que les données sont reçues de l’IDP.

Outre l’utilisation de signatures numériques pour garantir l’intégrité des messages, d’autres mécanismes sont utilisés pour sécuriser les protocoles SSO, tels que le nonce pour empêcher les attaques par relecture et limiter la durée de validité des messages.

Les informations que le PS reçoit finalement de l’IDP consistent généralement en un ensemble de demandes. Une revendication est simplement une déclaration indiquant qu’un utilisateur possède un attribut donné. Il peut s’agir du nom d’utilisateur, de l’adresse e-mail, des groupes auxquels il appartient, etc. Les revendications peuvent également faire référence au processus d’authentification lui-même, par exemple quand l’identité de l’utilisateur a été vérifiée pour la dernière fois et comment. Au minimum, l’ensemble de revendications doit inclure une revendication avec un identifiant unique de l’utilisateur.

Après avoir passé en revue les exigences fondamentales d’un système SSO, nous pouvons maintenant parler d’un protocole SSO abstrait. Un processus d’authentification SSO peut être mis en œuvre avec les étapes suivantes :

1. Un utilisateur accède à une application à laquelle il souhaite accéder (le SP).

2. Le SP identifie qu’il doit établir l’identité de l’utilisateur. Il redirige ensuite l’utilisateur vers un IDP préalablement configuré au sein du SP.

3. L’IDP peut soit utiliser une session d’authentification précédemment établie, soit authentifier l’utilisateur si une telle session n’existe pas ou a expiré.

4. Une fois que l’IDP est parvenu à une conclusion quant à savoir s’il existe un utilisateur authentifié avec succès, il redirige l’utilisateur vers le SP via son navigateur tout en transmettant (dans le cadre de la réponse de redirection) des informations sur l’utilisateur ou une sorte de descripteur qui permettrait au SP pour en récupérer un en toute sécurité.

5. Le SP valide le résultat de l’authentification en fonction de la relation de confiance qu’il entretient avec l’IDP.

6. Accès accordé (ou refusé). À ce stade, le SP peut utiliser les informations qu’il a obtenues de l’IDP (les demandes) à des fins supplémentaires. Par exemple, l’autorisation (utilisez les revendications pour décider des rôles et des autorisations).

Le protocole ci-dessus décrit un processus d’authentification initié par le SP (SP initié). Il est également possible d’avoir une variante de ce processus, où l’authentification est initiée par l’IDP (IDP initié). IDP initié signifie qu’une fois que l’utilisateur s’est connecté une fois, il aura accès à un portail, où il aura un menu d’applications auxquelles se connecter. En sélectionnant une application, l’utilisateur sera à l’étape 4 du protocole ci-dessus – il sera redirigé vers le SP avec la réponse d’authentification. Ensuite, il ne reste plus qu’aux étapes 5 et 6. Le SP devra valider les résultats de l’authentification et l’utilisateur pourra se voir accorder l’accès.

Approches d’autorisation avec connexion SSO

Comme mentionné ci-dessus, la réponse de l’IDP inclut diverses revendications concernant l’identité de l’utilisateur connecté et le processus d’authentification lui-même. Ces revendications peuvent inclure des détails qui peuvent être utilisés par le SP pour autoriser l’utilisateur à effectuer des opérations spécifiques au sein de l’application.

Ces détails peuvent inclure des groupes auxquels l’utilisateur appartient, des rôles ou des privilèges spécifiques. Le SP peut utiliser ces informations à des fins d’autorisation en les mappant à des autorisations au sein de l’application. Lors de la configuration de SSO, côté IDP, l’organisation peut choisir les informations à envoyer dans le cadre de la réponse d’authentification (par exemple, une organisation peut décider d’inclure l’appartenance de l’utilisateur à des groupes spécifiques), et côté SP, l’organisation créera le mappage aux autorisations (poursuivant le même exemple, en mappant les groupes aux autorisations autorisées). Le mappage des autorisations peut être effectué sur un niveau d’accès simple (lecture/édition/administration) ou une approche complète basée sur ACL (le groupe X a l’autorisation de voir uniquement un ensemble spécifique de données, etc.)

Un avantage significatif de l’utilisation de l’une des approches d’autorisation ci-dessus est que l’organisation peut obtenir un contrôle centralisé de l’autorisation sur différents SP. Par exemple, une organisation qui utilise un IDP, comme AD ou Okta, permet aux administrateurs de revoir ou de modifier l’accès à tous les SP utilisés par l’organisation en modifiant l’affectation de groupe de l’utilisateur dans l’IDP.

SAML et OIDC

Le protocole abstrait décrit ci-dessus est généralement réalisé en utilisant l’une des deux normes suivantes : SAML et OIDC, que l’IDP utilise comme base pour la gestion de l’identité. Un IDP peut être basé sur l’un d’entre eux, mais certains IDP prennent en charge les deux, il est donc utile de les comprendre tous les deux.

SAML est un protocole basé sur XML pour échanger des informations de sécurité. Il est ancien, mature et couramment déployé dans les entreprises. Dans SAML, la confiance SP-IDP est établie à l’aide de signatures numériques basées sur la norme XML Signature.

OIDC signifie « OpenID Connect ». Il s’agit d’un protocole nouveau et évolutif construit à partir du protocole OAuth 2.0 – un cadre plus général pour les protocoles d’autorisation ouverts. OIDC utilise une communication backend à backend et des jetons JWT signés pour établir la confiance.

Ne lancez pas votre propre implémentation SSO

Lors de la mise en œuvre d’un SP, nous devons décider comment mettre en œuvre le support SSO. Après avoir décidé à quels IDP nous souhaitons nous connecter, nous devrons décider quels protocoles prendre en charge et implémenter dans notre application.

La mise en œuvre correcte de la prise en charge du protocole SSO est une tâche complexe – chaque protocole d’authentification se compose de nombreux petits détails, et en manquer un seul peut suffire à introduire une vulnérabilité de sécurité dans l’application. Avoir une application sécurisée est un élément important pour assurer son succès, car il est difficile de gagner la confiance des clients et très facile de la perdre.

De plus, les meilleures pratiques et les détails de mise en œuvre peuvent changer et évoluer au fil du temps, notamment pour des raisons de sécurité. Cela signifie qu’il y a des coûts de maintenance cachés dans la mise en œuvre des protocoles SSO.

La complexité intrinsèque de la mise en œuvre, ainsi que l’impact potentiel désastreux que les erreurs peuvent avoir, suggèrent que le déploiement de votre propre implémentation SSO n’est souvent pas la meilleure idée, tout comme nous optons généralement pour des implémentations tierces de normes de chiffrement. Ceci est encore amplifié par le fait que la prise en charge de plusieurs protocoles est une pratique courante, ce qui signifie que les coûts et les risques sont multipliés.

Heureusement, avec la variété d’intergiciels tiers qui existent sur le marché, il est rarement nécessaire de déployer votre propre solution pour SSO. En connectant le middleware à votre infrastructure de serveur Web, vous pouvez facilement bénéficier de l’interopérabilité SSO tout en réduisant les coûts associés à sa mise en œuvre.

Néanmoins, l’utilisation d’un middleware SSO tiers n’est en aucun cas une garantie automatique que votre implémentation d’authentification est sécurisée. Des précautions doivent être prises pour intégrer et configurer ces solutions en toute sécurité, et pour ce faire, une compréhension fondamentale des protocoles est souhaitable.