Yes it’s true. *** Hardt on Microsoft.

http://identity20.com/?p=171

 

Another way for sharing knowledge at .NET University. It uses an interesting community (free) oriented model: you can volunteer to share your knowledge through a structured course that you suggest, or you can simply attend an available course.

While searching for a team collaboration tool that would easily allow sharing my screen and documents with other team members, I came across Microsoft SharedView. This beta, released on May 2007, allows a "fast, easy way to share documents and screen views with small groups of friends or coworkers; anytime, anywhere." 

The usability just is great, despite the poor performance and the lack of P2P support - something to be fixed for the RTM (hopelly). It is a small and simple tool that integrates with Windows Live Messenger making it really easy to use.

Check it out.

  

I just noticed this interesting release on Codeplex called sqltool. This project provides two tools:

• Database Publishing Wizard
• Database Publishing Services

Database Publishing Wizard (supporting command line mode & Visual Studio integration) allows to script a database to a file (schema &| data) or publish it on a server (with Database Publishing Services).

 

If you read my previous post concerning Transport Security on a Self-Hosted WCF service, you may realize that I was using a digital certificate (X.509) on a basicHttpBinding to encrypt our channel, but with no client authentication. WCF supports several types of client authentication: Basic, Digest, NTLM, Windows and Certificate. I'll focus this post on a client authentication, or if you want, Transport Client Credential: Certificate.

With transport security settled to certificate and a client credential type as certificate were are able to mutually authenticate the server to the client (the SSL connection) and the client to the server (through the client credential).

The first thing to do is to enable transport security. I'll not go on this, because my previous post discusses exactly this, check it out.

Assuming that you have already transport security running ok, you will need to add a few more information into your configuration file:

 

The thing here, is to define the client credential type has shown in bold in the server config file. On the client side, your client configuration file must be compliant with the server configuration. The client configuration follows:


At bold, you can find the relevant parts in the client configuration file. The first bolded part, specifies the certificate that will be used for client authentication. This certificate was generated as being a Client Authentication type certificate from the Certificate Authority.
The second bolded part indicates that we will be using a digital certificate as the client credential.

This is all you have to do on your client and server configuration files. However, not enough to put working.
The next step is to reconfigure the server certificate binding to the port to allow client certificates, enabling mutual authentication. Assuming that you have read and tried to do what's in my previous post, you first need to clear the configuration you done with the HttpCfg.exe tool:

---

C:\Program Files\Support Tools>httpcfg delete ssl -i 0.0.0.0:8888

HttpDeleteServiceConfiguration completed with 0.

---

The previous command removes the certificate binding to the IP 0.0.0.0 (0.0.0.0 represents the machine address, so it will bind to every IP addresses your machine has)  and port 8888 you had previously configured. You should ignore this command if you haven't done any IP:Port - certificate binding.

Now, you need to configure to enable mutual authentication:

---

C:\Program Files\Support Tools>httpcfg set ssl -i 0.0.0.0:8888 -h e561943dac9441e1ecaafb064e86b047672adb2d -f 2 -m 1

HttpSetServiceConfiguration completed with 0.

---

In the blue part, we define the IP & port to which we want to bind your certificate used to enable transport security.
In the red part, we indicate the certificate being used to enable transport security. We specify the certificate by its SHA1 hash. Once again, check the previous port for further details.
In the green part, we indicate we want to negociate the client certificate. This is the key point that enables the client credential to be accepted from the server.
Finally, in the orange part, we specify the certificate check mode. In this case, we are specifying that the client certificate will not be verified for revogation (something you don't want to do in a production environment).

Now we are almost done. Just a few check ups and we are ready to hit F5. You will mainly need this if you don't have a Certificate Authority available or if your certificates are issued from the makecert.exe tool.

Your client has to trust the server certificate (the certificate used enabling transport security, - SSL). Yet, it needs the public key of the server certificate.
If you don't have a Certificate Authority that can tell you  whether the server certificate is trustable or not you should add the root certificate (that makes part of the server certificate) into the Local Computer | Trusted Root Certificate Authorities. Also, you need to install the server certificate public key on the client.

You can install the server certificate public key on the client, by exporting the server certificate to a file:










Now, go to the client and import the server certificate into Current User store | Personal.
Now import the root certificate into Current User store | Trusted Root Certification Authorities using the same procedure:




What you have done so far was to give the server's certificate (containing the public key) to the client and made the client trust this certificate. This should only be necessary if you don't have a certificate authority in place.
The next step is to make the client certificate trustable by the server. You need to execute the inverse procedure to allow the server to trust the client.

And now, the good part: run your service. Invoke a service operation from the client, and check the 
The PrimaryIdentity should contain the client identity based on the client certificate.

I've just spent half a day with my colleague Sérgio to get this thing working, and I've decided to share it with the community.

The deal was to enable transport security on a basicHttpBinding in a self-hosted WCF service. I am not going into the service definition logic because it's not really relevant in this context. Instead I'll focus on configuration and the steps for achieving transport security using a service certificate (X.509 certificate).
If you are new on PKI and the concepts behind digital certificates, you should get some background info to help you to understand some of these concepts. Check this topic group on MSDN concerning Transport Security that will help you to understand the underlying concepts of PKI.

An important point here, is that WCF does not internally enable transport security (SSL). You can achieve transport security in WCF by introducing some external artifacts. If you are hosting your service on IIS (which is not the case in this example), you can use IIS to configure and enable SSL. There is at least one sample on the Windows SDK that addresses this scenario.
The other scenario is enabling SSL on a self-hosted service (and this is what this post is about).

The followed example was created using the .NET Framework 3.0 September CTP.

The first step is to create your service logic. The service configuration will be exemplified declaratively on the .config file:


This file associated to your service contains the configuration data to enable transport security to your service.  You now need to issue the proper certificate using a CA or makecert (for testing purposes). If you are using a Microsoft Windows CA you can request the digital certificate by choosing:
Advanced Certificate Request from the CA the web application and provide the hostname as the name (subject name) for your digital certificate. In this case, it will be MYSERVER. Also, you must request the certificate type as Server Authentication, indicate you want to store the certificate on the Local Computer Store and the hash being a SHA1 hash type.
Then, go to the Certification Authority console and issue the certificate that should be in pending. After doing this, go back to the CA web application, and install the certificate on your computer. Check if the certificate was added to the Local Computer store, under Personal\Certificates.

Now you are almost done. Remember that WCF does not internally enable transport security. You have to configure this by yourself. To achieve this you will require the HttpCfg.exe tool. This is part of Windows XP SP2 Support Tools and is available for download here. (This tool is available by default on Windows 2003).
If the HttpCfg.exe is installed use it to configure a port with an X.509 certificate:

where 0.0.0.0:8888, is the IP Address and the port for your certificate and the e561943dac9441e1ecaafb064e86b047672adb2d is the thumbprint of the certificate (the SHA1 hash) that you can obtain on the certificate Details tab in the certificate (when copying it remember to remove the spaces on it).

And that should be done. You can now run your service using transport security on a self-hosted WCF service.

Hello,

I finally had the time to finish the Parameter Validation Add-in. This add-in allows you to perform method's parameters validation in a automatic manner based on configuration file.

Take this as example:

In the figure above, by calling the context menu, you'll see a new menu item named "Validate Parameters". By clicking on it, the add-in will validate the method's parameters based on a configuration file (we'll get on that config file soon...).

So, the result will be something like this:



The generated code is based on a XML configuration file (check this post), and also based on a language extension plugin. In this case a C# language plugin. Since I almost only use C# on .NET context, I will only provide the C# plugin for code generation, however it's really easy to create language extension plugins for other languages; let me know if you are interested on doing this.
The following picture, show the configuration/options window inside Microsoft Visual Studio 2005:



As you can see, the add-in will ask you the path for the XML configuration file. It is based on this file that the semantics for the code are built. Also, you can see that it requires a plugin assembly; this assembly contains one (or more) classes that implement a IIfStatementGenerator interface, and each of these classes are considered language extension plugins.

The add-in is working, but still needs some work and documentation supporting it. Nevertheless, here are the binaries if you want to check it while I don't post a stable release: ParameterValidation20060327.rar (26.32 KB)

Greetings,

Here is the Parameter Validation Schema for Visual Studio 2005 Add-in: ParameterValidation.xsd

The parameter validation schema relates with Parameter Validation Add-in, which allows you to validate method parameters automatically based on a XML configuration file.
Here is an add-in example in action:


And here's the result:



This code was generated based on a XML configuration file:



I will be publishing the add-in very soon. Hope you enjoy it.