Lexique SSO
L’identification : Indication de l’identité d’une chose ou d’une personne. En informatique elle se caractérise le plus souvent par l’utilisation d’une chaîne de caractères ou d’un nombre qui doit pourvoir identifier une entité de manière unique dans un contexte donné (à noter qu’il est compliqué d’obtenir un identifiant unique à portée universelle, même un UUID ne garantit pas de réelle unicité).
L’authentification : Processus de vérification d’une identité. Il peut s’agir par exemple de valider un couple identifiant/mot-de-passe ou l’authenticité d’un site web à l’aide d’un certificat numérique.
Il existe différentes méthodes de vérification de l’authentification :
- la simple : l’authentification ne repose que sur un seul élément ou « facteur » (exemple : l’utilisateur indique son mot de passe)
- la forte : l’authentification repose sur deux facteurs ou plus.
- l’unique : (en anglais Single Sign-On ou SSO) est une méthode permettant à un utilisateur de ne procéder qu’à une seule authentification pour accéder à plusieurs applications informatiques (ou sites internet sécurisés).
L’autorisation : Avec une authentification réussie, un système peut autoriser une personne ou un service à accéder à des ressources. L’autorisation spécifie la politique d’accès aux ressources. Une des politiques les plus répandue de nos jours est le contrôle d’accès basé sur des rôles, en anglais « role-based access control » (RBAC).
Rôles et permissions : Dans un contrôle d’accès basé sur des rôles, un rôle est un ensemble nommé uniquement de permissions concernant un type de ressource. Une permission représente une action possible pour un type de ressource. Il s’agit de l’entité de sécurité de granularité la plus fine. Par exemple pour une ressource de type fichier, il peut exister des permissions de lecture, d’écriture, et de parcours de dossier. Un rôle « lecteur » possèdera des permissions de lecture et de parcours de dossier, et un rôle « éditeur » possèdera les permissions du rôle lecteur auxquelles s’ajoute la permission d’écriture. Un autre exemple serait dans le cas d’un web service, l’utilisation de différentes permissions pour permettre ou interdire l’appel de certaines opérations.
Protocole : Un protocole de communication est un langage de format binaire ou textuel qui permet de définir la structure des messages échangés afin que deux entités puissent se comprendre. La plupart des protocoles communément utilisés sont décrit au travers de RFC (spécifications techniques). A noter que rien n’empêche un protocole d’en inclure un autre, ou de déléguer une partie de ses responsabilités à un autre. Il s’agit d’ailleurs de quelque chose de fréquent au sein de la couche de sécurité (cf. SASL plus bas).
Différentes méthodes d’authentification
Il existe de nombreuses méthodes d’authentification. En fonction des protocoles ou des applications, on pourra authentifier des utilisateurs, des machines ou des services. Ci-dessous une présentation non exhaustive des plus rencontrées en entreprise :
- SASL : Framework d’authentification permettant à des protocoles applicatifs de supporter différents mécanismes d’authentification (potentiellement au travers d’autres protocoles).
- LDAP : Il s’agit d’un protocole applicatif d’annuaire (de ressources). Il supporte une authentification (bind) simple ou complexe via d’autres mécanismes d’authentifications plus avancés au travers de SASL.
Il est notamment utilisé par le service d’annuaire de Microsoft, Active Directory et permet aux utilisateurs d’un domaine de s’authentifier et de démarrer leurs sessions Windows.
- TLS/SSL : TLS est le remplaçant de SSL, il s’agit de protocoles « enveloppe » dont le but est de protéger via chiffrement des communications et donc d’autres protocoles avec une possible authentification de la partie client ou serveur via certificat.
- HTTP : C’est le protocole applicatif utilisé par les navigateurs pour accéder aux ressources du web. Il contient quelques constructions permettant de supporter différents types d’authentification pour les utilisateurs et services/API web :
- Authentification « Basic » : Il s’agit d’envoyer le couple identifiant/mot-de-passe d’un utilisateur ou d’un service codé en base 64 (donc en clair) dans l’entête de la requête.
- Authentification « Digest » : Cette méthode est similaire à celle « Basic » à l’exception que le mot-de-passe n’est pas envoyé en clair, un hash du de ce dernier et différents paramètres sont utilisés pour permettre de valider l’authentification.
- Autres : HTTP est extensible par nature et de nouvelles méthodes d’authentification personnalisables peuvent être ajoutées au travers d’entêtes existantes ou de nouvelles. Un système d’authentification naïf par formulaire peut par exemple être construit autour d’un état en session.
- HTTPS : Le protocole HTTP avec une « enveloppe » TLS ou SSL.
- OIDC : Il s’agit d’un protocole d’authentification décentralisé basé sur OAuth 2.0.
Mettre en place du SSO : OAuth 2.0, SAML et OIDC
Comme vu dans la première section, l’authentification unique, en anglais Single Sign-On ou SSO est une méthode permettant à un utilisateur de ne procéder qu’à une seule authentification pour accéder à plusieurs applications informatiques. La mise en place d’une telle authentification au sein du groupe permettrait de grandement simplifier la vie des utilisateurs de nos applications, mais également de simplifier le partage de nos API.
OAuth, « Open Autorisation » est un protocole libre. Twitter l’invente alors que ses équipes cherchaient à mettre en place l’Open ID et souhaitaient faire de la délégation d’autorisation. La version la plus répandu de nos jours est la version 2.0. Il est principalement utilisé dans un contexte HTTP.
OAuth n’est pas un protocole d’authentification, il ne définit donc pas de méthode de SSO. Il ne s’agit que d’un protocole de délégation d’autorisation : Son but est de permettre d’autoriser un site web, un logiciel ou une application (dit « consommateur ») à utiliser l’API sécurisée d’un autre site web (dit « fournisseur ») pour le compte d’un utilisateur.
Exemple :
Accès aux données Facebook d’un utilisateur pour un site tiers en obtenant un « access token ».
SAML, « Security Assertion Markup Language », en version SAML 2.0 depuis 2005. Il est un standard d’échange d’authentifications et d’autorisations entre plusieurs parties basé sur HTTP au travers d’échanges SOAP. Il s’agit d’un protocole de SSO.
OIDC, « Open ID Connect » est le nom de la troisième version du protocole Open ID. C’est un protocole d’authentification décentralisé basé sur OAuth 2.0. Ce protocole permet de vérifier l’identité d’un utilisateur auprès d’un serveur fournisseur d’identité IDP en anglais (Identity Provider). Il délivre des informations sur cet utilisateur. Des web services REST réalisent ces opérations au travers d’échanges au format JSON. OIDC améliore Open ID notamment avec la standardisation des données obtenues suite à une authentification. Celles-ci sont formalisées dans un jeton d’identité au format JWT (JSON chiffré/signé), qui contient des paramètres obligatoires et non obligatoires. Ces paramètres seront toujours nommés de la même façon quel que soit le partenaire de fédération. OIDC permet donc le SSO au travers de jetons JWT.
Accès aux données Google d’un utilisateur pour un site tiers en obtenant un « ID token » et un « access token » comme pour OAuth 2.0 (compatibilité).
Conclusion
SAML et OIDC sont tous deux des protocoles qui peuvent servir à implémenter du SSO. SAML est un standard plus ancien qu’OIDC, basé sur des échanges XML SOAP plutôt que REST JSON. Le protocole SAML bien que moins à la mode est bien implanté en entreprise. Il permet de contourner plus simplement les problématiques de « cross domain ». OIDC a quant à lui l’avantage d’être compatible OAuth 2.0.
Il existe de nombreuses implémentations pour les protocoles SAML et OIDC. Dans le monde open source, on peut citer Keycloak qui semble devenir la référence. Côté solution Microsoft ADFS, « Active Directory Federation Services » supporte également ces standards.
