Vue d’ensemble de la sécurité

L’infrastructure de sécurité dans l’API des services web Windows (WWSAPI) fournit :

• Intégrité des messages, confidentialité, détection de relecture et authentification du serveur à l’aide de la sécurité du transport.
• Authentification du client, telle que la validation de jeton de sécurité, les vérifications d’approbation et de révocation des certificats, etc. à l’aide de la sécurité des messages SOAP ou de la sécurité du transport.

Modèle de programmation de sécurité

La sécurité est associée aux canaux de communication. La sécurisation d’un canal se compose des étapes suivantes.

• Créez et initialisez une ou plusieurs liaisons de sécurité adaptées aux exigences de sécurité de l’application.
• Créez une description de sécurité contenant ces liaisons de sécurité.
• Créez un canal ou un proxy de service (côté client), ou créez un écouteur ou un hôte de service (côté serveur) en transmettant cette description de sécurité.
• Effectuez les étapes normales de programmation de canal : Ouvrir, Accepter, Envoyer, Recevoir, Fermer, etc.

Les messages envoyés et reçus sur le canal sont automatiquement sécurisés par le runtime en fonction de la description de sécurité fournie. Si vous le souhaitez, ces étapes peuvent être affinées en spécifiant un ou plusieurs paramètres de sécurité à l’échelle du canal dans la description de la sécurité ou des paramètres de sécurité au niveau de la liaison dans une liaison de sécurité.

Toute autorisation requise des identités de l’expéditeur doit être effectuée par l’application à l’aide des résultats du traitement de la sécurité joints à chaque message reçu. Les étapes d’autorisation ne sont pas spécifiées dans la description de sécurité et ne sont pas effectuées automatiquement par le runtime.

Les erreurs dans la description de sécurité, telles que les liaisons non prises en charge, les propriétés/champs inapplicables, l’absence de propriétés/champs obligatoires ou des valeurs de propriété/champ non valides, entraînent l’échec de la création du canal ou de l’écouteur.

Sélection des liaisons de sécurité

Lors de la conception de la sécurité d’une application, la principale décision consiste à sélectionner les liaisons de sécurité à inclure dans la description de sécurité. Voici quelques instructions pour choisir des liaisons de sécurité adaptées au scénario de sécurité d’une application. Une heuristique utile consiste à commencer par comprendre quels types d’informations d’identification de sécurité (tels que les certificats X.509, les noms d’utilisateur/mots de passe de domaine Windows, le nom d’utilisateur/les mots de passe définis par l’application) seront disponibles pour l’application, puis pour choisir une liaison de sécurité pouvant utiliser ce type d’informations d’identification.

• La sécurité du transport, où la sécurité est appliquée au niveau du flux d’octets de transport (sous les limites des messages SOAP), est la première option à prendre en compte.

  • Pour les scénarios Internet et pour les scénarios intranet où un certificat X.509 peut être déployé sur le serveur, l’application peut utiliser WS_SSL_TRANSPORT_SECURITY_BINDING. L’exemple suivant illustre cette option. Client : HttpClientWithSslExample Server : HttpServerWithSslExample.

    Si l’authentification du client via l’authentification d’en-tête HTTP est souhaitée, une WS_HTTP_HEADER_AUTH_SECURITY_BINDING peut être ajoutée pour fournir cette fonctionnalité.

  • Pour les scénarios Intranet où les protocoles d’authentification intégrée Windows tels que Kerberos, NTLM et SPNEGO sont appropriés, l’application peut utiliser WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING. L’exemple suivant illustre cette option : Client : RequestReplyTcpClientWithWindowsTransportSecurityExample Server : RequestReplyTcpServerWithWindowsTransportSecurityExample.

    Client sur des canaux nommés : RequestReplyNamedPipesClientWithWindowsTransportSecurityExample

    Serveur sur des canaux nommés : RequestReplyNamedPipesServerWithWindowsTransportSecurityExample

  • Pour les scénarios d’ordinateur local où les protocoles d’authentification intégrée Windows tels que Kerberos, NTLM et SPNEGO sont appropriés, l’application peut utiliser WS_TCP_SSPI_TRANSPORT_SECURITY_BINDING ou WS_NAMEDPIPE_SSPI_TRANSPORT_SECURITY_BINDING. LeWS_NAMEDPIPE_CHANNEL_BINDING est préférable dans ces scénarios, car il garantit que le trafic ne quittera pas l’ordinateur (il s’agit de la propriété de WS_NAMEDPIPE_CHANNEL_BINDING).

• La sécurité en mode mixte, où la sécurité de transport protège la connexion et où un en-tête WS-Security dans le message SOAP fournit l’authentification du client, est l’option suivante à prendre en compte. Les liaisons suivantes sont utilisées conjointement avec l’une des liaisons de sécurité de transport décrites dans la section précédente.

  • Lorsque le client est authentifié par une paire nom d’utilisateur/mot de passe au niveau de l’application, l’application peut utiliser un WS_USERNAME_MESSAGE_SECURITY_BINDING pour fournir les données d’authentification. Les exemples suivants illustrent l’utilisation de cette liaison conjointement avec un WS_SSL_TRANSPORT_SECURITY_BINDING :

    • Client : HttpClientWithUsernameOverSslExample
    • Serveur : HttpServerWithUsernameOverSslExample

  • Lorsque le client est authentifié par un ticket Kerberos, l’application peut utiliser un WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING pour fournir les données d’authentification.

  • Lors de l’utilisation d’un contexte de sécurité, le client établit d’abord un contexte de sécurité avec le serveur, puis utilise ce contexte pour authentifier les messages. Pour activer cette fonctionnalité, la description de sécurité doit contenir un WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING. Une fois établis, les contextes de sécurité peuvent être transmis au moyen de jetons légers, ce qui évite d’avoir à envoyer les informations d’identification client potentiellement volumineuses et coûteuses en calcul avec chaque message.

  • Dans un scénario de sécurité fédérée , le client obtient d’abord un jeton de sécurité émis par un service de jeton de sécurité (STS), puis présente le jeton émis à un service. Côté client : pour obtenir le jeton de sécurité du STS, l’application peut utiliser WsRequestSecurityToken. L’application peut également utiliser une bibliothèque de fournisseur de jetons de sécurité côté client, telle que CardSpace ou LiveID, puis utiliser leur sortie pour créer localement un jeton de sécurité à l’aide de WsCreateXmlSecurityToken. Dans les deux cas, une fois le jeton de sécurité disponible pour le client, il peut être présenté au service à l’aide d’une description de sécurité contenant un WS_XML_TOKEN_MESSAGE_SECURITY_BINDING. Côté serveur : si le jeton de sécurité émis par le STS est un jeton SAML, le serveur peut utiliser une description de sécurité avec un WS_SAML_MESSAGE_SECURITY_BINDING.

    Notes

    Windows 7 et Windows Server 2008 R2 : WWSAPI prend uniquement en charge Ws-Trust et Ws-SecureConversation tels que définis par le profil de sécurité des services Web légers (LWSSP). Pour plus d’informations sur l’implémentation de Microsoft, consultez la section Syntaxe message de LWSSP.

     

• La dernière option à prendre en compte est l’utilisation de liaisons d’authentification sans utiliser une liaison de protection telle que WS_SSL_TRANSPORT_SECURITY_BINDING. Cela entraîne la transmission des informations d’identification en texte clair et peut avoir des implications sur la sécurité. L’utilisation de cette option doit être soigneusement évaluée pour s’assurer qu’il n’y a pas de vulnérabilités en conséquence. Un exemple d’utilisation potentielle est l’échange de messages entre serveurs principaux sur un réseau privé sécurisé. Les configurations suivantes prennent en charge cette option.

  • WS_HTTP_HEADER_AUTH_SECURITY_BINDING prend en charge cette option dans toutes les configurations.
  • WS_USERNAME_MESSAGE_SECURITY_BINDING prend en charge cette option sur le serveur lors de l’utilisation de HTTP comme transport.
  • WS_KERBEROS_APREQ_MESSAGE_SECURITY_BINDING prend en charge cette option sur le serveur lors de l’utilisation de HTTP comme transport.
  • WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING prend en charge cette option sur le serveur lors de l’utilisation de HTTP comme transport.
  • WS_SAML_MESSAGE_SECURITY_BINDING prend en charge cette option sur le serveur lors de l’utilisation de HTTP comme transport.

  L’activation de cette option nécessite de définir explicitement le WS_PROTECTION_LEVEL sur une valeur autre que WS_PROTECTION_LEVEL_SIGN_AND_ENCRYPT.

Canaux et sécurité

Comme indiqué ci-dessus, la sécurité est limitée aux canaux. En outre, les opérations de canal sont mappées aux étapes de sécurité de manière cohérente sur toutes les liaisons de sécurité.

• Création de canal : l’ensemble des liaisons de sécurité spécifiées dans la description de sécurité est validé et reste fixe pour le canal par la suite. La forme de la pile de canaux, y compris les canaux latéraux à utiliser pour les négociations basées sur WS-Trust, est également déterminée.
• Canal ouvert : toutes les informations d’identification fournies dans le cadre des liaisons de sécurité sont chargées et les sessions de sécurité sont établies. En général, un canal ouvert contient l’état de sécurité « live ». L’ouverture d’un canal client spécifie également l’adresse de point de terminaison du serveur sur laquelle l’authentification du serveur sera effectuée par le runtime.
• Entre l’ouverture et la fermeture du canal : les messages peuvent être envoyés et reçus en toute sécurité pendant cette phase.
• Envoi de messages : les jetons de contexte de sécurité sont obtenus ou renouvelés en fonction des besoins et la sécurité est appliquée à chaque message transmis en fonction de la description de la sécurité. Les erreurs rencontrées lors de l’application de la sécurité sont retournées à l’application en tant qu’erreurs d’envoi.
• Réception du message : la sécurité est vérifiée sur chaque message reçu en fonction de la description de la sécurité. Toutes les erreurs de vérification de la sécurité des messages sont retournées à l’application en tant qu’erreurs de réception. Ces erreurs par message n’affectent pas l’état du canal ni les réceptions suivantes. L’application peut ignorer un échec de réception et redémarrer une réception pour un autre message.
• Abandon du canal : le canal peut être abandonné à tout moment pour arrêter toutes les E/S sur le canal. Lors de l’abandon, le canal passe à l’état défectueux et n’autorise plus d’envois ou de réceptions. Toutefois, le canal peut conserver un état de sécurité « en direct », de sorte qu’une fermeture de canal ultérieure sera nécessaire pour supprimer tout l’état proprement.
• Fermeture du canal : l’état de sécurité créé à l’ouverture est supprimé et les sessions sont détruites. Les jetons de contexte de sécurité sont annulés. La pile de canaux reste, mais ne contient pas d’état de sécurité « actif » ni d’informations d’identification chargées.
• Canal libre : la pile de canaux créée lors de la création, ainsi que toutes les ressources de sécurité, sont libérées.

API Sécurité

La documentation de l’API pour la sécurité est regroupée dans les rubriques suivantes.

• Description de la sécurité
  • Paramètres du canal de sécurité
  • Liaisons de sécurité
    • Informations d'identification de sécurité
    • Paramètres de liaison de sécurité
• Fédération
• Contexte de sécurité
• Identité du point de terminaison
• Résultats du traitement de la sécurité

Sécurité

Lors de l’utilisation du API de sécurité WWSAPI, les applications sont confrontées à plusieurs risques de sécurité :

Mauvaise configuration accidentelle

WWSAPI prend en charge une gamme d’options de configuration liées à la sécurité. Consultez l’exemple WS_SECURITY_BINDING_PROPERTY_ID. Certaines de ces options, telles que WS_SECURITY_BINDING_PROPERTY_ALLOW_ANONYMOUS_CLIENTS permettent à l’application de réduire le niveau de sécurité par défaut fourni par les différentes liaisons de sécurité. L’utilisation de telles options doit être soigneusement évaluée pour s’assurer qu’il n’y a pas de vecteurs d’attaque résultants.

En outre, comme décrit ci-dessus, WWSAPI permet à une application de désactiver délibérément certaines étapes requises pour sécuriser entièrement un échange de messages, telles que l’autorisation de désactiver le chiffrement même si les informations d’identification de sécurité sont transmises. Cela permet d’activer certains scénarios spécifiques et ne doit pas être utilisé pour la communication générale. La WS_PROTECTION_LEVEL doit être spécifiquement abaissée pour activer ce scénario, et les applications ne doivent pas modifier cette valeur sauf si cela est absolument nécessaire, car cela désactive de nombreuses vérifications conçues pour garantir une configuration sécurisée.

Stockage d’informations confidentielles en mémoire

Les informations confidentielles, telles que les mots de passe, qui sont stockées en mémoire, sont vulnérables à l’extraction par un attaquant privilégié au moyen, par exemple, du fichier de page. WWSAPI effectue une copie des informations d’identification fournies et chiffre cette copie, en laissant les données d’origine non protégées. Il incombe à l’application de protéger le instance d’origine. En outre, la copie chiffrée est brièvement déchiffrée lors de son utilisation, ce qui ouvre une fenêtre pour l’extraire.

Déni de service

Le traitement de la sécurité peut consommer des ressources importantes. Chaque liaison de sécurité supplémentaire augmente ces coûts. WWSAPI interrompt le traitement de la sécurité dès qu’un échec de vérification de la sécurité est rencontré, mais certaines vérifications telles que les décisions d’autorisation peuvent ne pas avoir lieu tant qu’un travail important n’a pas été effectué.

Lorsqu’un message est traité sur le serveur, l’état de sécurité est stocké sur le tas de messages. L’application peut limiter la consommation de mémoire pendant le traitement de la sécurité en réduisant la taille de ce tas via WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. En outre, certaines liaisons de sécurité telles que la WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING peuvent amener le serveur à allouer des ressources pour le compte du client. Les limites de ces ressources peuvent être configurées au moyen des valeurs WS_SECURITY_BINDING_PROPERTY_ID suivantes :

• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_PENDING_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_MAX_ACTIVE_CONTEXTS
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_RENEWAL_INTERVAL
• WS_SECURITY_BINDING_PROPERTY_SECURITY_CONTEXT_ROLLOVER_INTERVAL

La définition de ces limites sur des valeurs faibles réduit la consommation maximale de mémoire, mais peut entraîner le rejet des clients légitimes lorsque le quota est atteint.