Using Certificate Based Authentication to Consume a Windows Azure WCF Service from SharePoint 2010

Version: 1.0

Description

The cloud security design ensures that a customer's data is only accessible by authorized entities. In this lab, you will learn how to create a signing certificate and store it in the machine root and how to create self-signed client and server certificates and store them in the appropriate certificate stores. Then you will create a Windows Azure hosted WCF service that authenticates users based on the certificates, and finally create a SharePoint Web Part application that reads the client's certificate store for a valid certificate to consume the Windows Azure service.

Overview

The cloud security design ensures that a customer’s data is only accessible by authorized entities. Windows Azure provides confidentiality via several mechanisms, one of which is Identity and Access Management. This Ensures that only properly authenticated entities are allowed access.

Certificates and private keys are uploaded via Service Management API (SMAPI) or the Windows Azure Portal as PKCS12 (PFX) files protected in transit by SSL. PKCS12 is one of the Public-Key Cryptography Standards (PKCS), published by RSA Laboratories, which defines a file format commonly used to store X.509 private keys with accompanying public key certificates, protected with a password-based symmetric key. SMAPI removes the password protection (if necessary) and encrypts the entire PKCS12 blob using SMAPI’s public key and stores it in a secret store on the fabric controller, along with a short certificate name and the public key as metadata. The configuration data associated with any role within the same subscription specifies the certificates that should be made available to the role. When a role is instantiated on a VM, the Fabric controller retrieves the appropriate certificate, decrypts the PKCS12 blob, and re-encrypts it using the Fabric agent's public transport key. For more information on using Certificates with Windows Azure, please read the Windows Azure Security Overview Whitepaper.

Objectives

In this lab, you will:

  • Create a signing certificate and store it in the machine root.
  • Create self-signed client and server certificates and store them in the appropriate certificate stores
  • Create a Windows Azure hosted WCF service that authenticates users based on the certificates
  • Create a SharePoint Web Part application that reads the client's certificate store for a valid certificate to consume the Windows Azure service.

System Requirements

You must have the following items to complete this lab:

Setup

The Windows Azure SDK (included in Windows Azure Tools for Visual Studio) installs a simulation environment on your development machine for testing Azure applications locally before deploying them to the cloud. The simulation environment consists of the development fabric to host web and worker roles, and the development storage which simulates cloud blob, table and queue storage locally.

Development storage uses SQL Server as its underlying storage mechanism, and by default the SDK will attempt to configure it to use SQL Server Express. If you do not have SQL Server Express installed before installing the SDK, or you wish to simply use an existing SQL Server instance to host the development storage database, you must run the dsinit command to select the SQL Server instance where the database will be created.

Using dsinit to Configure Development Storage

  1. Open a command prompt.
  2. Edit the following command line as appropriate for your environment, where [AzureSDKInstallDrive] is the drive where you installed the Azure SDK (or Windows Azure Tools for Visual Studio), and [YourSqlInstance] is the SqlServer where you want to create the development storage database.[AzureSDKInstallDrive]\ Program Files\Windows Azure SDK\v1.4\bin\devstore\dsinit.exe /sqlinstance:[YourSqlInstance].

    Example Command Line:“C:\Program Files\Windows Azure SDK\v1.4\bin\devstore\dsinit.exe” /sqlinstance:.

  3. Note that the sample command line above uses the value “.” for the sqlinstance argument, which specifies that the local default SQL instance will be used for development storage.

Estimated time to complete this lab: 60 minutes.