Web Services

Encrypting and securing web service traffic without SSL

Sometimes the need arises to have secured web service traffic without depending on SSL. The web service in a windows service without IIS from the previous post cannot use SSL anyway (well not that I know – any comments on this). There also may be a need to authenticate to the web service, either through the usual user and pass system, or my preferred method of using AES and pre-shared keys. Security experts agree the world over that AES is a very tough security standard. This method is great for two reasons:

  • No need to type in a user and pass, just ensure the keyfile is on each machine – if they keys match then the data is readable
  • Very high security

It does have a couple of downsides however:

  • Each client must have the same key – unless we use soap headers to first identify the user, the server will use this info to load the appropriate key
  • Keys cannot distinguish users without the soap header above or something similar, so user accounting is a smidge more tricky than straight user and pass

Of course on IIS you can use both the pre-shared key and user/pass authentication for extra security – NTLM kerberos and pre-shared AES key… pretty damn secure in my book.

A basic outline of the steps involved in this little project is:

  • Create webservice
  • Create encryption class
  • Create SOAP header class to provide a secondary layer of security
  • Maybe some user/pass authentication if I get time (for IIS only)

I’m going to use the web service created in the previous post, but this should work with any web service, WSE or not.

First we will get the basic encryption stuff out of the way, so create a new public class called Crypto… mine is in a class library. This class will create a key if one doesn’t exist, and will provide the encryption and decryption duties. This article isn’t focused on encryption, so I’m going to just dump the encryption class code in one blob.


using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Security.Cryptography;
using System.Xml;

namespace Web_Service_inside_a_Windows_Service
{
    public class Crypto
    {
        byte[] key;
        byte[] iv;

        public Crypto()
        {
            keyInit();
        }

        //pretty much a straight copy of MSDN
        public byte[] Encrypt(string input)
        {
            UTF8Encoding textConverter = new UTF8Encoding();
            RijndaelManaged rijndael = new RijndaelManaged();
            byte[] toEncrypt;         

            ICryptoTransform encryptor = rijndael.CreateEncryptor(key, iv);

            MemoryStream msEncrypt = new MemoryStream();
            CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write);

            toEncrypt = textConverter.GetBytes(input);

            csEncrypt.Write(toEncrypt, 0, toEncrypt.Length);
            csEncrypt.FlushFinalBlock();

            return msEncrypt.ToArray();
        }

        public string Decrypt(byte[] input)
        {
            UTF8Encoding textConverter = new UTF8Encoding();
            RijndaelManaged rijndael = new RijndaelManaged();

            byte[] fromEncrypt;
            int discarded = 0;

            ICryptoTransform decryptor = rijndael.CreateDecryptor(key, iv);

            MemoryStream msDecrypt = new MemoryStream(input);
            CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read);

            fromEncrypt = new byte[input.Length];

            csDecrypt.Read(fromEncrypt, 0, fromEncrypt.Length);

            return textConverter.GetString(fromEncrypt);
        }

        //check for keys and if not present the create them
        //load keys into local vars
        void keyInit()
        {
            //place the keys in a nicely accessible location so other applications that use this class can use them - note this location is probably
            //not secure on most machines
            FileInfo keyFile = new FileInfo(System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\\CryptoKeys");

            string sKey;
            string sIv;

            if (!keyFile.Exists)
            {
                sKey = generateHexKey();//set the keys into the local vars as they are created
                sIv = generateHexIV();
                XmlDocument doc = new XmlDocument();
                doc.LoadXml("");

                XmlNode keyNode = doc.CreateElement("key");
                keyNode.InnerText = sKey;
                doc.DocumentElement.AppendChild(keyNode);

                XmlNode ivNode = doc.CreateElement("iv");
                ivNode.InnerText = sIv;
                doc.DocumentElement.AppendChild(ivNode);

                if (!keyFile.Directory.Exists)
                {
                    keyFile.Directory.Create();
                }

                doc.Save(keyFile.FullName);
            }
            else
            {
                XmlDocument doc = new XmlDocument();
                doc.Load(keyFile.FullName);
                sKey = doc.DocumentElement.SelectSingleNode("key").InnerText;
                sIv = doc.DocumentElement.SelectSingleNode("iv").InnerText;
            }

            key = Convert.FromBase64String(sKey);
            iv = Convert.FromBase64String(sIv);
        }

        string generateHexKey()
        {
            //Rijndael *is* AES
            RijndaelManaged rijndael = new RijndaelManaged();
            rijndael.GenerateKey();
            return Convert.ToBase64String(rijndael.Key);
        }

        string generateHexIV()
        {
            RijndaelManaged rijndael = new RijndaelManaged();
            rijndael.GenerateIV();
            return Convert.ToBase64String(rijndael.IV);
        }
    }
}

There. Nothing fancy, pretty much the default encryption stuff from MSDN, except i change the ASCIIEncoder to a UTF one so that way it will support any character we throw at it. Oh and the comments are poor as you can see.

Okay, so now we can encrypt stuff, lets use it and get some secure web service action happening. First we need to update the web service. In your web service code behind make the following adjustments.


using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://myURI/MyLittleWebService")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebServiceCodeEncrypted : System.Web.Services.WebService
{
    Web_Service_inside_a_Windows_Service.Crypto crypto = new Web_Service_inside_a_Windows_Service.Crypto();
    public WebServiceCodeEncrypted()
    {
    }

    [WebMethod]
    [SoapHeader("AuthKey", Direction = SoapHeaderDirection.In)]
    public string GetMessages(string sGuid)
    {
        string guid = decString(sGuid);
        return encString("At the third stroke the time will be " + DateTime.Now.ToString() + ". Your guid was " + guid);
    }

    string encString(string input)
    {
        //convert the byte array that comes out for easy transport.
        return Convert.ToBase64String(crypto.Encrypt(input));
    }

    string decString(string input)
    {
        return crypto.Decrypt(Convert.FromBase64String(input));
    }

    public class AuthorisationKey : SoapHeader
    {
        public byte[] EncData = null;

        public AuthorisationKey()
        {

        }

        public bool Validate(System.Web.HttpContext context, string WSMethodName)
        {
            try
            {
                //EncData should contain the ticks of the date time that hte request was made...
                //by checking this we are doing two things a) the key is right if we get a valid date time and
                //b) the request is only valid for 5 minutes, cause after that runDate will be less than now - 5 mins.
                string ticks = crypto.Decrypt(EncData);
                DateTime runDate = new DateTime(Convert.ToInt64(ticks));
                return runDate > DateTime.Now.AddMinutes(-5);
            }
            catch (Exception ex)
            {
                //maybe throw a nice exception here - like the key was bad or something.
                throw ex;
            }
        }
    }

}

A few notes:

  • Added decrypt and encrypt string methods. They user the base64encoding stuff in the Convert class library to turn the byte array into a string.
  • We could have just put return type of byte[] on the GetMessages web method (.NET will base64 encode it anyway), but I like strings better because they are easily stored in formats like XML.
  • We added in the soap header authorisation class. More on this a bit later.
  • Changed the web service class name to WebServiceCodeEncrypted because you need to include a reference to your main project to bring in the new crypto class library, and there would have been two classes named the same (the original copy of the webservice is in the other class remember)
  • Note that any unsafe string (i.e. un encrypted) should always be named in a way that indicates its status. For example, you could call your safe encrypted string sSomeName and your un-encrypted ones uSomeName… then hopefully you wont ever accidentally transmit around an unsecured string.

Ensure you copy this updated webservice code into an IIS based “real” web service and update the reference in your project.

Now accessing the webservice is the fun part. Update the code in your WebServiceQuery class:


WebServiceCodeReference.WebServiceCodeWse wsc = new WebServiceCodeReference.WebServiceCodeWse();
WebServiceCodeReference.AuthorisationKey key = new WebServiceCodeReference.AuthorisationKey();

Crypto crypto = new Crypto();
key.EncData = crypto.Encrypt(DateTime.Now.Ticks.ToString());

wsc.AuthorisationKeyValue = key;

IPHostEntry ip = Dns.GetHostEntry(targetMachineName);
wsc.Url = "soap.tcp://" + ip.AddressList[0].ToString() + "/MyLittleWebService";

string result = wsc.GetMessages(Convert.ToBase64String(crypto.Encrypt("This here is a test string")));

string decResult = crypto.Decrypt(Convert.FromBase64String(result));</pre>
<pre>return decResult;

First and foremost if you run this from your test application or service, the data will be encrypted! Secondly you can see we are creating an object to implement the call to the soap security header… we put the current date time in there, so the server can get *its* current date time, take off five minutes, and compare it to the one passed in… this means that each message is only valid for five minutes (so no nefarious beings can pinch your packets and spoof another request to the server – well not after five minutes anyway).

If you are running your web service on IIS then you can add in the following code to authenticate with user and pass while still using the pre-shared key system:


	if (user != null && user!=string.Empty)
            {
                if (user.ToLower() == "integrated")
                {
                    wsc.Credentials = System.Net.CredentialCache.DefaultCredentials;
                }
                else
                {
                    NetworkCredential netCred = new NetworkCredential(user, pass);
                    wsc.Credentials = netCred;
                }
            }

Pass the user and pass variables into your method. Set the user the integrated to use the NTLM based single sign on authentication of the current windows user.

Update: 31 October 2007

Another reason why using built in encryption rather than SSL etc is that SSL is transport level encryption, meaning you cannot access the encrypted version of the content. With the AES inbuilt version you could save off your messages to DB or filesystem without the need to re-encrypt them.

Update: 16 May 2008

Added missing soap attribute from GetMessages method.

Web Services

Web service inside a Windows service without IIS

Update: If you have any questions about this article or any other web-services related queries then please ask! I see alot of traffic coming from Google about web-services and related issues/problems which this text doesn’t cover but I can probably help with! Leave a comment and I will respond quickly – if I don’t have the answers then I bet I know someone that does.

Skip to the Ramble End section to get into the guts of the article… the first part is just me talking too much as usual.

I’ve decided I need to get out more (it was either me or my shrink – I cant remember. Ed.); see the sights, expand my horizons, meet new media dissemination platforms.

I find myself writing and documenting code for my team mates at Objectify – tidbits of information here and there, how-to’s, faq, code snippets, my secret pasta recipe etc. – all usually transmitted in email form, with the occasional Word or PDF doc if they are lucky. If they are really lucky I may enter it into our internal FAQ system… for a fee.

Why not blog about some stuff too? See just for interests sake if anybody is interested in anything I say.

I thought I would start off nice and easy – ease into the Blogoshere nice and slowly (note to self – blog about hating the word “Blogoshere”… oh someone already did, damn). So I’m opening up the innings with a little ditty about hosting web services inside a windows service without the need for IIS. I wrote this doco about a year and a half ago, so its basically a translation of some old stuff… Sure its nothing too technical, its not ahead of the curve so to speak, and its probably been done a thousand times but we all gotta start somewhere. If we get time we may even throw in some SOAP headers and AES encryption for good measure – nothing like a pre-shared key to brighten your day. Okay well maybe in the next entry.

I first came across the need for a web service inside a windows service when thinking about ways to decentralise the Objectify CMS debugging system. Basically the debugging system goes way back to the days of the first CMS, all written in VB6 mind you, and uses mail slots to transfer messages from an array of COM objects to the debugger output application. Problem was that clients (and internal testers etc.) had to log into the server and run the application to see the messages. Now I know what you are going to say – you can pipe mailslot data between machines, problem solved… but I wanted to try something new, so web services it was.

Ramble End

We will end up with a simple web service windows service (WSWS?) with an interface to query which will do some simple processing for posterity’s sake and return a message to the client.
Firstly, you are going to need Web Services Enhancements 3.0 from Microsoft. Hop along to http://msdn2.microsoft.com/en-gb/webservices/Aa740663.aspx and grab a copy – make sure you install the developer option (the Visual Studio developer option if you are using VS). It will distribute itself with your app when you build the installer (if you choose to) so no need to install the MSI on your target machine.

Start your new project by creating a class library. I called mine something original – Web Service inside a Windows Service. This is where we will be placing the bulk of the code. Create a new public class called HostWebService.

Add in references to Microsoft.Web.Services3 and System.Web.Services.

Begin your code by adding the following namespace includes:

using Microsoft.Web.Services3;
using Microsoft.Web.Services3.Addressing;
using Microsoft.Web.Services3.Messaging;
using System.Net;

Okay so we are ready to go. Too easy. In the constructor we need to do some things to start our little web service listener. First, we need to know the local machine’s DNS address, and use this address to create a URI for our new Web Service (i.e. the address that will be used in the client application to query the service).

 string hostName = Dns.GetHostName();
 IPHostEntry ipEntry = Dns.GetHostEntry(hostName);
 Uri address = new Uri("soap.tcp://" + ipEntry.AddressList[0].ToString() + "/MyLittleWebService");

By the way, did I mention that if you know a better way to do any of this the please feel free to comment – i.e. is that the best way to get the IP of the local machine?

You can see above that the Uri address=xxxxx line is where you set the actual URI of the service, you can change the last part from MyLittleWebService to something more fitting if you like.

Now we need to create the actual web service code… It’s basically the same code that is generated by Visual Studio when you create a web service (the code behind in the Service.asmx file). Create a new class called WebServiceCode.cs and paste in the following:

using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://myURI/MyLittleWebService")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class WebServiceCode : System.Web.Services.WebService
{
    public WebServiceCode()
    {
    }

    [WebMethod]
    public string GetMessages(string guid)
    {
        return "At the third stroke the time will be " + DateTime.Now.ToString();
    }

}

Nothing too tricky there, stock standard web service stuff. Next we go back into the HostWebService class and add the following just below the URI stuff:

 SoapReceivers.Add(new EndpointReference(address), typeof(WebServiceCode));

And we’re done… almost. Well we’re done to the point that if you run that code (from a test app or something) then you will have a windows app that is hosting a web service. Thats great, but how do you query said service?

Accessing the new service

Before we can access the new web service we need to add it as a Web Reference to our project. Normally this is nice and easy, just right click and add a Web Reference in Visual Studio and let WDSL do the work. Problem is this new web service isn’t published anywhere yet, and even when its installed on the target machine and running, its URI will be unknown to the client.

Lets start by getting the web reference. Create a new ASP.NET web service project (call it tempservice or something, you wont need to keep it for long) go to the Service.asmx code behind and paste in the code from your WebServiceCode.cs file. Then right click the Service.asmx file and View in Browser. Copy the URL from the browser window that pops up, and add it as a web reference to your main project (right click References, Add Web Reference, paste into field, click Go, click Add Reference).

Great we have a description of our web service for the client app to use when querying.

Create another class called WebServiceQuery. Add the following to the namespace references section:

 using System.Net;

Now create a public method called Query that returns a string (or you can just paste in the following code):

 public string Query(string targetMachineName)
   {
      Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE wsc = new Web_Service_inside_a_Windows_Service.WebServiceCodeReference.WebServiceCodeWSE();

      IPHostEntry ip = Dns.GetHostEntry(targetMachineName);
      wsc.Url = "soap.tcp://" + ip.AddressList[0].ToString() + "/MyLittleWebService";
      string result = wsc.GetMessages("some guid");

      return result;
   }

NOTE: The object we create is the WSE version (WebServiceCodeWSE), without this the calls to soap.tcp will not work.

Simple – first we instantiate our web reference object. Then we set the URI of the newly instantiated object the same way we did for the service itself. Finally we query the service and return the value. Note the GUID parameter on the service call – this is just in there to demonstrate calling methods and passing in parameters, but you already knew how to do that.

Now you can create a test application, start the service and then query it! All that’s left is to create a Windows service and create an instance of your calling class.

Just a note on the URI creation parts – if you are getting an error do do with port parsing, check that the IP address its getting isn’t and IPV6 address…

Okay so that’s it, my first post. Its long and boring.

Next time I will visit security using SOAP headers and how to encrypt the SOAP data using AES (Rijndael).

Cheers.