Discussion :

[forinfo]

BONJOUR;
je me demande si vous pouvez m'aider à propos des services web, je vous serez tres reconnaissante.
le probleme est:
je viens de terminer une application web developpée avec c# en asp.net .le but c'etait de la publier sur le reseau local de la société.- maintenant le boss veut que l'application soit accessible de l'exterieur de l'entreprise mais en prenant en considération la sécurité de serveur de base de données de la société. on m'a proposé de penser aux services web. et je suis bloquée à ce stade là. est ce que je suis obligée de developper un service web pour chaque page aspx ou juste la page de demarrage.

pour moi l'utilité des services web est de faire communiquer plusieurs applications entre eux pas la sécurité. et je suis pas sure si les services web sont suffisants pour assurer la sécurité .

[popo]

Tu te fais une fausse idée des web services.
Un web service ne sert pas à faire communiquer plusieurs applications entre elles
Un web service sert à faire communiquer une ou plusieurs applications CLIENTES avec une application SERVEUR.
Cette application serveur peut éventuellement servir d'intermédiaire pour faire communiquer différentes applications clientes.

Pour l'aspect sécurité, le simple fait de passer par un web service ne garantira pas la sécurité.
Pour cela il faut au minimum sécuriser l'accès au web service lui même.
Cette page donne une première idée de ce qu'il est possible de mettre en place
https://docs.microsoft.com/fr-fr/sec...curity/6946659

[Pol63]

https c'est le début de la sécurité, après il faut une application avec login et interdire l'accès aux autres méthodes exposées si on est pas loggé

[forinfo]

https c'est le début de la sécurité, après il faut une application avec login et interdire l'accès aux autres méthodes exposées si on est pas loggé

merci à vous . l'implémentation de https se fait au niveau de serveur de l'application ou bien avant le déploiement de l'application?
merci pour votre réponse

[forinfo]

Tu te fais une fausse idée des web services.
Un web service ne sert pas à faire communiquer plusieurs applications entre elles
Un web service sert à faire communiquer une ou plusieurs applications CLIENTES avec une application SERVEUR.
Cette application serveur peut éventuellement servir d'intermédiaire pour faire communiquer différentes applications clientes.

Pour l'aspect sécurité, le simple fait de passer par un web service ne garantira pas la sécurité.
Pour cela il faut au minimum sécuriser l'accès au web service lui même.
Cette page donne une première idée de ce qu'il est possible de mettre en place
https://docs.microsoft.com/fr-fr/sec...curity/6946659

merci bcp. l'article est très utile. pour mon cas on m'a demandé d'implémenter un service web d'authentification dans la même application, chose que je trouve un peu inutile , qu'est ce que vous en penser?

[popo]

C'est loin d'être inutile.
C'est même la base de la sécurité d'un web service.

L'authentification permet de savoir qui appelle le web service.
Cela peut inclure qu'elle personne appelle le service et/ou quelle application.
Et cela permet de déterminer si ce qui appelle ton service est autorisé à le faire.
Sans cela, tu donnes accès aux données à n'importe qui et n'importe quoi.

Pol63 t'a parlé de login (et par extension, mot de passe).
C'est une possibilité, la plus simple mais la moins robuste car quiconque intercepte les données possède un accès illimité.

Je te suggères une authentification par jeton (genre bearer).
Tu demandes à passer au minimum un clientId et un clientSecret et ton service génère un jeton valable un certain laps de temps.
Ensuite chaque appel aux méthodes devra fournir ce jeton dans l'en-tête authorization.
Cela implique que ta base gère les différents couples clientid/clientsecret et l'associé à un client unique.
Puisque le jeton est valable dans un laps de temps limité, cela limite le laps de temps où quelqu'un pourrait l'intercepter et l'utiliser.
Pour encore plus de sécurité, tu peux éventuellement demander au consommateur de hasher le clientsecret d'une manière que tu auras déterminé.
Comme cela personne ne pourra retrouver ce secret en cas d'interception.
Tout cela est largement documenté sut le net

[forinfo]

Merci @POPO;
en fait j'ai jamais entendu parlé de clientid/clientsecret, je vais chercher un peu sur le net.
pour le service web d'authentification, est ce que je dois créer un service web(je travaille avec asp.net c# ) pour déclarer une méthode simple d'authentification, et par la suite l'appeler dans une page web d'authentification.?
merci pour vos retours.

[popo]

Je trouve que ce blog illustre bien le concept.
https://blogs.infinitesquare.com/pos...on-aspnet-core

Ce code ne doit pas être repris tel quel, il est juste là pour illustrer le concept.
Par exemple, l'email et le password ne doivent JAMAIS être mis en dur dans du code.
On peut par exemple gérer cela dans une base de données (qui n'est pas celle qui contient les données renvoyée par l'API).
Donc une base dédiée et non accessible depuis l'extérieur.

Un email et un password ne sont pas des données fiables (selon moi) car les gens ont tendances à toujours utiliser le même mot de passe.
C'est pour cela que j'ai suggéré clientId et SecretId qui ne sont pas choisis par le consommateur.

[forinfo]

merci pour votre intervention;
la question primordiale dont je n'ai plus la réponse, est comment je peut gérer la sécurité chez le client? en utilisant l'authentification par jeton

[popo]

Il faut bien différencier client et utilisateur.
L'utilisateur est la personne qui utilise ton application.
Le client est le programme qui consomme ton web service.

Donc l'utilisateur utilise l'application et l'application consomme le web service.
Le couple clientId et clientSecret permet d'identifier le client (l'application) et non l'utilisateur.
Mais rien n'empêche, dans la demande de jeton, de passer également des informations qui identifient l'utilisateur.
L'identifiant utilisateur (pas son mot de passe) peut potentiellement être transmis dans le jeton.

Tu peux également te connecter en deux fois.
Un appel a une méthode GetToken renvoyant le jeton utilisant le couple clientId et clientSecret plus un email qui sera transmis dans le jeton.
Une appel a une méthode Connect avec le jeton dans l'en-tête Authorization et un mot de passe Hashé transmis dans le body que tu compares avec le hash stocké en base pour l'utilisateur dont le mail est transmis dans le jeton.

Edit :
En me relisant, je m'aperçois que je dis une bêtise.
Si tu transmet un mot de passe hashé pour le comparer directement avec la valeur du mot de passe hashé en base, c'est comme si tu passais un mot de passe en clair.
Je barre donc cette partie de la phrase.
Si tu veux sécuriser un peu plus la transmission du mot de passe, tu peux éventuellement utiliser le principe de clé publique/clé privée.
Ton mot de passe est transmis crypté, ton service le décrypte, puis le hash et compare ce hash avec le contenu en base.

[forinfo]

merci bcp pour vos retours.
je commence à me débrouiller avec les webservice. j'ai ajouté un web service à mon application, je suis en train de créer toutes les méthodes de mon projet dans la même page.asmx, coté programmation c'est facile, mais c'est assez long vue le nombre énorme de méthodes que je dois créer. si j'ai bien compris je dois par la suite sécuriser ce web service, puisque un web service n'est pas suffisant pour assurer la sécurité. mais je n'ai aucune idée par quoi commencer , et ce que je dois écrire un code? si oui, où ?. pour la chaine de connexion appelée dans le web service, je dois la garder dans le web.config? une dernière question, est ce que je dois créer un seul web service pour tout le projet ou bien pour chaque page de mon application web je dois associer un web service?
merci pour vos aides et vos retours

[popo]

merci bcp pour vos retours.
je commence à me débrouiller avec les webservice. j'ai ajouté un web service à mon application, je suis en train de créer toutes les méthodes de mon projet dans la même page.asmx, coté programmation c'est facile, mais c'est assez long vue le nombre énorme de méthodes que je dois créer. si j'ai bien compris je dois par la suite sécuriser ce web service, puisque un web service n'est pas suffisant pour assurer la sécurité. mais je n'ai aucune idée par quoi commencer , et ce que je dois écrire un code? si oui, où ?. pour la chaine de connexion appelée dans le web service, je dois la garder dans le web.config? une dernière question, est ce que je dois créer un seul web service pour tout le projet ou bien pour chaque page de mon application web je dois associer un web service?
merci pour vos aides et vos retours

Pour la sécurité, commence par mettre une authentification (par exemple JWT).
Ensuite, tu as tout un tas d'options décrite dans le lien que je t'ai donné l'autre jour.

Pour la chaine de connexion, tu peux la garder dans le web.config à partir du moment où ton serveur IIS est sécurisé.
La sécurité de IIS est un sujet largement exposé sur le net. Tu n'auras aucun mal à trouver des infos.

Pour le nombre de web service, je ne vois pas l'intérêts d'en créer plusieurs.
Par contre, il est préférable d'avoir plusieurs contrôleurs dans ce web service.
Le plus efficace selon moi est d'avoir un contrôleur par domaine fonctionnel.
Par exemple un service pour faire de la facturation va avoir un contrôleur dédié au client, un autre dédié aux articles, etc.

[forinfo]

MERCI POPO pour votre disponibilité.
les contrôleurs ca veut dire les API?

[popo]

Je m'aperçois que nous n'utilisons pas le même vocabulaire.
Je suis habitué aux API REST et vous écrivez du SOAP, du coup le terme "Contrôleur" n'est pas bon.

Ce que j'appelle Web Service, c'est l'application web.
Il s'agit du projet ASP.Net lui-même.
Ce qui va déterminer l'application publiée sur le serveur.
Cela correspond au domaine de l'URL (exemple=> https://www.popo.com).

Ce que j'appelle contrôleur en REST correspond à ce que SOAP considère comme le Web service.
Il sagit de la classe héritant de System.Web.Services.WebService
Celle qui va service a générer l'ASMX.
Cela correspond à ce qu'il y a derrière le domaine (exemple : https://www.popo.com/ArticleService.asmx)

Donc si je reste sur l'exemple de la facture, mes contrôleur Article et Client se traduiront en SOAP par deux URL sur le même domaine mais avec des routes différentes.
https://www.popo.com/ArticleService.asmx
https://www.popo.com/ClientService.asmx