Bonjour,
Je voudrais sécuriser l'accès à un service web. Pas nécessairement crypter
les données.
Voilà ce que j'avais «bricolé» dans un premier temps.
Login sur une page en https
Création par le serveur d'un en-tête soap personnalisé reprenant
exactement le principe des cookies cryptés http.
(username, roles, date de création, date d'expiration, ...)
Par la suite, les échanges se font en reprenant cet en-tête, le serveur
pouvant éventuellement le modifier à chaque appel. Le client se contentant
de répondre avec le ticket qui lui a été envoyé en réponse à sa dernière
requête.
Donc seul le serveur crypte et décrypte ce qui est simple à mettre en
½uvre.
(À améliorer en empêchant un second traitement d'un même ticket)
Voyez-vous des raisons de ne pas procéder de la sorte ?
J'ai ensuite essayé WSE, mais sans trouver comment reproduire
approximativement ce schéma.
Il me semble que les fonctionnalités proposées permettent :
- D'envoyer facilement des informations d'identification (username, pwd
hashé). Ce qui oblige à authentifier l'utilisateur à chaque requête et à
recalculer les rôles. Pourquoi pas ? Cela fonctionne bien mais me semble
moins sécurisé que mes premiers essais et un peu plus lourd.
- Ou bien de crypter les informations côté client et décrypter côté
serveur ce qui génère des trames soap énormes par rapport à la quantité
d'informations que je passe (utilisation de certificats).
- D'autres possibilités que j'ignore ??? ....
Si quelqu'un peut m'aiguiller dans la bonne direction je lui serait
reconnaissant, n'ayant que quelques notions d'autodidacte en matière de
sécurité.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Bonjour,
Je voudrais sécuriser l'accès à un service web. Pas nécessairement crypter
les données.
Voilà ce que j'avais «bricolé» dans un premier temps.
Login sur une page en https
Création par le serveur d'un en-tête soap personnalisé reprenant
exactement le principe des cookies cryptés http.
(username, roles, date de création, date d'expiration, ...)
Par la suite, les échanges se font en reprenant cet en-tête, le serveur
pouvant éventuellement le modifier à chaque appel. Le client se contentant
de répondre avec le ticket qui lui a été envoyé en réponse à sa dernière
requête.
Donc seul le serveur crypte et décrypte ce qui est simple à mettre en
½uvre.
(À améliorer en empêchant un second traitement d'un même ticket)
Voyez-vous des raisons de ne pas procéder de la sorte ?
J'ai ensuite essayé WSE, mais sans trouver comment reproduire
approximativement ce schéma.
Il me semble que les fonctionnalités proposées permettent :
- D'envoyer facilement des informations d'identification (username, pwd
hashé). Ce qui oblige à authentifier l'utilisateur à chaque requête et à
recalculer les rôles. Pourquoi pas ? Cela fonctionne bien mais me semble
moins sécurisé que mes premiers essais et un peu plus lourd.
- Ou bien de crypter les informations côté client et décrypter côté
serveur ce qui génère des trames soap énormes par rapport à la quantité
d'informations que je passe (utilisation de certificats).
- D'autres possibilités que j'ignore ??? ....
Si quelqu'un peut m'aiguiller dans la bonne direction je lui serait
reconnaissant, n'ayant que quelques notions d'autodidacte en matière de
sécurité.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Bonjour,
Je voudrais sécuriser l'accès à un service web. Pas nécessairement crypter
les données.
Voilà ce que j'avais «bricolé» dans un premier temps.
Login sur une page en https
Création par le serveur d'un en-tête soap personnalisé reprenant
exactement le principe des cookies cryptés http.
(username, roles, date de création, date d'expiration, ...)
Par la suite, les échanges se font en reprenant cet en-tête, le serveur
pouvant éventuellement le modifier à chaque appel. Le client se contentant
de répondre avec le ticket qui lui a été envoyé en réponse à sa dernière
requête.
Donc seul le serveur crypte et décrypte ce qui est simple à mettre en
½uvre.
(À améliorer en empêchant un second traitement d'un même ticket)
Voyez-vous des raisons de ne pas procéder de la sorte ?
J'ai ensuite essayé WSE, mais sans trouver comment reproduire
approximativement ce schéma.
Il me semble que les fonctionnalités proposées permettent :
- D'envoyer facilement des informations d'identification (username, pwd
hashé). Ce qui oblige à authentifier l'utilisateur à chaque requête et à
recalculer les rôles. Pourquoi pas ? Cela fonctionne bien mais me semble
moins sécurisé que mes premiers essais et un peu plus lourd.
- Ou bien de crypter les informations côté client et décrypter côté
serveur ce qui génère des trames soap énormes par rapport à la quantité
d'informations que je passe (utilisation de certificats).
- D'autres possibilités que j'ignore ??? ....
Si quelqu'un peut m'aiguiller dans la bonne direction je lui serait
reconnaissant, n'ayant que quelques notions d'autodidacte en matière de
sécurité.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Bonjour,
Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
- Limiter l'accès au service à des personnes identifées?
Le moyen le plus simple consiste à forcer les appels au service web
via https.
De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Cordialement,
Bonjour,
Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
- Limiter l'accès au service à des personnes identifées?
Le moyen le plus simple consiste à forcer les appels au service web
via https.
De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Cordialement,
Bonjour,
Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
- Limiter l'accès au service à des personnes identifées?
Le moyen le plus simple consiste à forcer les appels au service web
via https.
De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Cordialement,
Bonjour,
Bonjour,
Bonjour,
Dans : news:,
Osman MALIK [MS] disait :Bonjour,
Bonjour,Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
Non- Limiter l'accès au service à des personnes identifées?
OuiLe moyen le plus simple consiste à forcer les appels au service web
via https.
C'est ce que je fais pour le login.De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Non, je ne veux pas d'interférence avec Windows, mais gérer les
utilisateurs à part.
Sous VS 2003, j'avais programmé tout cela avec une base de données en
exploitant le document SecNet.pdf trouvé sur votre site.
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en train
de l'étudier.Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Oui, j'ai essayé et cela fonctionne bien. Mais je cherche plutôt à
reproduire le mécanisme du cookie http crypté utilisé pour les pages aspx.
Qui me suffit amplement.
Je voulais surtout avoir un avis (voir description de mon procédé sur le
post initial). Et comme je le disais, je n'ai pas trouvé l'équivalent avec
WSE. Dès qu'il y a cryptage, il se fait côté client et serveur et cela
génère des trames importantes (comme, je le suppose, le https utilisé
systématiquement).
Ou bien alors, le client envoie systématiquement un username (en clair) et
un password hashé. Et côté serveur, il faut retrouver à chaque appel les
rôles et, si j'ai bien compris, stocker les mots de passe en clair. Cela
me paraît moins bien que le ticket crypté qui contient toutes les infos et
que seul le serveur peut décoder. Mais peut-être me trompe-je.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https : ok)
Je ne souhaite pas crypter les infos transmises (ou alors il faut que cela
reste léger)
Je veux contrôler qui appelle les fonctions du service web.
Je souhaite conserver un flux d'informations léger car il est prévu que
certaines parties de l'application nécessiteront des appels répétés
(peut-être toutes les demi-secondes dans certains cas), mais les
contraintes matérielles conditionneront cette fonctionnalité.
Cordialement,
Merci pour votre réponse.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:u1Bthde5FHA.1140@tk2msftngp13.phx.gbl,
Osman MALIK [MS] disait :
Bonjour,
Bonjour,
Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
Non
- Limiter l'accès au service à des personnes identifées?
Oui
Le moyen le plus simple consiste à forcer les appels au service web
via https.
C'est ce que je fais pour le login.
De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Non, je ne veux pas d'interférence avec Windows, mais gérer les
utilisateurs à part.
Sous VS 2003, j'avais programmé tout cela avec une base de données en
exploitant le document SecNet.pdf trouvé sur votre site.
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en train
de l'étudier.
Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Oui, j'ai essayé et cela fonctionne bien. Mais je cherche plutôt à
reproduire le mécanisme du cookie http crypté utilisé pour les pages aspx.
Qui me suffit amplement.
Je voulais surtout avoir un avis (voir description de mon procédé sur le
post initial). Et comme je le disais, je n'ai pas trouvé l'équivalent avec
WSE. Dès qu'il y a cryptage, il se fait côté client et serveur et cela
génère des trames importantes (comme, je le suppose, le https utilisé
systématiquement).
Ou bien alors, le client envoie systématiquement un username (en clair) et
un password hashé. Et côté serveur, il faut retrouver à chaque appel les
rôles et, si j'ai bien compris, stocker les mots de passe en clair. Cela
me paraît moins bien que le ticket crypté qui contient toutes les infos et
que seul le serveur peut décoder. Mais peut-être me trompe-je.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https : ok)
Je ne souhaite pas crypter les infos transmises (ou alors il faut que cela
reste léger)
Je veux contrôler qui appelle les fonctions du service web.
Je souhaite conserver un flux d'informations léger car il est prévu que
certaines parties de l'application nécessiteront des appels répétés
(peut-être toutes les demi-secondes dans certains cas), mais les
contraintes matérielles conditionneront cette fonctionnalité.
Cordialement,
Merci pour votre réponse.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:,
Osman MALIK [MS] disait :Bonjour,
Bonjour,Qu'entendez vous par sécuriser le wervice Web?
- Empecher la lecture du flux transmis?
Non- Limiter l'accès au service à des personnes identifées?
OuiLe moyen le plus simple consiste à forcer les appels au service web
via https.
C'est ce que je fais pour le login.De plus, vous pouvez limiter l'accès aux personnes autorisés en
passant par une authentification Basic ou Windows.
Non, je ne veux pas d'interférence avec Windows, mais gérer les
utilisateurs à part.
Sous VS 2003, j'avais programmé tout cela avec une base de données en
exploitant le document SecNet.pdf trouvé sur votre site.
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en train
de l'étudier.Pour ce qui est de WSE, la sécurité passe alors par la mise en place
de cryptage de certaines données, la signature du message afin de
pouvoir sécuriser les echanges en utilisant HTTP.
Oui, j'ai essayé et cela fonctionne bien. Mais je cherche plutôt à
reproduire le mécanisme du cookie http crypté utilisé pour les pages aspx.
Qui me suffit amplement.
Je voulais surtout avoir un avis (voir description de mon procédé sur le
post initial). Et comme je le disais, je n'ai pas trouvé l'équivalent avec
WSE. Dès qu'il y a cryptage, il se fait côté client et serveur et cela
génère des trames importantes (comme, je le suppose, le https utilisé
systématiquement).
Ou bien alors, le client envoie systématiquement un username (en clair) et
un password hashé. Et côté serveur, il faut retrouver à chaque appel les
rôles et, si j'ai bien compris, stocker les mots de passe en clair. Cela
me paraît moins bien que le ticket crypté qui contient toutes les infos et
que seul le serveur peut décoder. Mais peut-être me trompe-je.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https : ok)
Je ne souhaite pas crypter les infos transmises (ou alors il faut que cela
reste léger)
Je veux contrôler qui appelle les fonctions du service web.
Je souhaite conserver un flux d'informations léger car il est prévu que
certaines parties de l'application nécessiteront des appels répétés
(peut-être toutes les demi-secondes dans certains cas), mais les
contraintes matérielles conditionneront cette fonctionnalité.
Cordialement,
Merci pour votre réponse.
--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Bonjour,
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en
train de l'étudier.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https :
ok)
Vous parlez bien d'un Web Service et non d'une application Web?
Si oui, l'authentification doit avoir lieu à chaque appel.
Dans ce cas, soit vous réalisez tous les appels en https avec les
informations d'authentification/identification passées lors de
l'ouverture du flux https.
Si vous utilisez WSE, le cryptage de certaines données est réalisée
sur le client et le serveur. Si vous limitez le nombre de champs
cryptés et que vous utilisez des datatypes simples (string, int,
etc.) sous http, la charge CPU et le ralentissement des temps de
réponse est très limité (<~5%)
Je veux contrôler qui appelle les fonctions du service web.
Cela nécessite la mise en place d'un mécanisme
d'authentification/identification.
Vous devez donc gérer un ensemble d'identités et de droits pour ces
identités.
Bonjour,
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en
train de l'étudier.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https :
ok)
Vous parlez bien d'un Web Service et non d'une application Web?
Si oui, l'authentification doit avoir lieu à chaque appel.
Dans ce cas, soit vous réalisez tous les appels en https avec les
informations d'authentification/identification passées lors de
l'ouverture du flux https.
Si vous utilisez WSE, le cryptage de certaines données est réalisée
sur le client et le serveur. Si vous limitez le nombre de champs
cryptés et que vous utilisez des datatypes simples (string, int,
etc.) sous http, la charge CPU et le ralentissement des temps de
réponse est très limité (<~5%)
Je veux contrôler qui appelle les fonctions du service web.
Cela nécessite la mise en place d'un mécanisme
d'authentification/identification.
Vous devez donc gérer un ensemble d'identités et de droits pour ces
identités.
Bonjour,
Sous VS 2005, j'ai vu que tout cela existait tout prêt et je suis en
train de l'étudier.
Bref, pour résumer :
Je veux protéger les informations d'identification (login en https :
ok)
Vous parlez bien d'un Web Service et non d'une application Web?
Si oui, l'authentification doit avoir lieu à chaque appel.
Dans ce cas, soit vous réalisez tous les appels en https avec les
informations d'authentification/identification passées lors de
l'ouverture du flux https.
Si vous utilisez WSE, le cryptage de certaines données est réalisée
sur le client et le serveur. Si vous limitez le nombre de champs
cryptés et que vous utilisez des datatypes simples (string, int,
etc.) sous http, la charge CPU et le ralentissement des temps de
réponse est très limité (<~5%)
Je veux contrôler qui appelle les fonctions du service web.
Cela nécessite la mise en place d'un mécanisme
d'authentification/identification.
Vous devez donc gérer un ensemble d'identités et de droits pour ces
identités.
