Discussion :

[Invité]

Bonjour,

Je reviens vers vous concernant mon Service WCF.

J'ai donc créé un Service WCF qui est exposé via 3 endpoints :

- SOAP
- POX
- JSON

Niveau sécurité, tout passe en Https avec en plus une implémentation de la classe UserNamePasswordValidator.

Mon Service WCF est parfaitement fonctionnel en interne et en externe avec des applications WPF, Winforms ou Silverlight créées avec le Framework 3.5 ou même 4.0.

Un des clients qui doit utiliser le Service WCF nous a signalé qu'il avait des problèmes pour utiliser notre Service. Pour tester la communication, je leur ai transmis une application de test en 3.5. Ils m'ont confirmé que la communication passait bien. J'ai appris par la même occasion que leur application était en Framework 1.1. Le problème semble donc venir de là.

J'ai essayé de créer une application Windows Form en 2.0 et effectivement, je n'arrive pas à consommer mon Service WCF.

J'obtiens systèmatiquement ce message d'erreur :

Une erreur s'est produite lors de la vérification de la sécurité du message.

Quelqu'un a déjà eu ce problème ? Est-il possible de consommer un Service WCF en Https utilisant une sécurité UserNamePasswordValidator avec une application cliente réalisée en 1.1 ou 2.0 ?

A noter que je n'ai pas trouvé l'équivalent de ClientCredentials avec le Framework 2.0.

En 3.5, je fais comme cela pour m'authentifier :

Code :

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

1
2
3
client = new MyServiceReference.ServiceClient();
client.ClientCredentials.UserName.UserName = "login";
client.ClientCredentials.UserName.Password = "pass";

En 2.0, à défaut d'avoir trouvé autre chose, j'ai fais comme cela :

Code :

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

1
2
3
4
5
ServiceClient service = new ServiceClient();
System.Net.NetworkCredential cred = new System.Net.NetworkCredential();
cred.UserName = "login";
cred.Password = "pass";
service.Credentials = cred;

Est-ce la bonne méthode ?

A titre informatif, voici le fichier Web.Config de mon Service WCF :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<system.serviceModel>
 
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
    <services>
      <service name="Solution.WCFService.MonService" behaviorConfiguration="MetadataWSDL">
        <host>
          <baseAddresses>
            <add baseAddress="https://adresse-site"/>
          </baseAddresses>
        </host>
        <endpoint address="SOAP"
                  binding="basicHttpBinding"
                  contract="Solution.ServiceContract.IMonService"
                  bindingConfiguration="soapBinding" />
        <endpoint address="POX"
                  binding="webHttpBinding"
                  contract="Solution.ServiceContract.IMonService"
                  behaviorConfiguration="PoxBehavior"
                  bindingConfiguration="webBinding" />
        <endpoint address="JSON"
                 binding="webHttpBinding"
                 contract="Solution.ServiceContract.IMonService"
                 behaviorConfiguration="JsonBehavior"
                 bindingConfiguration="webBinding" />
      </service>
    </services>
 
    <!-- bindings -->
    <bindings>
      <!-- SOAP -->
      <basicHttpBinding>
        <binding name="soapBinding" >
          <security mode="TransportWithMessageCredential"  >
            <transport clientCredentialType="Basic" />
            <message clientCredentialType="UserName" />
          </security>
        </binding>
      </basicHttpBinding>
      <!-- REST -->
      <webHttpBinding>
        <binding name="webBinding">
          <security mode="Transport" >
          </security>
        </binding>
      </webHttpBinding>
    </bindings>
 
    <!-- behaviors -->
    <behaviors>
      <endpointBehaviors>
        <!-- plain old XML -->
        <behavior name="PoxBehavior">
          <webHttp />
        </behavior>
        <!-- JSON -->
        <behavior name="JsonBehavior">
          <enableWebScript  />
        </behavior>
      </endpointBehaviors>
      <serviceBehaviors>
          <behavior name="MetadataWSDL">
            <serviceCredentials>
              <userNameAuthentication customUserNamePasswordValidatorType="Solution.WCFService.CustomUserNameValidator, Solution.WCFService" userNamePasswordValidationMode="Custom" />
            </serviceCredentials>
            <serviceMetadata httpsGetEnabled="true" httpGetEnabled="true" />
            <serviceDebug includeExceptionDetailInFaults="true" />
            <dataContractSerializer maxItemsInObjectGraph="6553600"/>
          </behavior>
      </serviceBehaviors>
    </behaviors>
 
  </system.serviceModel>

Merci d'avance pour votre aide.

[cybermaxs]

Salut,

Est-il possible de consommer un Service WCF en Https utilisant une sécurité UserNamePasswordValidator avec une application cliente réalisée en 1.1 ou 2.0 ?

Mauvaise nouvelle, WCF a été introduit avec .Net 3.0. Il n'est donc pas accessible aux versions précédentes car il y a de nouvelles assemblies. J'ai bien peur qu'il ne soit pas possible de l'utiliser dans ton cas.

[SaumonAgile]

Mauvaise nouvelle, WCF a été introduit avec .Net 3.0. Il n'est donc pas accessible aux versions précédentes car il y a de nouvelles assemblies. J'ai bien peur qu'il ne soit pas possible de l'utiliser dans ton cas.

Cela n'a rien à voir. Tu peux consommer des services WCF avec n'importe quelle application .NET ou autre. La seule contrainte est que la plateforme cliente supporte les mêmes schémas d'authentification et les mêmes protocoles que ce qui est requis par le service. Ici apparemment ce n'est pas le cas, la négociation du schéma semble échouer pour une raison non spécifiée.

Sookie, peux tu nous donner l'exception complète qui se déclenche ?

[cybermaxs]

Cela n'a rien à voir. Tu peux consommer des services WCF avec n'importe quelle application .NET ou autre

Bien sûr, WCF n'a pas inventé ses propres standards. Il utilise, selon le binding les WS-*. Bien sûr que les services sont censés pouvoir être consommés depuis autre chose que le client WCF de base. J'ai peut être répondu trop vite sur ce sujet. Néanmoins, je te remercie de l'info. Autant pour le basichttpBinding je ne me faisant pas de soucis sur la compatibilté, autant pour le webHttpBinding je ne savais pas. Tu peux aussi m'accorder que consomer en .NEt 1/2 un service WCF c'est pas une opération qu'on fait tous les jours, et que les possibilités sont limitées.

La seule contrainte est que la plateforme cliente supporte les mêmes schémas d'authentification et les mêmes protocoles que ce qui est requis par le service. Ici apparemment ce n'est pas le cas, la négociation du schéma semble échouer pour une raison non spécifiée.

C'est là le hic. J'ai du me brancher il y a quelques temps sur un web service java bien respectueux du WS-BasicProfile. Pour plusieurs raisons je n'ai pas pu le consommer nottament à cause de la sécurité.

Sookie, je te suggère d'essayer d'utiliser WSE pour tes credentials. La secutité Username avec Message ajoute des éléments dans l'entête Soap. Ce que tu ajoutes dans ton ServiceClient n'ajoute rien dans le Soap. Avec WSE tu pourras. Essaye aussi d'utiliser des traces des messages : ce sera plus simple pour voir les requêtes de ton client.

[Invité]

Cela n'a rien à voir. Tu peux consommer des services WCF avec n'importe quelle application .NET ou autre. La seule contrainte est que la plateforme cliente supporte les mêmes schémas d'authentification et les mêmes protocoles que ce qui est requis par le service. Ici apparemment ce n'est pas le cas, la négociation du schéma semble échouer pour une raison non spécifiée.

Sookie, peux tu nous donner l'exception complète qui se déclenche ?

Je sais pas si ça va t'aider, mais j'ai récupérer ça dans l'Exception :

Code :

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

à System.ComponentModel.AsyncCompletedEventArgs.RaiseExceptionIfNecessary()

Code :

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

à System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) à System.Web.Services.Protocols.SoapHttpClientProtocol.InvokeAsyncCallback(IAsyncResult result)

Bien sûr, WCF n'a pas inventé ses propres standards. Il utilise, selon le binding les WS-*. Bien sûr que les services sont censés pouvoir être consommés depuis autre chose que le client WCF de base. J'ai peut être répondu trop vite sur ce sujet. Néanmoins, je te remercie de l'info. Autant pour le basichttpBinding je ne me faisant pas de soucis sur la compatibilté, autant pour le webHttpBinding je ne savais pas. Tu peux aussi m'accorder que consomer en .NEt 1/2 un service WCF c'est pas une opération qu'on fait tous les jours, et que les possibilités sont limitées.

C'est là le hic. J'ai du me brancher il y a quelques temps sur un web service java bien respectueux du WS-BasicProfile. Pour plusieurs raisons je n'ai pas pu le consommer nottament à cause de la sécurité.

Sookie, je te suggère d'essayer d'utiliser WSE pour tes credentials. La secutité Username avec Message ajoute des éléments dans l'entête Soap. Ce que tu ajoutes dans ton ServiceClient n'ajoute rien dans le Soap. Avec WSE tu pourras. Essaye aussi d'utiliser des traces des messages : ce sera plus simple pour voir les requêtes de ton client.

Tu entends quoi exactement par "utiliser WSE pour les credentials" ? Tu as un exemple à me donner ou un complément d'information sur le sujet ? Merci

[cybermaxs]

Tu entends quoi exactement par "utiliser WSE pour les credentials" ? Tu as un exemple à me donner ou un complément d'information sur le sujet ? Merci

Les credentials passés via ton code ne respectent pas ce qu'attend le serveur c'est à dire un élement dans l'entête SOAP du style

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        <soap:Header>
         ...
          <wsse:Security soap:mustUnderstand="1">
            <wsu:Timestamp wsu:Id="Timestamp-e99dc7c6-97d0-4495-8529-96cfe09c9083">
              <wsu:Created>2010-03-01T13:48:34Z</wsu:Created>
              <wsu:Expires>2010-03-01T13:53:34Z</wsu:Expires>
            </wsu:Timestamp>
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-d98f92fa-6b48-498a-b029-f18b8df29c78">
              <wsse:Username>wstest</wsse:Username>
              <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">15sICKqOHd/7R+ytKYErtkesjvM=</wsse:Password>
              <wsse:Nonce>fdWMqvwe4lOC3S3VTnB9TA==</wsse:Nonce>
              <wsu:Created>2010-03-01T13:48:34Z</wsu:Created>
            </wsse:UsernameToken>
          </wsse:Security>
...
        </soap:Header>

Pour cela la façon la plus simple que j'ai trouvé, est d'utiliser WSE car il permet de gérer ce niveau de sécurité (absent des webservices standards). Il est possible de faire l'ajout de l'entête par toi même mais ça risque d'être plus compliqué.

Ensuite un simple code de ce genre ajoutera l'élément

Code :

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

1
2
           MyServiceReference.ServiceClientWse client = new MyServiceReference.ServiceClientWse();
            client.RequestSoapContext.Security.Tokens.Add(new UsernameToken(username, password, PasswordOption.SendHashed));

[Invité]

Les credentials passés via ton code ne respectent pas ce qu'attend le serveur c'est à dire un élement dans l'entête SOAP du style

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        <soap:Header>
         ...
          <wsse:Security soap:mustUnderstand="1">
            <wsu:Timestamp wsu:Id="Timestamp-e99dc7c6-97d0-4495-8529-96cfe09c9083">
              <wsu:Created>2010-03-01T13:48:34Z</wsu:Created>
              <wsu:Expires>2010-03-01T13:53:34Z</wsu:Expires>
            </wsu:Timestamp>
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-d98f92fa-6b48-498a-b029-f18b8df29c78">
              <wsse:Username>wstest</wsse:Username>
              <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">15sICKqOHd/7R+ytKYErtkesjvM=</wsse:Password>
              <wsse:Nonce>fdWMqvwe4lOC3S3VTnB9TA==</wsse:Nonce>
              <wsu:Created>2010-03-01T13:48:34Z</wsu:Created>
            </wsse:UsernameToken>
          </wsse:Security>
...
        </soap:Header>

Pour cela la façon la plus simple que j'ai trouvé, est d'utiliser WSE car il permet de gérer ce niveau de sécurité (absent des webservices standards). Il est possible de faire l'ajout de l'entête par toi même mais ça risque d'être plus compliqué.

Ensuite un simple code de ce genre ajoutera l'élément

Code :

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

1
2
           MyServiceReference.ServiceClientWse client = new MyServiceReference.ServiceClientWse();
            client.RequestSoapContext.Security.Tokens.Add(new UsernameToken(username, password, PasswordOption.SendHashed));

J'avais trouvé un exemple dans ce sens sur Internet.
J'ai bien créé un UsernameToken avec le login et le pass dans le constructeur.
Mais le problème, c'est que je n'ai pas accès à RequestSoapContext depuis mon objet client. Donc impossible de lier les deux

[cybermaxs]

J'avais trouvé un exemple dans ce sens sur Internet.
J'ai bien créé un UsernameToken avec le login et le pass dans le constructeur.
Mais le problème, c'est que je n'ai pas accès à RequestSoapContext depuis mon objet client. Donc impossible de lier les deux

comment ça, pas accès ?

[Invité]

comment ça, pas accès ?

Et bien quand je tape client. , l'intellisence ne me propose pas RequestSoapContext.

[cybermaxs]

Et bien quand je tape client. , l'intellisence ne me propose pas RequestSoapContext.

Si tu as bien pluggé WSE dessus, il te génère un objet supplémentaire du type clientWse dans lequel il se trouve.
WSE n'est qu'une couche supplémentaire ajoutée au client classique.

[Invité]

Si tu as bien pluggé WSE dessus, il te génère un objet supplémentaire du type clientWse dans lequel il se trouve.
WSE n'est qu'une couche supplémentaire ajoutée au client classique.

Tu peux m'expliquer plus en détails ?

Comment tu fais pour plugué WSE sur l'objet Client ?

Merci encore pour ton aide et désolée pour toutes mes questions.

[cybermaxs]

Tu peux m'expliquer plus en détails ?

Comment tu fais pour plugué WSE sur l'objet Client ?

Merci encore pour ton aide et désolée pour toutes mes questions.

Lorsque tu installes WSE, un nouveau élément du menu contextuel projet apparaît "WSE Settings" (clic droit sur le projet). Dedans tu peux spécifier si il faut l'utiliser ou pas pour la génération du proxy. Par contre, je crois qu'il faut faire une petite manip sous VS2008, car WSE cible VS2005 : c'est comme une extension. Pour faire plus simple, je m'étais de VS2005.