Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite reconnu
par toutes les applications web du même serveur. Puis-je envisager le même
fonctionnement pour un web service : envoyer les credentials en SSL sur un
web service dédié à l'authentification et échanger ensuite un ticket
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite reconnu
par toutes les applications web du même serveur. Puis-je envisager le même
fonctionnement pour un web service : envoyer les credentials en SSL sur un
web service dédié à l'authentification et échanger ensuite un ticket
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite reconnu
par toutes les applications web du même serveur. Puis-je envisager le même
fonctionnement pour un web service : envoyer les credentials en SSL sur un
web service dédié à l'authentification et échanger ensuite un ticket
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message de news: e6557pCGFHA.3728@TK2MSFTNGP14.phx.gbl...
La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" <nospam@nospam.org> a écrit dans le message de news:
e2L2zsMGFHA.2180@TK2MSFTNGP12.phx.gbl...
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message de news: e6557pCGFHA.3728@TK2MSFTNGP14.phx.gbl...
La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme me
l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à protéger
(contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL sur
un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker mon
ticket crypté ? (ce qui me permettrait, si j'ai bien compris, d'interdire
de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" a écrit dans le message
de news: uR4%Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker mon
ticket crypté ? (ce qui me permettrait, si j'ai bien compris, d'interdire
de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" <simonm@online.microsoft.com> a écrit dans le message
de news: uR4%2371NGFHA.1924@TK2MSFTNGP14.phx.gbl...
Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" <nospam@nospam.org> a écrit dans le message de news:
e2L2zsMGFHA.2180@TK2MSFTNGP12.phx.gbl...
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message de news: e6557pCGFHA.3728@TK2MSFTNGP14.phx.gbl...
La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker mon
ticket crypté ? (ce qui me permettrait, si j'ai bien compris, d'interdire
de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" a écrit dans le message
de news: uR4%Cela semble correct, il faut juste faire attention au "cookie crypté", ce
qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels risques
on court (risque = impact + probabilité). Une fois qu'on a évalué ou
calculé ça, on met les moyens correspondant en face. Si vous protégez des
silos de missiles ou une centrale nucléaire avec des cookies cryptés,
c'est sans doute trop faible par exemple. Mais par rapport à vos besoins
fonctionnels, c'est peut-être largement suffisant. Ce que je veux dire
c'est que le niveau de sécurité nécessaire n'est pas une question
technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Je ne suis pas sûr de tout bien comprendre :-)
Le cookie permet d'avoir un mécanisme standard de persistence/état/session
(enfin presque ce n'est pas un standard tout à officiel :-) implémenté par
le "User Agent" quel qu'il soit: IE, Navigator, Firefox, Opera, ... au
sens HTTP. A partir du moment ou vous êtes en Winform (SmartClient), et
que vous maîtrisez aussi le serveur, vous avez le loisir de faire ce que
vous voulez.
Concernant HttpGet et HttpPost, quoiqu'il arrive les webservices
fonctionnent avec GET ou POST. Ne pas confondre la page de test générée
automatiquement pour un browser (GET) et les appels par des programmes
(POST en général).
Simon.
"Fred" a écrit dans le message de news:
%Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker
mon ticket crypté ? (ce qui me permettrait, si j'ai bien compris,
d'interdire de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" a écrit dans le
message de news: uR4%Cela semble correct, il faut juste faire attention au "cookie crypté",
ce qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels
risques on court (risque = impact + probabilité). Une fois qu'on a
évalué ou calculé ça, on met les moyens correspondant en face. Si vous
protégez des silos de missiles ou une centrale nucléaire avec des
cookies cryptés, c'est sans doute trop faible par exemple. Mais par
rapport à vos besoins fonctionnels, c'est peut-être largement suffisant.
Ce que je veux dire c'est que le niveau de sécurité nécessaire n'est pas
une question technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur
des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Je ne suis pas sûr de tout bien comprendre :-)
Le cookie permet d'avoir un mécanisme standard de persistence/état/session
(enfin presque ce n'est pas un standard tout à officiel :-) implémenté par
le "User Agent" quel qu'il soit: IE, Navigator, Firefox, Opera, ... au
sens HTTP. A partir du moment ou vous êtes en Winform (SmartClient), et
que vous maîtrisez aussi le serveur, vous avez le loisir de faire ce que
vous voulez.
Concernant HttpGet et HttpPost, quoiqu'il arrive les webservices
fonctionnent avec GET ou POST. Ne pas confondre la page de test générée
automatiquement pour un browser (GET) et les appels par des programmes
(POST en général).
Simon.
"Fred" <nospam@nospam.net> a écrit dans le message de news:
%23FPOz6QGFHA.1740@TK2MSFTNGP09.phx.gbl...
Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker
mon ticket crypté ? (ce qui me permettrait, si j'ai bien compris,
d'interdire de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" <simonm@online.microsoft.com> a écrit dans le
message de news: uR4%2371NGFHA.1924@TK2MSFTNGP14.phx.gbl...
Cela semble correct, il faut juste faire attention au "cookie crypté",
ce qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels
risques on court (risque = impact + probabilité). Une fois qu'on a
évalué ou calculé ça, on met les moyens correspondant en face. Si vous
protégez des silos de missiles ou une centrale nucléaire avec des
cookies cryptés, c'est sans doute trop faible par exemple. Mais par
rapport à vos besoins fonctionnels, c'est peut-être largement suffisant.
Ce que je veux dire c'est que le niveau de sécurité nécessaire n'est pas
une question technique.
Simon.
"Fred" <nospam@nospam.org> a écrit dans le message de news:
e2L2zsMGFHA.2180@TK2MSFTNGP12.phx.gbl...
Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" <PasDeSpam_f.LAMBOUR@everlog.com> a écrit dans le
message de news: e6557pCGFHA.3728@TK2MSFTNGP14.phx.gbl...
La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" <nospam@nospam.org> a écrit dans le message de
news:ehjy7KBGFHA.2928@TK2MSFTNGP14.phx.gbl...
Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur
des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
crypté
par l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !
Je ne suis pas sûr de tout bien comprendre :-)
Le cookie permet d'avoir un mécanisme standard de persistence/état/session
(enfin presque ce n'est pas un standard tout à officiel :-) implémenté par
le "User Agent" quel qu'il soit: IE, Navigator, Firefox, Opera, ... au
sens HTTP. A partir du moment ou vous êtes en Winform (SmartClient), et
que vous maîtrisez aussi le serveur, vous avez le loisir de faire ce que
vous voulez.
Concernant HttpGet et HttpPost, quoiqu'il arrive les webservices
fonctionnent avec GET ou POST. Ne pas confondre la page de test générée
automatiquement pour un browser (GET) et les appels par des programmes
(POST en général).
Simon.
"Fred" a écrit dans le message de news:
%Bonsoir,
Merci pour cette appréciation. Effectivement ce niveau de sécurité sera
très suffisant pour mon application. Mais je profite de ce développement
pour approfondir un peu ces questions et parcourir la section "Security"
de la MSDN Library. D'ailleurs je n'ai rien inventé, mais collecté et
adapté des exemples de code C#. Mon cookie contient donc, à priori, les
bonne infos : nom utilisateur, roles, date de création et d'expiration,
mais pas de mot de passe.
Puis-je utiliser l'en-tête SOAP, plutôt qu'un cookie HTTP¨pour stocker
mon ticket crypté ? (ce qui me permettrait, si j'ai bien compris,
d'interdire de nouveau HttpGet et HttpPost, comme par défaut)
"Simon Mourier [MS]" a écrit dans le
message de news: uR4%Cela semble correct, il faut juste faire attention au "cookie crypté",
ce qu'il contient, etc...
Dans les histoires de sécurité, la question à se poser c'est toujours de
savoir quelle attaque ou quelle menace on cherche à éviter, quels
risques on court (risque = impact + probabilité). Une fois qu'on a
évalué ou calculé ça, on met les moyens correspondant en face. Si vous
protégez des silos de missiles ou une centrale nucléaire avec des
cookies cryptés, c'est sans doute trop faible par exemple. Mais par
rapport à vos besoins fonctionnels, c'est peut-être largement suffisant.
Ce que je veux dire c'est que le niveau de sécurité nécessaire n'est pas
une question technique.
Simon.
"Fred" a écrit dans le message de news:Bonjour,
Finalement j'ai trouvé une façon de procéder, sans doute pas très
orthodoxe, qu'en pensez-vous ?
Je crée un service web. J'autorise le http, désactivé par défaut comme
me l'a signalé Simon Mourier plus tôt.
Dans le service web, un fichier login.asmx et un autre fichier à
protéger (contenant effectivement les services)
dans le web.config :
- < authentication mode=None />
- un élément location qui me permet d'accorder l'accès aux utilisateurs
anonymes sur le fichier login.asmx
<location path="login.asmx">
<system.web>
<authorization>
<allow users="?" />
</authorization>
</system.web>
</location>
- de manière générale je n'autorise aucun utilisateur excepté certains
roles
<authorization>
<allow roles="role1, role2, role3" />
<deny users="*" />
</authorization>
Dans login.asmx, j'authentifie l'utilisateur à partir d'une base de
données, j'ajoute un cookie crypté à la réponse (avec un nom spécifique
puisque je ne suis pas en mode Forms)
Dans Global.asax, je récupère le cookie crypté et je crée un
GenericPrincipal avec les roles de l'utilisateur.
Dernière étape, dans IIS, j'impose le SSL sur mon fichier login.asmx.
Cela à l'air de bien fonctionner.
"Frédéric LAMBOUR" a écrit dans le
message de news:La solution la plus simple : mettre en place l'autentification windows
et
passer le login et le password avec le code suivant :
//Autentification Windows
ICredentials credentials = new NetworkCredential("Login", "Pwd");
monServiceWeb.Credentials = credentials;
Incovénient : il faut stocker chez le client le login et le mot de
passe.
"Fred" a écrit dans le message de
news:Bonjour,
Je souhaite sécuriser un service web. Je me perds un peu dans les
méandres
de la documentation.
Pouvez-vous m'indiquer une piste pour mes recherches.
Sachant que :
Le client de mon service est une application WinForm, exécutée sur
des
postes n'appartenant pas au domaine.
Je ne veux pas utiliser SSL pour ne pas surcharger le serveur. Les
données
pouvant circuler en clair sur internet sans problème, à l'exception
des
données d'identification de l'utilisateur (compte et mot de passe).
D'après ce que j'ai compris, il ne m'est pas possible d'utiliser
l'authentification Forms ? Et quand bien même, il me faudrait trouver
un
moyen de passer outre la page de login (déjà en place pour d'autres
Applications Web sur le même serveur) car j'accède au service par
application WinForm.
La solution est-elle dans la personnalisation des en-têtes SOAP ?
Comment dans ce cas encrypter mes données ?
Pour mes applications Web, le serveur génère un ticket crypté en
fonction
des informations d'identification envoyées en https.Ticket ensuite
reconnu
par toutes les applications web du même serveur. Puis-je envisager le
même
fonctionnement pour un web service : envoyer les credentials en SSL
sur un
web service dédié à l'authentification et échanger ensuite un ticket
cryptépar l'intermédiaire de l'en-tête SOAP ?
Merci de bien vouloir me mettre sur la bonne voie !