Pensez a préparer votre certification Microsoft
Pour commencer je vous est préparer un petit parcours a suivre
Afin d’avoir un MCSD vous devez obtenir 5 examens :
1 examen dans la catégorie Architecture de solutions
70-300 - Analyse des besoins et définition des solutions avec Microsoft .NET
1 examen dans la catégorie Développement d'applications Web,
70-305 - Développement et mise en œuvre d'applications Web avec Microsoft Visual
Basic .NET et Microsoft Visual Studio .NET
Ou bien pour ceux qui préféré le C# comme moi
70-315 - Développement et mise en œuvre d'applications Web avec Microsoft Visual C# .NET
et Microsoft Visual Studio .NET
1 examen dans la catégorie Développement d'applications Windows,
70-306 - Développement et mise en œuvre d'applications Windows avec Microsoft Visual
Basic .NET et Microsoft Visual Studio .NET
70-316 - Développement et mise en œuvre d'applications Windows avec Microsoft Visual
C# .NET et Microsoft Visual Studio .NET
1 examen dans la catégorie Développement de Services Web,
70-310 - Développement de services Web XML et de composants serveur via Microsoft Visual
Basic .NET et l'environnement Microsoft .NET Framework
70-320 - Développement de services Web XML et de composants serveur via Microsoft Visual
C# .NET et l'environnement Microsoft .NET Framework
1 examen à choisir dans la liste des Examens complémentaires
70-229 - Conception et implémentation de bases de données avec Microsoft SQL Server 2000
Édition Entreprise
70-230 - Conception et implémentation de solutions avec Microsoft BizTalk Server 2000,
Édition Entreprise
70-234 - Conception et implémentation de solutions avec Microsoft Commerce Server 2000
70-330 : Implémentation de la sécurité dans vos applications avec Microsoft Visual Basic .NET
70-340 : Implémentation de la sécurité dans vos applications avec Microsoft Visual C# .NET
Et avant de passer vous exams penser bien a bien vous préparez et n’oubliez pas de simuler des exams soit sur net ou bien avec des logiciel dédié pour ça
Et bon courage les amis.
samedi, mai 27, 2006
Intégration du Common Language Runtime à SQL Server 2005
Intégration du Common Language Runtime à SQL Server 2005
Les développeurs de base de données implémentent souvent une logique de programmation dans les bases de données à l'aide de modules de code Transact-SQL, tels que des procédures stockées et des fonctions.
Depuis le lancement de .NET Framework, les développeurs d'application ont pu construire des solutions performantes en créant des assemblys managés avec n'importe quel langage de programme .NET.
Dans SQL Server 2005, .NET Framework peut être hébergé dans le serveur de bases de données, ce qui fournit la puissance du code managé à la base de données.
Pour gérer du code managé dans une base de données SQL Server, vous devez créer un assembly .NET. Vous pouvez effectuer cette opération à l'aide de n'importe quel langage de programmation, tel que Visual Basic® ou Visual C#®.
Vous pouvez ensuite importer l'assembly dans la base de données où vous souhaitez l'utiliser.
Après avoir importé l'assembly, vous pouvez créer des objets de base de données, tels que des procédures stockées, des fonctions, des types définis par l'utilisateur et des déclencheurs qui référencent le code managé dans l'assembly.
La possibilité d'utiliser du code managé dans la base de données fournit un certain nombre d'avantages au développeur de base de données. Vous pouvez utiliser le langage de programmation le plus adapté à une tâche particulière.
Vous pouvez profiter de l'environnement d'exécution de code sécurisé de .NET Framework. Vous pouvez utiliser les mêmes outils de développement que ceux utilisés par les développeurs d'applications sur différents niveaux de la solution. Votre code bénéficiera ainsi des performances optimisées et des fonctionnalités d'évolutivité de .NET Framework.
Les développeurs de base de données implémentent souvent une logique de programmation dans les bases de données à l'aide de modules de code Transact-SQL, tels que des procédures stockées et des fonctions.
Depuis le lancement de .NET Framework, les développeurs d'application ont pu construire des solutions performantes en créant des assemblys managés avec n'importe quel langage de programme .NET.
Dans SQL Server 2005, .NET Framework peut être hébergé dans le serveur de bases de données, ce qui fournit la puissance du code managé à la base de données.
Pour gérer du code managé dans une base de données SQL Server, vous devez créer un assembly .NET. Vous pouvez effectuer cette opération à l'aide de n'importe quel langage de programmation, tel que Visual Basic® ou Visual C#®.
Vous pouvez ensuite importer l'assembly dans la base de données où vous souhaitez l'utiliser.
Après avoir importé l'assembly, vous pouvez créer des objets de base de données, tels que des procédures stockées, des fonctions, des types définis par l'utilisateur et des déclencheurs qui référencent le code managé dans l'assembly.
La possibilité d'utiliser du code managé dans la base de données fournit un certain nombre d'avantages au développeur de base de données. Vous pouvez utiliser le langage de programmation le plus adapté à une tâche particulière.
Vous pouvez profiter de l'environnement d'exécution de code sécurisé de .NET Framework. Vous pouvez utiliser les mêmes outils de développement que ceux utilisés par les développeurs d'applications sur différents niveaux de la solution. Votre code bénéficiera ainsi des performances optimisées et des fonctionnalités d'évolutivité de .NET Framework.
Common Language Runtime Microsoft .NET
Les runtimes ne sont pas nouveaux en programmation. De nombreux langages de programmation utilisent des runtimes, y compris Microsoft Visual Basic®, Visual C++®, Visual FoxPro® et JScript®, en plus des langages tiers, tels que SmallTalk, Perl et Java.
Le rôle principal de .NET Framework consiste à mettre à votre disposition un environnement unifié, quels que soient les langages de programmation. Cette particularité est ce qui le différencie réellement des autres runtimes. Cet environnement est également appelé environnement managé.
Lorsqu'un composant s'exécute, le Common Language Runtime est responsable de la gestion de l'espace mémoire, du démarrage et de l'arrêt des threads et des processus et de l'application des paramètres de sécurité. Il doit également s'assurer du respect de toutes les correspondances éventuelles entre le composant et d'autres composants.
Lors du développement, le rôle du runtime est légèrement modifié. Étant donné qu'il automatise de nombreuses fonctionnalités (telles que la gestion de la mémoire), le Common Language Runtime facilite le travail du développeur.
Le Common Language Runtime vérifie notamment l'exactitude du code et la sécurité de type. Le Common Language Runtime réduit de manière significative la quantité de code qu'un développeur doit écrire pour transformer une logique métier en un composant réutilisable.
Le rôle principal de .NET Framework consiste à mettre à votre disposition un environnement unifié, quels que soient les langages de programmation. Cette particularité est ce qui le différencie réellement des autres runtimes. Cet environnement est également appelé environnement managé.
Lorsqu'un composant s'exécute, le Common Language Runtime est responsable de la gestion de l'espace mémoire, du démarrage et de l'arrêt des threads et des processus et de l'application des paramètres de sécurité. Il doit également s'assurer du respect de toutes les correspondances éventuelles entre le composant et d'autres composants.
Lors du développement, le rôle du runtime est légèrement modifié. Étant donné qu'il automatise de nombreuses fonctionnalités (telles que la gestion de la mémoire), le Common Language Runtime facilite le travail du développeur.
Le Common Language Runtime vérifie notamment l'exactitude du code et la sécurité de type. Le Common Language Runtime réduit de manière significative la quantité de code qu'un développeur doit écrire pour transformer une logique métier en un composant réutilisable.
mercredi, mai 24, 2006
Sécurité des services Web XML
Un des sujets fréquemment soulevés lorsqu'il est question des services Web XML est la sécurité.
Les Services Web sont-ils sûrs ?
Compte tenu des nombreux aspects liés à la sécurité, à l'authentification et aux autorisations, à la confidentialité et à l'intégrité des données, et compte tenu du fait que la spécification SOAP ne mentionne pas la sécurité, il est aisé d'imaginer que la réponse à cette question est "non" ! Pourtant, examinons de plus près les Services Web de Microsoft®. Actuellement, la création de Services Web sécurisés n'est pas chose impossible.
Lorsque l'on aborde la question de la sécurité de ces services, il faut examiner les points suivants :
Qu'essayons-nous de réaliser ?
Restreindre l'accès à un service Web XML à des utilisateurs dûment habilités, éviter que les messages ne soient lus par des indésirables, etc.
Comment allons-nous y parvenir ?
Par le Réseau, la couche transport, le système d'exploitation, un service ou une application.
Quel niveau d'interopérabilité recherchons-nous dans le cadre de notre solution ? Un niveau local ou global.
Comment donc sécuriser les Services Web actuellement proposés ? En répondant à ces questions et en appliquant les mêmes techniques que celles que nous employons pour sécuriser n'importe quelle autre application Web, notamment :
Par la sécurisation des connexions
Par l'authentification et l'autorisation des interactions
Comme nous allons le voir, ces techniques offrent des solutions élaborées qu'il est possible de combiner pour optimiser les résultats. Par exemple, il est possible d'utiliser un pare-feu avec un service Web XML afin de limiter l'accès à certaines fonctionnalités (méthodes) en fonction de la nature du client et de stratégies préétablies.
Pour plus de clarté, commençons par examiner chacune des solutions actuellement disponibles pour sécuriser l'infrastructure.
Sécurisation de l'infrastructure
Un service Web XML sûr repose sur une infrastructure sécurisée. Microsoft offre diverses technologies qui, intégrées dans un plan de sécurité global, permettent à une entreprise d'assurer la sécurité de son infrastructure informatique. Le processus de planification relatif à sa mise en œuvre suppose :
Une identification approfondie des risques potentiels liés à l'environnement (virus, pirates, catastrophes naturelles) ;
Une analyse des conséquences d'une violation de la sécurité et des mesures préventives à envisager ;
Une stratégie d'implémentation soigneusement planifiée pour intégrer les mesures de sécurité à tous les niveaux du réseau de l'entreprise, en fonction de l'identification et de l'analyse préalablement réalisées.
Sécurisation des connexions
Une des solutions les plus faciles pour sécuriser des Services Web est d'assurer la fiabilité de la connexion entre le client et le serveur. Pour atteindre cet objectif, plusieurs techniques sont possibles, selon la portée du réseau et le profil d'activité des interactions. Citons, parmi les plus répandues et les plus accessibles, les techniques suivantes : des règles basées sur l'existence d'un pare-feu, le protocole SSL (Secure Sockets Layer) et les réseaux privés virtuels (VPN, Virtual Private Network).
Si vous savez exactement quels ordinateurs doivent accéder à vos Services Web, vous pouvez appliquer des règles de pare-feu afin de limiter l'accès sur la base d'adresses IP connues. Cette technique s'avère utile lorsque vous souhaitez restreindre l'accès aux ordinateurs au sein d'un réseau privé, LAN ou WAN par exemple, et que le contenu des messages n'est pas un secret (par conséquent, pas de cryptage). Les pare-feu tels que ISA Server (Internet Security and Acceleration) de Microsoft offrent éventuellement un ensemble de règles reposant sur des stratégies et permettent de limiter, à des degrés divers, l'accès aux ordinateurs par les clients, en fonction de leur origine ou de leur identité.
Cette solution est par exemple applicable pour que des clients aient accès aux diverses fonctionnalités (méthodes) d'un même service Web XML.
Le protocole SSL (Secure Sockets Layer) quant à lui permet d'établir des connexions sécurisées sur des réseaux non sécurisés (tel qu'Internet). SSL crypte et décrypte les messages qui circulent entre un client et un serveur. En cryptant les données, vous empêchez la lecture des messages pendant leur transfert. SSL crypte un message envoyé par le client puis le transmet au serveur. Lorsque le serveur reçoit le message, SSL le décrypte et vérifie qu'il provient de l'expéditeur correct (ce processus est appelé "authentification"). Le serveur, ou le client et le serveur, peuvent proposer des certificats utilisés dans le cadre de l'authentification pour permettre une identification en plus du cryptage.
Bien que le protocole SSL constitue une solution tout à fait efficace en termes de sécurisation des communications, il pèse sur les performances d'une façon non négligeable. Les Services Web de Microsoft gèrent le protocole SSL intégré aussi bien au niveau du client que du serveur.
Un réseau privé virtuel (VPN) est une extension d'un réseau privé qui assure des connexions sur des réseaux partagés ou publics comme Internet. Via un VPN, vous pouvez envoyer des données d'un ordinateur à un autre sur une connexion sécurisée. Semblable par bien des côtés au protocole SSL, le VPN est une connexion point-à-point à long terme. Aussi exige-t-il une connexion à long terme pour que le gain en terme d'efficacité soit sensible.
Authentification et autorisations
Authentification : L'authentification est le processus qui consiste à vérifier l'identité d'une personne (ou, plus généralement, de "quelque chose"). Cette "personne" ou ce "quelque chose" est l'entité. L'authentification nécessite des preuves, appelées informations d'identification. Par exemple, une application cliente peut fournir un mot de passe comme informations d'identification. Si elle présente des informations correctes, le système suppose qu'elle est bien ce qu'elle prétend être.
Autorisations : Une fois que l'identité de l'entité est authentifiée, des autorisations peuvent être accordées. Pour qu'il y ait accès à un système, les informations concernant l'entité sont comparées avec des informations de contrôle des accès, par exemple avec une liste ACL (Access Control List). Les accès peuvent varier selon les clients. Ainsi, certains clients ont un accès total au service Web XML, alors que d'autres n'ont accès qu'à certaines tâches. Vous pouvez accorder à certains clients un accès complet à l'ensemble des données, à d'autres un accès à un groupe limité de données, ou encore un accès en lecture seule.
Une solution parmi les plus simples pour authentifier les accès à un service Web SML est d'utiliser les fonctionnalités d'authentification du protocole employé pour l'échange des messages. Pour la plupart des Services Web, il s'agit d'exploiter les fonctions d'authentification du protocole HTTP.
Microsoft Internet Information Server (IIS) et ISA Server proposent plusieurs mécanismes d'authentification sur HTTP par le biais de Windows 2000 Server.
De base : Utilisé pour une identification non sécurisée et semi-sécurisée des clients, car le nom d'utilisateur et le mot de passe sont envoyés sous la forme de texte codé base64 (binaire), facile à décoder. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
De base sur SLL : Identique au précédent, sauf que le canal d'échange est crypté, ce qui assure la protection du nom d'utilisateur et du mot de passe. Ce mécanisme est une bonne solution pour Internet ; cependant, l'utilisation du protocole SSL a une incidence non négligeable sur les performances.
Digest : Utilise la technique du hachage pour transmettre les informations d'identification du client de manière sécurisée. Toutefois, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clientes de Services Web. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
Authentification intégrée de Windows : Utile essentiellement dans l'environnement Internet. Utilise NTLM ou Kerberos. Le client doit appartenir au même domaine que le serveur ou à un domaine sécurisé du domaine du serveur. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
Certificats clients sur SSL : Chaque client doit obtenir un certificat. Les certificats sont mappés sur des comptes utilisateur auxquels se réfère IIS pour autoriser l'accès aux Services Web. Il s'agit d'une solution intéressante en environnement Internet, bien que l'usage de certificats numériques ne soit pas très répandu pour le moment. En outre, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clients de Services Web. Disponible pour des connexions SSL, il peut enfin avoir une incidence sur les performances.
Du point de vue du programmeur de Services Web, l'un des avantages offerts par ces mécanismes d'authentification est qu'aucune modification de code n'est nécessaire dans le service Web XML : en effet, IIS et ISA Server effectuent toutes les vérifications d'authentification et d'autorisation par rapport aux listes ACL avant que le service ne soit appelé. Cependant, lors de la mise en œuvre du client, certaines opérations supplémentaires peuvent s'avérer nécessaires. L'application cliente doit répondre aux requêtes du serveur concernant les informations d'authentification.
Il existe d'autres techniques pour mettre en œuvre l'authentification dans les Services Web, notamment le recours à des services externes comme ceux que l'on trouve dans Microsoft® .NET Passport, l'utilisation des fonctionnalités de session de Microsoft ASP.NET, ou la mise en place d'une méthode personnalisée.
Phase suivante : l'interopérabilité
Comme vous le constatez, les techniques standard de sécurisation des applications Web sont applicables seules ou combinées afin d'offrir des Services Web sûrs et fiables. Ces techniques s'inspirent d'une riche expérience et sont tout à fait efficaces. Cependant, elles n'offrent pas de solution intégrée au sein de l'architecture des Services Web. À mesure que le service Web XML augmente en complexité (nécessité de traverser des frontières sécurisées, présence sur plusieurs systèmes ou entreprises, etc.), les programmeurs sont contraints de bâtir des solutions personnalisées qui, bien qu'efficaces, n'offrent pas une véritable interopérabilité.
Pour répondre à ces besoins et accroître l'interopérabilité entre les Services Web, Microsoft et ses partenaires travaillent à la mise au point d'un ensemble d'applications de sécurité qui s'appuient sur le mécanisme d'extensibilité de la norme SOAP pour proposer des fonctionnalités de sécurité optimales, directement intégrées dans les Services Web.
Le langage WS-Security (Web Services Security Language) est au cœur de la solution et améliore les échanges SOAP grâce aux trois fonctionnalités suivantes : transfert des informations d'identification, intégrité des messages, confidentialité des messages. Ces fonctionnalités ne constituent pas en soi une solution de sécurisation complète ; le langage WS-Security est un bloc fonctionnel qui s'utilise conjointement avec l'infrastructure et d'autres protocoles de Services Web pour répondre à diverses exigences en matière de sécurisation des applications. L'architecture Global Web Services de Microsoft englobe le langage WS-Security et des spécifications associées qui fournissent un cadre contribuant à faire évoluer l'infrastructure des Services Web.
Les Services Web sont-ils sûrs ?
Compte tenu des nombreux aspects liés à la sécurité, à l'authentification et aux autorisations, à la confidentialité et à l'intégrité des données, et compte tenu du fait que la spécification SOAP ne mentionne pas la sécurité, il est aisé d'imaginer que la réponse à cette question est "non" ! Pourtant, examinons de plus près les Services Web de Microsoft®. Actuellement, la création de Services Web sécurisés n'est pas chose impossible.
Lorsque l'on aborde la question de la sécurité de ces services, il faut examiner les points suivants :
Qu'essayons-nous de réaliser ?
Restreindre l'accès à un service Web XML à des utilisateurs dûment habilités, éviter que les messages ne soient lus par des indésirables, etc.
Comment allons-nous y parvenir ?
Par le Réseau, la couche transport, le système d'exploitation, un service ou une application.
Quel niveau d'interopérabilité recherchons-nous dans le cadre de notre solution ? Un niveau local ou global.
Comment donc sécuriser les Services Web actuellement proposés ? En répondant à ces questions et en appliquant les mêmes techniques que celles que nous employons pour sécuriser n'importe quelle autre application Web, notamment :
Par la sécurisation des connexions
Par l'authentification et l'autorisation des interactions
Comme nous allons le voir, ces techniques offrent des solutions élaborées qu'il est possible de combiner pour optimiser les résultats. Par exemple, il est possible d'utiliser un pare-feu avec un service Web XML afin de limiter l'accès à certaines fonctionnalités (méthodes) en fonction de la nature du client et de stratégies préétablies.
Pour plus de clarté, commençons par examiner chacune des solutions actuellement disponibles pour sécuriser l'infrastructure.
Sécurisation de l'infrastructure
Un service Web XML sûr repose sur une infrastructure sécurisée. Microsoft offre diverses technologies qui, intégrées dans un plan de sécurité global, permettent à une entreprise d'assurer la sécurité de son infrastructure informatique. Le processus de planification relatif à sa mise en œuvre suppose :
Une identification approfondie des risques potentiels liés à l'environnement (virus, pirates, catastrophes naturelles) ;
Une analyse des conséquences d'une violation de la sécurité et des mesures préventives à envisager ;
Une stratégie d'implémentation soigneusement planifiée pour intégrer les mesures de sécurité à tous les niveaux du réseau de l'entreprise, en fonction de l'identification et de l'analyse préalablement réalisées.
Sécurisation des connexions
Une des solutions les plus faciles pour sécuriser des Services Web est d'assurer la fiabilité de la connexion entre le client et le serveur. Pour atteindre cet objectif, plusieurs techniques sont possibles, selon la portée du réseau et le profil d'activité des interactions. Citons, parmi les plus répandues et les plus accessibles, les techniques suivantes : des règles basées sur l'existence d'un pare-feu, le protocole SSL (Secure Sockets Layer) et les réseaux privés virtuels (VPN, Virtual Private Network).
Si vous savez exactement quels ordinateurs doivent accéder à vos Services Web, vous pouvez appliquer des règles de pare-feu afin de limiter l'accès sur la base d'adresses IP connues. Cette technique s'avère utile lorsque vous souhaitez restreindre l'accès aux ordinateurs au sein d'un réseau privé, LAN ou WAN par exemple, et que le contenu des messages n'est pas un secret (par conséquent, pas de cryptage). Les pare-feu tels que ISA Server (Internet Security and Acceleration) de Microsoft offrent éventuellement un ensemble de règles reposant sur des stratégies et permettent de limiter, à des degrés divers, l'accès aux ordinateurs par les clients, en fonction de leur origine ou de leur identité.
Cette solution est par exemple applicable pour que des clients aient accès aux diverses fonctionnalités (méthodes) d'un même service Web XML.
Le protocole SSL (Secure Sockets Layer) quant à lui permet d'établir des connexions sécurisées sur des réseaux non sécurisés (tel qu'Internet). SSL crypte et décrypte les messages qui circulent entre un client et un serveur. En cryptant les données, vous empêchez la lecture des messages pendant leur transfert. SSL crypte un message envoyé par le client puis le transmet au serveur. Lorsque le serveur reçoit le message, SSL le décrypte et vérifie qu'il provient de l'expéditeur correct (ce processus est appelé "authentification"). Le serveur, ou le client et le serveur, peuvent proposer des certificats utilisés dans le cadre de l'authentification pour permettre une identification en plus du cryptage.
Bien que le protocole SSL constitue une solution tout à fait efficace en termes de sécurisation des communications, il pèse sur les performances d'une façon non négligeable. Les Services Web de Microsoft gèrent le protocole SSL intégré aussi bien au niveau du client que du serveur.
Un réseau privé virtuel (VPN) est une extension d'un réseau privé qui assure des connexions sur des réseaux partagés ou publics comme Internet. Via un VPN, vous pouvez envoyer des données d'un ordinateur à un autre sur une connexion sécurisée. Semblable par bien des côtés au protocole SSL, le VPN est une connexion point-à-point à long terme. Aussi exige-t-il une connexion à long terme pour que le gain en terme d'efficacité soit sensible.
Authentification et autorisations
Authentification : L'authentification est le processus qui consiste à vérifier l'identité d'une personne (ou, plus généralement, de "quelque chose"). Cette "personne" ou ce "quelque chose" est l'entité. L'authentification nécessite des preuves, appelées informations d'identification. Par exemple, une application cliente peut fournir un mot de passe comme informations d'identification. Si elle présente des informations correctes, le système suppose qu'elle est bien ce qu'elle prétend être.
Autorisations : Une fois que l'identité de l'entité est authentifiée, des autorisations peuvent être accordées. Pour qu'il y ait accès à un système, les informations concernant l'entité sont comparées avec des informations de contrôle des accès, par exemple avec une liste ACL (Access Control List). Les accès peuvent varier selon les clients. Ainsi, certains clients ont un accès total au service Web XML, alors que d'autres n'ont accès qu'à certaines tâches. Vous pouvez accorder à certains clients un accès complet à l'ensemble des données, à d'autres un accès à un groupe limité de données, ou encore un accès en lecture seule.
Une solution parmi les plus simples pour authentifier les accès à un service Web SML est d'utiliser les fonctionnalités d'authentification du protocole employé pour l'échange des messages. Pour la plupart des Services Web, il s'agit d'exploiter les fonctions d'authentification du protocole HTTP.
Microsoft Internet Information Server (IIS) et ISA Server proposent plusieurs mécanismes d'authentification sur HTTP par le biais de Windows 2000 Server.
De base : Utilisé pour une identification non sécurisée et semi-sécurisée des clients, car le nom d'utilisateur et le mot de passe sont envoyés sous la forme de texte codé base64 (binaire), facile à décoder. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
De base sur SLL : Identique au précédent, sauf que le canal d'échange est crypté, ce qui assure la protection du nom d'utilisateur et du mot de passe. Ce mécanisme est une bonne solution pour Internet ; cependant, l'utilisation du protocole SSL a une incidence non négligeable sur les performances.
Digest : Utilise la technique du hachage pour transmettre les informations d'identification du client de manière sécurisée. Toutefois, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clientes de Services Web. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
Authentification intégrée de Windows : Utile essentiellement dans l'environnement Internet. Utilise NTLM ou Kerberos. Le client doit appartenir au même domaine que le serveur ou à un domaine sécurisé du domaine du serveur. IIS autorise l'accès au service Web XML si les informations d'identification correspondent à un compte utilisateur valide.
Certificats clients sur SSL : Chaque client doit obtenir un certificat. Les certificats sont mappés sur des comptes utilisateur auxquels se réfère IIS pour autoriser l'accès aux Services Web. Il s'agit d'une solution intéressante en environnement Internet, bien que l'usage de certificats numériques ne soit pas très répandu pour le moment. En outre, ce mécanisme risque de ne pas être largement pris en charge par les outils des développeurs utilisés pour créer des applications clients de Services Web. Disponible pour des connexions SSL, il peut enfin avoir une incidence sur les performances.
Du point de vue du programmeur de Services Web, l'un des avantages offerts par ces mécanismes d'authentification est qu'aucune modification de code n'est nécessaire dans le service Web XML : en effet, IIS et ISA Server effectuent toutes les vérifications d'authentification et d'autorisation par rapport aux listes ACL avant que le service ne soit appelé. Cependant, lors de la mise en œuvre du client, certaines opérations supplémentaires peuvent s'avérer nécessaires. L'application cliente doit répondre aux requêtes du serveur concernant les informations d'authentification.
Il existe d'autres techniques pour mettre en œuvre l'authentification dans les Services Web, notamment le recours à des services externes comme ceux que l'on trouve dans Microsoft® .NET Passport, l'utilisation des fonctionnalités de session de Microsoft ASP.NET, ou la mise en place d'une méthode personnalisée.
Phase suivante : l'interopérabilité
Comme vous le constatez, les techniques standard de sécurisation des applications Web sont applicables seules ou combinées afin d'offrir des Services Web sûrs et fiables. Ces techniques s'inspirent d'une riche expérience et sont tout à fait efficaces. Cependant, elles n'offrent pas de solution intégrée au sein de l'architecture des Services Web. À mesure que le service Web XML augmente en complexité (nécessité de traverser des frontières sécurisées, présence sur plusieurs systèmes ou entreprises, etc.), les programmeurs sont contraints de bâtir des solutions personnalisées qui, bien qu'efficaces, n'offrent pas une véritable interopérabilité.
Pour répondre à ces besoins et accroître l'interopérabilité entre les Services Web, Microsoft et ses partenaires travaillent à la mise au point d'un ensemble d'applications de sécurité qui s'appuient sur le mécanisme d'extensibilité de la norme SOAP pour proposer des fonctionnalités de sécurité optimales, directement intégrées dans les Services Web.
Le langage WS-Security (Web Services Security Language) est au cœur de la solution et améliore les échanges SOAP grâce aux trois fonctionnalités suivantes : transfert des informations d'identification, intégrité des messages, confidentialité des messages. Ces fonctionnalités ne constituent pas en soi une solution de sécurisation complète ; le langage WS-Security est un bloc fonctionnel qui s'utilise conjointement avec l'infrastructure et d'autres protocoles de Services Web pour répondre à diverses exigences en matière de sécurisation des applications. L'architecture Global Web Services de Microsoft englobe le langage WS-Security et des spécifications associées qui fournissent un cadre contribuant à faire évoluer l'infrastructure des Services Web.
samedi, mars 04, 2006
En construction
Ce blog est en construction alors n’hésite pas a laissé des commentaires et des suggestions
Aussi.
Aussi.
Inscription à :
Articles (Atom)
Articles
