Le WS-Trust est un standard OASIS qui impose aux clients et aux fournisseurs d’un service web d’interagir avec le STS (service de jeton de sécurité) pour délivrer, renouveler et valider des jetons de sécurité afin qu’une connexion de confiance soit établie. Cet échange peut avoir lieu entre divers terminaux web, API ou applications par le biais de simples messages SOAP (simple object access protocol). Si l’entité réceptrice valide avec succès le jeton de sécurité provenant de l’entité demandeuse, la connexion est établie. Si elle n’y parvient pas, la demande est refusée.
Un standard web OASIS
« Le but du WS-Trust est de permettre aux applications de construire des échanges de messages [SOAP] de confiance. Cette confiance est représentée par l’échange et la négociation de jetons de sécurité. Cette spécification procure une manière de délivrer, de renouveler et de valider ces jetons de sécurité sans dépendre d’un protocole en particulier ». 1
Dans un service web qui a recours au WS-Trust, le STS est utilisé par les deux côtés pour finaliser le processus d’authentification.
Par exemple, lorsqu’un client souhaite accéder au service, il envoie un message au serveur qui contient un jeton avec des données XML qui l’identifie. Protégé par un chiffrement fort, le jeton contient également des informations sur sa longévité et sa propriété. Lorsque le serveur reçoit le message du client, le serveur même n’authentifie pas l’identité du client en la comparant aux données se trouvant dans sa base de données. Au lieu de cela, il envoie la demande au STS qui évaluera et validera la demande. Lorsque toute cette communication a eu lieu, le client peut présenter le jeton au serveur pour y accéder.
Le concept de traduction universelle de jeton universel et d’un STS qui trouve son origine dans des services web. Très tôt, le manque de méthode standard pour communiquer des identités d’utilisateurs a empêché l’adoption à grande échelle des applications de services web dans les entreprises. Des standards tels que WS-Security et WS-Trust ont émergé dans le monde du protocole SOAP (Simple Object Access Protocol) pour permettre aux services web de partager des identités utilisateur en incorporant des jetons de sécurité standard dans les messages SOAP.
Alors que WS-Trust envisageait que le traitement des jetons aurait lieu en deux phases auprès du client et du fournisseur du service web, le STS sous-jacent ne connaît pas cette restriction. De ce fait, les organisations plus grandes ayant de multiples domaines de sécurité ont reconnu la valeur du STS en tant que « traducteur universel de jeton » pouvant convertir n’importe quel type de jeton de sécurité en tout autre type de jeton de sécurité, même si aucun service web n’est utilisé.
Le standard WS-Trust spécifie que le STS (service de jeton de sécurité) peut être utilisé à la fois par les clients et les fournisseurs d’un service web pour réaliser des opérations sur des jetons de sécurité standard. Du côté du client du service web, qui peut êtrer une application web ou une application bureautique, le STS convertit n’importe quel jeton de sécurité utilisé localement en jeton de sécurité SAML (security assertion markup language) standard contenant l’identité de l’utilisateur, qui est partagé avec le fournisseur des services web. Du côté du fournisseur de service web, le STS valide les jetons de sécurité entrants et peut générer un nouveau jeton local qui sera consommé par d’autres applications.
Le processus commence lorsque le demandeur demande au fournisseur de service ses politiques de sécurité et les compare à ses propres exigences pour voir s’il a les jetons de sécurité nécessaires pour accéder au fournisseur de service. Ce service peut être attaché à un équipement électronique qui communique avec le client par le biais d’Internet, ou il peut se trouver sur un ordinateur qui reçoit la demande à un port particulier du réseau.
Si le demandeur n’a pas de jeton viable à disposition, il peut en demander un au STS. De cette manière, le STS agit comme un fournisseur d’identité pour le demandeur car il délivre et renouvelle des jetons à des fins d’authentification.
Lorsque le fournisseur reçoit le jeton de la part du client, son STS est utilisé pour valider ou rejeter le jeton.
Si le jeton est accepté par le fournisseur, une connexion est alors établie. S’il n’est pas accepté, l’échange de messages n’a pas lieu.
Ressources annexes
Lancez-vous dès Aujourd'hui
Découvrez comment Ping peut vous aider à protéger vos employés et améliorer l'expérience de vos clients dans un monde digital en constante évolution.
Démonstration Gratuite