Discussion :

[Nanais19]

Bonjour,

Alors voilà, je me triture l'esprit pour essayer de gérer l'authentification à mon web service qui est utilisé dans un site web.

Mon web service utilise l'identification username avec ws-security ce qui implique de devoir compléter à chaque utilisation du web service les informations clientcredentials comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
            Client_WS ws_client = new Client_WS();
            ws_client.ClientCredentials.UserName.UserName = "toto";
            ws_client.ClientCredentials.UserName.Password = "toto";

Toutes les fonctions de mon web service nécessite d'être authentifié car lors de la vérification de login mot de passe, j'attribut un rôle à l'utilisateur qui est utilisé pour vérifier les accès à certaines fonctions.

Jusque là tous va bien mais dans un site web je passe donc par la page d'authentification où l'utilisateur rentre son login et mot de passe donc pas de soucis non plus.

Puis sur les autres pages le web service et aussi utilisé par le site web pour récupérer des informations produits et les modifier.

Donc dans chaque page j'ai besoin de rentrer à nouveau le login et mot de passe de l'utilisateur authentifier, sauf que je n'ai plus les informations car je ne me voit pas stocker ses infos sensibles dans un cookies !!

Le cycle de vie de la page web m'oblige à re-authentifier mon utilisateur à chaque aller retour serveur !

Comment puis je gérer ce problème ? Y a t'il une méthode connu pour palier à ce problème ?

Merci d'avance pour votre aide et surtout n'hésitez pas à poser des questions si je me suis mal exprimé.

[DotNetMatt]

La première solution à laquelle je pense est de crypter le login et le mot de passe. Ainsi tu peux transférer de manière sécurisée ces information, et les utiliser là où tu en auras besoin.

Une autre serait de mettre en oeuvre une solution de Single Sign On (SSO), qui permettrait de ne pas avoir à authentifier à chaque fois l'utilisateur. Un simple transfert de paramètre suffirait, via l'entête HTTP par exemple... Il existe pas mal d'outils de SSO, mais ça peut coûter assez cher. Développer son propre système de SSO est une idée, mais il faut savoir ce que l'on fait car toute la sécurité du système repose dessus.

[Nanais19]

Merci pour ta contribution

La première solution à laquelle je pense est de crypter le login et le mot de passe. Ainsi tu peux transférer de manière sécurisée ces information, et les utiliser là où tu en auras besoin.

C'est aussi ce à quoi j'ai pensé. Seulement où est ce que je stocke ces informations. Dans un cookies sur le client, dans une variable de session, ou j'ai pensé aussi à gérer un fichier xml où j'associe le login et mot de passe crypté avec l'identifiant de session. Quel serait la meilleur des solutions ?

Je me dit que le fichier xml au moins il est sur le server et si les données sont cryptés c'est plus sécurisée comme méthode, non?

Une autre serait de mettre en oeuvre une solution de Single Sign On (SSO), qui permettrait de ne pas avoir à authentifier à chaque fois l'utilisateur. Un simple transfert de paramètre suffirait, via l'entête HTTP par exemple... Il existe pas mal d'outils de SSO, mais ça peut coûter assez cher. Développer son propre système de SSO est une idée, mais il faut savoir ce que l'on fait car toute la sécurité du système repose dessus.

Je ne sait pas si ça en vaut vraiment la peine car c'est que pour gérer l'authentification entre le site web et le web service. Sachant que je veut mettre en place le timeout de la session du site web à 5 minutes, afin qu'il soit obligé de se ré-authentifié au bout de 5 minutes d'inactivité sur le site.

[DotNetMatt]

Pour le stockage des infos cryptées, la session fait l'affaire. Tu y stocke l'info lors du login. Si la session est perdue, l'utilisateur devra s'authentifier de nouveau, donc tu es sûre de toujours avoir les infos dispo.

Sinon je viens de voir cet article qui présente comment utiliser l'ASP.NET Membership Provider. Ca peut être plus simple

[Nanais19]

Mais en utilisant les variables de sessions, les données peuvent être récupéré par quelqu'un qui arriverai à récupérer l'ID de session.

Et même si je crypte les données, rien ne les empêches d'être décrypté par moi ou un utilisateur malveillant, non ?

Je ne me souviens plus exactement des raisons pour lesquels je n'ai pas utilisés l'authentification membership mais j'avais déjà étudié cet éventualités.

[DotNetMatt]

Mais en utilisant les variables de sessions, les données peuvent être récupéré par quelqu'un qui arriverai à récupérer l'ID de session.

Effectivement On peut aussi se faire applatir dans la rue par un buffle au galop échappé d'un cirque.

Et même si je crypte les données, rien ne les empêches d'être décrypté par moi ou un utilisateur malveillant, non ?

Par toi, oui c'est le but ! Par un utilisateur malveillant, oui c'est possible dans l'absolu... Toutefois si tu utilises un cryptage type AES 256 je doute qu'il arrive à décrypter quoi que ce soit

Si tu ne veux pas que ça soit décryptable, tu peux utiliser les Hash (MD5/SHA), ou même mieux les Hashs "salés". Comme ça tu trimbales les hashs et il te suffit de comparer les Hashs des 2 côtés. Si ça match, c'est que c'est le bon utilisateur.

[Nanais19]

Très bien, merci beaucoup. Je pense que je vais procéder comme ça alors.

Je stockerai le mot de passe dans une variable de session une fois celui ci crypté.

Merci pour votre aide.