Tokens : comment authentifier et autoriser des microservices

Authentification et autorisation dans les microservices

L’accès sécurisé aux microservices nécessite une authentification et une autorisation :

• L’authentification permet d’identifier l’utilisateur en déterminant qu’une entité particulière est bien ce qu’elle prétend être.
• L’autorisation contrôle ce que l’utilisateur a le droit de faire en lui affectant des rôles et des classes appropriés.

Munie des outils adéquats, une application peut procéder à l’authentification une seule fois par session, tout en contrôlant quand même les autorisations à chaque passage d’un microservice à un autre.

Pour l’authentification dans les microservices, il faut aller au-delà du système élémentaire de type question-réponse, qui repose uniquement sur la saisie d’un nom d’utilisateur et d’un mot de passe. Le microservice en contact avec les utilisateurs doit effectuer une authentification multifacteur (MFA), en utilisant une application d’authentification distincte sur l’appareil de l’utilisateur ou, éventuellement, un jeton physique tel qu’un token matériel RSA SecurID. Cette authentification effectuée par le microservice exige également un service d’émission de jetons de sécurité (STS, Security Token Service). L’authentification peut également être centralisée par le biais d’une passerelle d’API qui transfère les demandes de connexions aux microservices. Dans ce cas-là, ces composants ne sont pas directement accessibles sans l’API.

Petite histoire de l’authentification à base de tokens par les microservices

Le concept de STS découle de l’architecture orientée services, lorsque WS-Trust est devenu un protocole de sécurité standardisé pour la gestion des tokens. À l’origine, WS-Trust a été conçu autour du protocole SOAP et utilisait des standards tels que SAML pour distribuer les jetons sous la forme de documents XML, appelés également assertions SAML.

L’évolution vers le développement d’applications Web distribuées a amené les équipes informatiques à chercher des tokens de sécurité compatibles avec les formats RESTful et JSON. Le jeton Web JSON et le protocole OAuth 2.0 figurent parmi les outils qui ont été créés pour répondre à ce besoin.

Service d’émission de jetons de sécurité

Le service STS permet aux clients d’obtenir les identifiants dont ils ont besoin pour accéder à plusieurs services qui fonctionnent dans des environnements distribués. Il émet des jetons de sécurité numériques qui sont attribués aux utilisateurs dès le démarrage de leur session et valident en continu leur autorisation pour chacun des services auxquels ils font appel. Il peut également réémettre, échanger et annuler des jetons de sécurité en fonction des besoins.

Le service STS doit se connecter à un répertoire d’utilisateurs d’entreprise, comme Active Directory chez Microsoft, qui contient toutes les informations sur les rôles et les responsabilités de chaque utilisateur. Ce répertoire, et toutes les connexions qu’il reçoit, doivent également être correctement sécurisées pour que les utilisateurs ne puissent pas s’octroyer des autorisations plus élevées simplement en modifiant eux-mêmes les règles. Vous pouvez segmenter les règles d’accès utilisateur en fonction des rôles et des activités. Par exemple, identifiez les personnes qui ont des responsabilités d’administration. Ou limitez les droits d’accès d’un développeur aux services sur lesquels il doit travailler.

La figure 2 montre de manière schématique le fonctionnement de ce système.

Pour commencer, un utilisateur se connecte à une application en donnant ses informations d’authentification dans un système de question-réponse compatible avec l’authentification à facteurs multiples. Ensuite, le STS utilise les informations fournies par l’authentification multifacteur pour déterminer le jeton à attribuer à l’utilisateur au démarrage de la session. L’utilisateur conserve ce token, toujours géré par le STS, pendant toute la durée de la session. Chacun des services auquel il tente d’accéder vérifie cet actif numérique pour autoriser ou refuser cet accès.

Sécurisation de l’accès automatisé

Les contrôles d’autorisation et de sécurité des microservices ne concernent pas tous un utilisateur humain. Des composants automatisés génèrent également des demandes d’accès aux microservices. L’essor de l’Internet des objets, notamment, a entraîné une énorme augmentation de l’utilisation de systèmes automatisés. Ces appareils transmettent leurs propres données via les réseaux et accèdent à un grand nombre de services, soit pour analyser les données, soit pour déclencher certaines fonctions. Un grand nombre de ces activités étant dictées par les événements, elles ne dépendent quasiment jamais d’une intervention humaine.

Les processus d’authentification et d’autorisation des microservices décrits ci-dessus sont également valables dans ces scénarios. Cependant, l’authentification multifacteur ne fonctionne pas pour les composants non humains, qui ne peuvent pas interagir avec les appareils des utilisateurs ou les tokens matériels. Dans de tels cas, il est recommandé d’incorporer aux composants automatisés qui accèdent à vos services, un identifiant unique, par exemple un numéro de série intégré, que le STS peut utiliser pour vérifier les tokens qu’il doit émettre. Certaines technologies, comme OAuth et OpenToken, permettent d’incorporer des identifiants uniques dans ces équipements.