Reliable Sessions Made Simple with WCF

The second in my series of articles on WCF is now available on DevX. The article covers the continuing saga of the ACME Toothpick Corporation as they integrate a new chopstick manufacturing system into their WCF based manufacturing management application. It discusses reliable sessions and guaranteed message delivery. Great reading for the whole family. Look for a follow-up article covering queuing in WCF soon.

Microsoft Azure

I recently had the opportunity to attend the MSDN developer's conference in Reston where I sat in on a couple of sessions about Microsoft Azure. While I am still waiting for my developer access to the Azure CTP I wanted to put together a brief overview of Azure and its included services.

What is Azure?
Azure is a new operating system designed to allow applications and services to be deployed and run in the cloud. While the cost structure has not been fully defined yet, the intention of Azure is to allow businesses to deploy applications to Azure and reduce the overhead required to maintain high availability servers and networks. Azure provides a fully scalable architecture without the need to purchase or maintain servers or a large data center.

When an application is deployed to Azure, virtual Windows 2008 64-bit servers are provisioned and assigned to the application. The number of servers assigned depends on how you choose to configure your deployment. For even the simplest application, Azure will provision enough servers to ensure that minimum failover and redundancy requirements are met. These servers are automatically maintained through the Azure platform - this means security patches and any other routine maintenance is handled for you. Any time a virtual server needs to be taken down, other backup servers (running your application) take up the load. This allows Azure to maintain your environment without any application downtime. These virtual servers are distributed across different networks (potentially different data centers and even countries).

Azure applications currently have access to a couple of different data storage options; Blobs, tables and queues. Azure storage, like the application hosting, is intended to be secure, redundant and highly available. Blobs are analogous to files in Azure and allow for metadata storage in addition to the binary file data. Tables are intended to provide a structured storage location containing a collection of entities and entity properties. Queues provide both messaging and storage options for applications.

Several additional services are included in the current CTP release of Azure: Live Services, SQL Services and .Net Services. Live services provide the developer full access to the toolset and SDK available through Microsoft's Live Framework (dev.live.com).

Sql Services does not provide a full virtual Sql Server like you might think. In the current release of Azure, Sql Services provides a way to execute relational queries against your data, but does not enforce any schema on the data you insert. Data in Sql Services is organized into 3 structures - Authority, Container and Entity. Authority can be thought of as 'server', Container as 'database' and Entity is more like a row in a table (although this may be too simplistic of an analogy). I didn't find Authority and Container much different from namespacing. Entity however looks to be where the real changes live. An entity in Sql Services is essentially a Property Bag where properties can be pretty much anything (base types, other complex objects, blobs, etc). Entities of the same "type" do not have to have all of the same properties - at least not enforced by Azure Sql Services. Access to Sql Services data can be accomplished through several different protocols and languages including (but not limited to) REST, SOAP and Linq.

.Net Services for Azure include 3 components: Access Control, Service Bus and Workflow Services. Access Control provides a way for applications to authenticate using several supported authentication providers including Windows Live ID and Active Directory.

The Service Bus provides a messaging infrastructure to allow applications to interact with each other regardless of where the applications live. Using the Service Bus, applications can securely transmit and receive messages through firewalls, NAT and other network boundaries without additional work from the developer or system administrators.

The Workflow Service provides declarative workflow processing in the cloud. Azure workflows are very similar to existing Windows Workflow Foundation workflows and can be designed using the same activities as WF, with the addition of new cloud-aware activities.

Developer Tools for Azure
The developer tools for Azure include plug-ins for Visual Studio 2008 and a full developer's fabric allowing you to run Azure locally and debug your applications in an environment that mimics what is available to a deployed Azure application. This developer fabric (similar to the VS web server) includes all of the functionality and services in Azure including local storage, sql services and .Net services.

Azure provides a staging and a production environment to developers so that we can continue to perform final testing on our applications post-deployment without having to make them live. The staging environment is identical to production - and can be swapped with production if you are deploying new versions of an existing application.

Note: The Azure SDK and developer tool downloads require Vista SP1 at a minimum. You will not be able to install these tools on XP. However, Sql Data Services and the Live Framework SDK support XP.

Open Questions
There are still some open questions about Azure that haven't been answered yet. The biggest of which, to me at least, was the pricing model is still somewhat undefined. Azure will be priced as a utility computing system, meaning users will only pay for what they use (cpu, memory, disk, runtime, hits, network usage). One of the code examples used included putting a worker process to sleep for 2 seconds before waking up and checking a queue for additional work. The presenter was unable to answer the question - How would that be charged? Should developers use sleeping threads? Or do we have to build some sort of scheduling system to avoid excessive usage charges?

Design Implications
How will Azure affect the way we design and build applications? The Azure CTP is an early look into what Microsoft is putting together for enterprise applications in the future. Currently, there is a waiting list just to get developer access to the current incarnation of MS Azure on their servers. Developers can work locally in Visual Studio, but projects cannot be deployed to Azure without being granted access to the developer CTP.

While even very small applications can be run on Azure, the real benefit of the system will be for large scale applications that would normally be deployed across several servers (or server farms) and require businesses to maintain significant infrastructure not used by internal apps. By deploying these large applications to Azure instead of hosting them locally, businesses should be able to save significantly by avoiding the infrastructure costs and overhead.

I don't see any short term benefit to developing for the Azure platform, but applications planning deployment in the 6-12+ month timeframe might be good candidates for an architecture that will support Azure. While there will probably be some restrictions on what your application will be able to do (or rather how you application will do it) Azure is still very young, and design implications are somewhat unclear. Here are a couple things you might want to keep in mind though:

• Remember your application will be deployed to a collection of virtual servers where managing state may become tricky. There are some tools available to help with this in Azure (tables, queues) but your architecture will need some flexibility in how stateful information is stored.
• Sql Data Services provides a good location to store data, however without a schema and without referential integrity enforcement, your data layer(s) will need to be able to handle any inconsistencies in your data.
• There are Blob and Entity size restrictions when storing information in Azure Sql Services today. Blobs are limited to 100mb and Entities to 2mb each.
• Be aware of long-running, idle or inefficient worker processes/threads in your application. Depending on the cost structure of Azure these may cause unexpected charges.
• Above all, remember Azure is still evolving. Restrictions and requirements will probably change as Azure moves closer to release.

Links
Windows Azure
www.azure.com
Register for Azure and SDK download links
http://www.microsoft.com/azure/register.mspx

Elementary Application Security Part 2: Don’t Pass Notes If You Don’t Want Them Read Aloud

Whenever you design a piece of software, a good rule of thumb is, "Simple is better." Sure, we can't always make our applications as simple as we'd like, but it is an ideal that designers have been chasing for a long time. In this spirit, I am writing a series of blog postings relating to application security based upon some very simple principles most of us remember from elementary school. It is the intent of this series that you, the developer, will be able to apply good, solid security principles in your software design.

Part 2: Don’t Pass Notes If You Don’t Want Them Read Aloud

Many times in software development we have information we need to keep hidden. This could be because of legislative, personal, or professional reasons. There is always a question of the best way to handle this. There are, after all, a lot of tools available to developers which make encryption readily available to us.


So, what types of encryption are out there, and which one is the most appropriate to use? Encryption comes in two different flavors: symmetric and asymmetric. Both have their uses and drawbacks.

Symmetric Encryption (or Secret Key Encryption):
Symmetric Encryption is very similar to the well-known “password” concept. All data is encrypted by a “password” (or, more appropriately, a key). Once encrypted, the data can be sent to anyone, but only those people who possess the key can read the data. The longer the key is, the stronger the encryption that is provided. This is form of encryption actually has historic roots going back as far as the Roman Empire, with the advent of the Caesar cipher.

The .NET Framework 3.5 possesses a number of symmetric encryption classes available for use. It is best to use the Rjindael class whenever possible, as it uses one of the strongest encryption methods available. The other classes provide different degrees of strength. One example: TripleDESCryptoServiceProvider is little more than the DESCryptoServiceProvider being ran three times.

The main weakness of the symmetric encryption is in key management: once you generate your key, how do you give it to your clients without others being able to read it? On the plus side, symmetric encryption is very quick, from a software performance perspective. This alone makes symmetric encryption a very appropriate means of securing data.

Asymmetric Encryption (or Public Key Encryption):
Asymmetric Encryption is a relative newcomer to the cryptography field. Its roots trace back to the late 1800s, and a working implementation, known as Diffie-Hellman, was published in 1976. It solves the key-swapping problem of the symmetric encryption routines, although its mechanism can be a little more difficult to understand.

With this type of encryption, there are two or more parties involved with a message. Each party has two keys: a public key and a private key. The public key can encrypt a message, but only a private key can decrypt the message. Conversely, a private key message can encrypt a message, but only the public key can decrypt the message. Mathematically speaking, it is impossible for a public key to both encrypt and decrypt the same message. Nor can a private key perform both actions: the two keys work as a team. One key, by itself, has no value. Public/Private key encryption also have the added benefit of non-repudiation. This means they can be used to verify a specific sender. When combined with security hashes (a future blog post), they act as digital signatures.

With that being said, the public key can be sent out to anyone who requests it without any worries of information being compromised. All parties will then freely give out their public keys. Then, any message that needs to be sent to a given party is encrypted with that party’s public key. Then, once it is sent, only the party’s private key can decrypt the message.

There are a few asymmetric providers available in the .NET Framework 3.5. Specifically, the DSACryptoServiceProvider, the RSACryptoServiceProvider, and the ECDiffieHelmanCng classes can be used for public/private key pairs. The weakness of asymmetric encryption is in processing speed. Computationally speaking, it is expensive to perform public/private key encryption.

Therefore, a common means of implementing encryption involves using both asymmetric and symmetric encryption. A “password” is randomly generated by one party of a transaction. This password is then sent to another party via public key encryption. Once decrypted with the corresponding private key, future messages (for a specified amount of time) is encrypted via a computationally cheap symmetric encryption algorithm.

By properly using symmetric and asymmetric encryption techniques, you have a great means of keeping your information secure:
* Use a random number generator to create a password.
* Use a form of asymmetric encryption to share the random password.
* Use Symmetric encryption to handle data exchange.
* Be sure to create an 'expiration date' for your password, and thus repeating these steps.

Be sure to try out different methods to determine which one (or ones) works the best for your situation. Never, ever attempt to create your own algorithm or implement your own versions of algorithms when encrypting data. The .NET Framework's classes have been thoroughly tested and are efficient. If you implement your own encryption algorithm and make a coding mistake, you have likely caused your application to be less secure.

Good luck with your cryptography!


Link to Part 1: Look Both Ways Before Crossing The Street