1. Certificates. We’ll be using two certificates for signing. We’ll create a private/public keypair in the client side and import the client’s public key to server. Likewise, we’ll import server’s public key to the machine running the client.
2. First let’s create a key pair to be used in the client,

   makecert -r -pe -n "CN=mycert" -sky exchange -sv mycert.pvk mycert.cer
   

   This will create a private and public key pair. Next we need to import this into Windows certificate store. In order to do that we need to convert our key pair to PFX format which includes both the private and the public key,

   pvk2pfx -pvk mycert.pvk -spc mycert.cer -pfx mycert.pfx
   

   Now, run mmc and add a certificate snap-in for the Local Computer. Browse into Trusted People and import mycert.pfx. Just click next when it asks for the private key password.

3. We have set the certificates for the client. Next we have to extract server’s public key and import it into Windows certificate store. Since I’m going to use WSO2 ESB for the server side, we need to extract the public key from the Java keystore that’s being used by the ESB. Browse to <ESB HOME>\repository\resources\security and give the following command. Java needs to be in your PATH. When prompted type “wso2carbon” as the keystore password.

   keytool -keystore wso2carbon.jks -export -alias localhost -file localhost.cer
   

   Import localhost.cer into Trusted People just like before.

4. Now we need to import the client’s public key to the server. Start the ESB by double clicking wso2server.bat. Browse into https://localhost:9443 and login with admin/admin. Click Configure -> Key Stores.

   

   Click Import Cert

   

   and browse and select mycert.cer we just created and click Import.

   

5. We’re done setting up certificates. Let’s create a simple secure service. Luckily ESB ships an echo service which when you send a message, echoes it back. Click Main -> List (under Web Services).

   

   Here you see a list of web services. In front of the echo service you’ll see a link saying “Unsecured”.

   

   Click it and select “yes” from the drop down to apply security for the echo service.

   

   Here you’ll see a list of pre-configured security scenarios. We’ll be using number 2, Non-Repudiation under Basic Scenarios. Select it and click Next.

   

   Select wso2carbon.jks as a trusted keystore and click Finish. Echo service is secured now.

   

6. We created and setup certificates and now have a secured service. Open up Visual Studio and create a new console application. You can create any kind of project but I’d prefer to create console apps for testing these type of scenarios.
7. Add a Service Reference to your project. WSDL file for the service is located at http://localhost:8280/services/echo?wsdl
8. For the binding that you’ll be using you have to configure security,

   <security defaultAlgorithmSuite="Default" authenticationMode="MutualCertificateDuplex"
       requireDerivedKeys="false" securityHeaderLayout="Lax" includeTimestamp="true"
       keyEntropyMode="CombinedEntropy" messageProtectionOrder="SignBeforeEncrypt"
       messageSecurityVersion="Default" requireSignatureConfirmation="false">
   <localClientSettings cacheCookies="true" detectReplays="true"
       replayCacheSize="900000" maxClockSkew="00:05:00" maxCookieCachingTime="Infinite"
       replayWindow="00:05:00" sessionKeyRenewalInterval="10:00:00"
       sessionKeyRolloverInterval="00:05:00" reconnectTransportOnFailure="true"
       timestampValidityDuration="00:05:00" cookieRenewalThresholdPercentage="60" />
   <localServiceSettings detectReplays="true" issuedCookieLifetime="10:00:00"
       maxStatefulNegotiations="128" replayCacheSize="900000" maxClockSkew="00:05:00"
       negotiationTimeout="00:01:00" replayWindow="00:05:00" inactivityTimeout="00:02:00"
       sessionKeyRenewalInterval="15:00:00" sessionKeyRolloverInterval="00:05:00"
       reconnectTransportOnFailure="true" maxPendingSessions="128"
       maxCachedCookies="1000" timestampValidityDuration="00:05:00" />
   <secureConversationBootstrap />
   </security>
   

9. Your actual service should looks like this,

   static void Main(string[] args)
   {
       svc.echoPortTypeClient echo = new svc.echoPortTypeClient("echoHttpSoap11Endpoint");
   
       echo.ClientCredentials.ServiceCertificate.SetDefaultCertificate(
          System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
          System.Security.Cryptography.X509Certificates.StoreName.TrustedPeople,
          System.Security.Cryptography.X509Certificates.X509FindType.FindBySubjectName, "localhost");
   
       echo.ClientCredentials.ClientCertificate.SetCertificate(
           System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
           System.Security.Cryptography.X509Certificates.StoreName.TrustedPeople,
           System.Security.Cryptography.X509Certificates.X509FindType.FindBySubjectName, "mycert");
   
       System.Console.WriteLine(echo.echoString("hello"));
       System.Console.ReadLine();
   }
   

   Note that we set the correct service and client certificates. As you can see I’m using an HTTP endpoint. This is useful to test the messages going through a tool like TCPMon. When you have the scenario working you can just switch to the HTTPS endpoint.

Useful references,

• Various ways to create private/public keypairs – http://code.google.com/apis/apps/articles/sso-keygen.html
• Makecert reference – http://msdn.microsoft.com/en-us/library/bfsktky3%28v=VS.100%29.aspx
• SecurityBindingElement Authentication Modes – http://msdn.microsoft.com/en-us/library/aa751836.aspx

IMO (also I’ve raised this issue numerous times in the Stonehenge mailing list) problem with .Net WCF code we have now in Stonehenge defines bindings to each and every endpoint. Currently Stonehenge .Net trader client program can talk to business services implemented in .Net, Java (deployed in WSO2 WSAS and Sun Metro) and PHP (implemented using WSF/PHP). Each of these implementations runs on a different port and is having their own URL that they’re exposing the services. When there is a new implementation of the business service using a different framework, in order to point the .Net trader client program to talk to this new business service we have to add a binding into the trader client configuration with a binding specific to that. This, IMHO, defeats the whole purpose of Web services. When you compare .Net WCF to WSO2 Web services frameworks, in the WSO2 family of open source frameworks for many languages, only need the end point. When you want to talk to a different service with similar semantics, you just change the end point URL and everything else just work. There’s no “boilerplate” configuration necessary. That’s loose coupling. Anyhoo, back to the steps,

1. Open SQL Management Studio
2. Connect to your StockTraderDB database
3. Open up ClientToBs table and make sure DOTNET_CLIENT is using DOTNET_BS
4. Open up Service table and change the URL of DOTNET_BS to http://localhost:9763/services/TradeServiceWsas
5. Open Web.config in \dotnet\trader_client\Trade and add requireSignatureConfirmation="false" to line 99. After the change the line should look like the following,

   messageSecurityVersion="WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10" requireSignatureConfirmation="false">

6. Build WSAS trunk
7. Start WSAS by running <WSAS dir>\bin\wso2server.bat
8. Import BS.jks and OPS.jks in <stonehenge trunk>\stocktrader\wsas\resources\conf. Go to https://localhost:9443/carbon and login as admin. Username: admin, password: admin.
9. Click on Key Stores -> Add New Key Store. For BS.jks password is ‘yyy’. For OPS.jks password is ‘password’.
10. Start .Net services by running RunServices.bat
11. Login to .Net trader client by going to http://localhost/trade and tryout the operations