Building Windows Azure Applications with the Caching Service

In this Article, learn how to use the Windows Azure Caching service for both your ASP.NET session state and to cache data from your data-tier. You will see how the Caching service provides your application with a cache that provides low latency and high throughput without having to configure, deploy, or manage the serviceOverview

The Windows Azure Caching service provides a distributed, in-memory cache for your applications. In this lab, you will learn how to use the Windows Azure Caching service for both your ASP.NET session state and to cache data from your data-tier. You will see how the Windows Azure Caching service provides your application with a cache that provides low latency and high throughput without having to configure, deploy, or manage the service.


In this lab, you will learn how to:

  • Easily and quickly provision your cache through the portal
  • Use the caching service for your ASP.NET session state
  • Cache reference data from SQL Azure in the caching service
  • Create a reusable and extensible caching layer for your applications

During this lab, you will explore how to use these features in a simple ASP.NET MVC application.


This lab includes the following exercises:

  1. Using the Windows Azure Caching for Session State
  2. Caching Data with Windows Azure Caching
  3. Creating a Reusable and Extensible Caching Layer

Connecting Apps with Windows Azure Connect

Windows Azure Connect’s primary scenario is enabling IP-level network connectivity between Azure services and external resources. The underlying connectivity model that supports this is quite flexible. For example, you can use Sydney to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.


To enable IP-level network connectivity between Azure services and external resources, Windows Azure Connect can be used. The underlying connectivity model that supports this is quite flexible. For example, you can use Windows Azure Connect to setup networking between arbitrary groups of machines that are distributed across the internet in a very controlled and secure manner.

The following diagram illustrates the key elements of the Windows Azure Connect model.

Windows Azure Connect creates a logical “virtual network” which can contain two types of entities: Azure Role groups and Machine groups.

  • Role groups map to Azure roles, which have been enabled for Windows Azure Connect. Only the Azure VM instances for a role are members of a role group – the admin cannot manually add or remove members. Windows Azure Connect automatically manages the membership of role groups – if you add or remove role instances, Windows Azure Connect will track this and update the role group membership appropriately.
  • Machine groups are admin-defined collections of external machines, which have been enabled for Windows Azure Connect through installation of the Windows Azure Connect Endpoint Software. An external machine can belong to at most one machine group.

Connectivity within the Windows Azure Connect virtual network is based on the following rules:

  • A role group can be “linked” to a machine group – this enables connectivity between the members of those groups. A role group can be linked to multiple machine groups – e.g. you could have an Azure web role that is connected to your “My Servers” and “My Laptops” machine groups as shown in the diagram above.
  • Members of a role group (the Azure VM instances) do not have connectivity with each other. In addition, a role group cannot be linked to another role group. These limitations are intentional – the Azure service model controls connectivity between roles and the Azure runtime supports connectivity between role instances. We did not want the Windows Azure Connect model to interfere with this behavior.
  • Machine groups can be linked, as mentioned above, to role groups. Machine groups can also be linked to other machine groups to enable connectivity between members of those groups.
  • Links are not transitive from a connectivity perspective. For example, suppose Group A is linked to Group B, and Group B is linked to Group C. Machines in Group A can communicate with those in Group B, and machines in Group B can communicate with those in Group C. However, machines in Group A cannot communicate with those in Group C.
  • A machine group has an “interconnected” property – if it is set to true, then all members of that group can communicate with each other. If it is set to false, then communication between the members is not allowed.
  • It is important to note that Windows Azure Connect does not affect or interfere with a machine’s existing network connectivity.


In this lab, you will learn how to:

  • Provision a Windows Azure Connect service and associate it with your Azure subscription.
  • Setup network connectivity between Azure Roles and external machines.


This lab includes the following exercise:

  1. Connecting an Azure Web Role to an External SQL Server Database with Windows Azure Connect
  2. Connecting an Azure Web Role to a on premise services with Windows Azure Connect

Windows Azure CDN

In this Article, you will learn how to scale your static blob content out to the Content Distribution Network (CDN) available in Windows Azure.


Windows Azure provides the Windows Azure Content Delivery Network (CDN) to deliver Windows Azure Blob content. Windows Azure CDN offers developers a global solution for delivering high-bandwidth content.

Windows Azure CDN has several locations globally (United States, Europe, Asia, Australia and South America) and continues to expand. Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Management Portal. The CDN provides edge delivery only to blobs that are in public blob containers, which are available for anonymous access.

The benefit of using a CDN is better performance and user experience for users who are farther from the source of the content stored in the Windows Azure blob storage.

When you enable CDN access for a storage account, the Management Portal provides you with a domain name of the following format: http:/ /<identifier> This domain name can then be used to access blobs in a public container. For example, given a public container “images” and a storage account “youraccount”, once the storage account is enabled for CDN access, users can access the blobs in that container using either of the following two URLs:

When a request is made using the Windows Azure Blob service URL, the blob is read directly from the Windows Azure Blob service. When a request is made using the Windows Azure CDN URL, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the blob. If the blob is not found at that endpoint, then it is retrieved from blob storage and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached blob. The TTL specifies that the blob should be cached for that amount of time in the CDN until it is refreshed by the Blob service. The CDN attempts to refresh the blob from Windows Azure blob storage only once the TTL has elapsed. As described in this msdn article, the default TTL is calculated as 20% of the interval between the present time and the last-modified time, up to a maximum interval of 72 hours. For example, a blob whose last-modified time was 30 minutes ago will be considered fresh for six minutes in the CDN cache. If this value is specified for a blob, then the TTL period will be set to the value specified in Cache-Control HTTP header.

The value of caching blobs in the Windows Azure CDN is realized only when the content is delivered from the CDN edge cache, so content requested only once during the blob’s TTL period will not get performance improvements from edge caching. The blob content that benefits the most from caching are blobs accessed frequently during their cached TTL period.

Blobs already cached in the CDN will remain cached until the TTL for each blob expires. When the TTL expires, the Windows Azure CDN will check to see whether the CDN endpoint is still valid and the Windows Azure blob is still anonymously accessible. If it is not, then the blob will no longer be cached. This means that if you want to change the content of the blob and the blob is currently cached in the CDN, the new content will not be available via the CDN until the CDN refreshes its content when the cached content TTL expires.

When you enable the CDN the configuration created for this endpoint is not immediately available; it can take up to 60 minutes for the registration to propagate through the CDN network worldwide. Users who try immediately to use the CDN domain name will get a 400 error until the configuration is updated worldwide.


In this lab, you will learn how to:

  • Enable Windows Azure CDN
  • Leverage Windows Azure CDN for static content
  • Use TTL headers to control CDN caching scenarios


The following is required to complete this lab:

  • IIS 7 (with ASP.NET, WCF HTTP Activation)
  • Microsoft Visual Studio 2010
  • Microsoft .NET Framework 4.0
  • Windows Azure Tools for Microsoft Visual Studio 1.6


This lab includes the following exercises:

  1. Using the CDN to Deliver Static Content
  2. Managing Cache Expiration and Resource Versioning
  3. Caching Content from Hosted Services

Note: When you first start Visual Studio, you must select one of the predefined settings collections. Every predefined collection is designed to match a particular development style and determines window layouts, editor behavior, IntelliSense code snippets, and dialog box options. The procedures in this lab describe the actions necessary to accomplish a given task in Visual Studio when using the General Development Settings collection. If you choose a different settings collection for your development environment, there may be differences in these procedures that you need to take into account.

Remote Desktop with Windows Azure Roles

The Windows Azure SDK 1.3 and later adds the ability to use Remote Desktop Services to access Windows Azure roles. Visual Studio lets you configure Remote Desktop Services from a Windows Azure project. To enable Remote Desktop Services, you must create a working project that contains one or more roles and then publish it to Windows Azure.

Note:This ability to access a Windows Azure role is intended for troubleshooting or development only. The purpose of each virtual machine is to run a specific role in your Azure application and not to run other client applications.

To enable Remote Desktop Services follow these steps

  1. Open Solution Explorer, right-click the name of your project, and then click Publish.
  2. The Deploy Windows Azure project dialog box appears. At the bottom of the dialog box, click the Configure Remote Desktop connections link at the bottom.
  3. The Remote Desktop Configuration dialog box appears. checked the checkbox Enable connections for all roles.
    Note :=>Visual Studio is designed to enable or disable Remote Desktop Services for all roles in your project. However, it will write remote desktop configuration information for each role. If you manually modify this information to disable Remote Desktop Service for some roles and not others, Visual Studio will no longer be able to modify the configuration and will display a dialog box that communicates this information.
  4. You can select an existing certificate from the drop-down list or you can create a new one.
    Note:=>The certificates that are needed for a remote desktop connection are different to the certificates that are used for other Windows Azure operations. The remote access certificate must have a private key.
  5. To create a new certificate select <create> from the drop-down list.
    The Create Certificate dialog box appears.

    • Type a friendly name for the new certificate and then click OK
    • To upload this certificate to the Windows Azure Platform Management portal, click View.
    • Click the Details tab.
    • To copy this certificate to a file, click Copy to File
    • To export a private key for this certificate, select Yes, export the private keyand then click Next.
    • To select the default export file format, click Next
    • To protect this private key using a password, type a password. Confirm this password and then click Next.
    • To obtain the path for this certificate file to use to upload the certificate, click Browse and copy the path shown in the Save As dialog box. Type the name of the file for this certificate in File name. Click Save, then click Next.
    • To create this file, click Finish.
  6. Using the Windows Azure Platform Management portal, upload the certificate for the hosted service that you will connect to with Remote Desktop Services.
    Note:=>If you attempt to deploy and you have not uploaded your Remote Desktop certificate to Windows Azure, you will receive an error message and your deployment will fail.
  7. Into the Remote Desktop Configuration dialog box, type a Username and a Password.
    Note:=>If the password does not meet the complexity requirements, a red icon will appear next to the password text box. A password that contains a combination of capital letters, lower case letters, and numbers or symbols will pass the complexity requirements.
  8. Choose an account expiration date. The expiration date will automatically block any remote desktop connections when the date passes.
  9. Click OK. A number of settings are added to the .cscfg and .csdef files to enable Remote Access Services.
  10. If you are ready to publish your Windows Azure application, in the Deploy Windows Azure Project dialog box, click OK. If you are not ready to publish, click Cancel. Your Remote Desktop configuration will still be saved, and you can publish your application at a later date.
  11. Once you have published your project to Windows Azure, log on to the Management Portal, and click Hosted Services, Storage Accounts & CDN in the lower right hand corner of the screen.
  12. Click Hosted Services to see the hosted services currently running.
  13. Select your role in the Management portal. In the Remote Access group, ensure that the Enable check box is selected and the Configure button is enabled. This shows that the deployment is enabled for Remote Desktop.
  14. Select the role instance that you want to connect to, which should enable the Connect button in the Management Portal interface.
  15. Click Connect. Your browser will prompt you to download a .RDP file, which you can open on your local computer.
  16. Open the .RDP file and enter the user and password that you set up in the earlier steps. If you are on a domain, you might have to put a \ in front of the username.
  17. You should now be logged into your remote session.

Virtual Machine Role


Windows Azure Virtual Machine Roles allow you to run a customized instance of Windows Server 2008 R2 in Windows Azure, making it easier to move applications to the cloud. In this article, you will explore Virtual Machine roles and you will learn how to create custom OS images that you deploy to Windows Azure.


The majority of the time Web and Worker roles configured with startup tasks are a better solution than the VM Role. The VM Role gives users freedom to control the operating system image. With this control comes the loss of automated consistent OS servicing. The developer is responsible for making sure that the OS image is up to date through the creation of difference disks. OS servicing increases the cost of development, testing and maintenance.

What a VM Role Cannot Do

The VM Role shares the same programming model and network limitations of the Web and Worker roles. One of the key tenets of the Windows Azure programming model is that the hosted service (application) behaves correctly when any instance of a role fails. This means that programs must be stateless so that data is not lost when a role fails. Applications such as SharePoint, SQL Server, Small Business Server, and Terminal Server are stateful applications that are not supported in the VM Role. The lack of UDP traffic means that a Domain Controller (Active Directory) will not work in a VM Role.

What a VM Role Can Do

The VM Role is a perfect fit for the following scenarios:

  • Long running application installations
  • Error-prone application installations
  • Application installations requiring manual interaction

In these cases, a startup task will not work, thus the only solution is to use a VM Role.

In this article, you will explore Virtual Machine roles and you will learn how to create custom OS images that you deploy to Windows Azure.


In this article, you will learn how to:

  • Prepare custom OS images that you can deploy to Windows Azure
  • Connect to your Windows Azure role instances with Remote Desktop for troubleshooting
  • Use differencing disks to apply updates to your Virtual Machine roles


  • This Exercises requires a high-speed Internet connection to upload VM image files to your Windows Azure subscription.
  • Important: Currently, access to VM Role is available through an invite-only beta program. Unless you have enrolled in this program, you will not be able to complete this hands-on lab.


This article includes the following exercises:

  1. Creating and Deploying a Virtual Machine Role in Windows Azure
  2. Troubleshooting with Remote Desktop
  3. Updating and Servicing a Virtual Machine Role

Azure Zone Web Role Service Configuration(HTTPs)


Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet.TLS/SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability.

Targeted Audience

This specification is intended for Architects, Project Managers, Software Design Engineers and Developer.

SSL Certificate

SSL uses an encryption mechanism to transport the data from Client-Server. The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair

The trick in a key pair is to keep one key secret (the private key) and to distribute the other key (the public key) to everybody (client). A client side public key is stored in certificate.

A certificate contains information about the owner, like e-mail address, owner’s name, certificate usage, duration of validity and the certificate ID of the person who certifies (signs) this information.

Certificate contains also the public key and finally a hash to ensure that the certificate has not been tampered with. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates.

Note: Developer can also generate Self Signed certificate for development and testing purpose.

Certificate Generation

Below steps is not required if developer has valid certificate.

Step-1 Generate Self Signed Certificate (Makecert.exe)
Developer can generate certificate for development and testing purpose. Follow below steps to generate Self Signed Certificate
Goto – > “Visual Studio Tool” ->“Visual Studio Command Prompt
Right click “Visual Studio Command Prompt” and select “Run as Administrator” as highlighted below.

Step 2: Use the following command from command prompt. Before running the command don’t forget to replace with service URL. It is mandatory to have CN value same as service URL to expose the service on HTTPs

makecert -r -pe -n “” -b 01/01/2000 -e 01/01/2036 -eku -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12

Step 3 After execution of above command execute MMC command from “RUN”. This will open below highlighted window

Step 4 : Click on File -> “Add/Remove Snap-in”

Step 5: Select Certificate -> Click on “Add” button

Step 6: Select Computer Account -> Click on “Next” button on next screen

Step 7: Click on “Finish” -> “Ok” button on next screen. You should be able to view the  certificate.

Note: It is recommended to NOT to use Self Signed certificate in production environment.

Export Private Key

Once certificate is generated, we need to export the Private key. Private Key required to upload on Windows Azure along with service package and configuration file.

1.Right click on your certificate and navigate to “All Task”->”Export”.

2.Click on Button “Next

3.Select “Yes, Export the private Key“ option and click on “Next” Button as sown below

4.Click on “Next” Button as shown below.

5.Type the Password and Confirm Password (example: sonata) and click on Next Button

6. Brows the location to save the private key on next screen

   Configure Web service on Secure Channel (HTTPs)

1.  Web Role Configuration

Assuming that user has Private key configured in certificate store at development m/c Open the Service solution in Visual Studio and right click on Web Role and select property

Previous steps will open property windows having following highlighted Tab.

Click on “Certificates” Tab, -> Click on “Add Certificates”. This step will display the below screen

Click on button at “Thumbprint” column to brows the certificate from certificate store, select your certificate and click on Ok button.

Now switch to “Endpoints” tab and make the below highlighted configuration and select SSL Certificate from dropdown. It is the same certificate created in previous step.

Now switch to “Configuration” tab and make the below highlighted configuration

Build the project and launch the service, It should be launched on HTTPs protocol.

Web.Config Configuration

Apart from above changes, few more changes to be made on service Web.config file to complete the configuration.
i.  Add the following property to ServiceMetaData Tag as highlighted <serviceMetadata httpsGetEnabled=”true” httpGetEnabled=”true”/>

Make the web config changes as highlighted  below

<?xml version=”1.0″?>
<add type=”Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ name=”AzureDiagnostics”>
<filter type=”” />
<compilation debug=”true” targetFramework=”4.0″>
<add assembly=”Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ />
<customErrors mode=”Off” />
<!–secure wcf by TransportWithMessageCredential security–>
<binding name=”binding1″>
<security mode=”TransportWithMessageCredential”>
<message clientCredentialType=”UserName” />
<service name=”AzureZoneWebRole.TimeSheetService” behaviorConfiguration=”sb1″>
<endpoint address=”” binding=”basicHttpBinding” contract=”AzureZone.TimeSheetContract.ISeemlessOfflineContract” bindingConfiguration=”binding1″ />
<endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
<service name=”AzureZoneWebRole.AuthenticationService” behaviorConfiguration=”sb1″>
<endpoint address=”” binding=”basicHttpBinding” contract=”AzureZone.AuthContract.IAuthenticationService” bindingConfiguration=”binding1″ />
<endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
<behavior name=”sb1″>
<userNameAuthentication userNamePasswordValidationMode=”Custom” customUserNamePasswordValidatorType=”AzureZoneWebRole.MyCustomUsernamePasswordValidator,AzureZoneWebRole” />
<!– To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment –>
<serviceMetadata httpsGetEnabled=”true” httpGetEnabled=”true”/>
<!– To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information –>
<serviceDebug includeExceptionDetailInFaults=”false”/>
<behavior name=””>
<serviceCertificate storeLocation=”LocalMachine” storeName=”My” x509FindType=”FindByThumbprint” findValue=”482C7073ECFD9B90385318C7566A441C4CFB2F8C” />
<behavior name=”ServiceBehavior”>
<!– To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment –>
<serviceMetadata httpsGetEnabled=”true” httpGetEnabled=”true”/>
<!– To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information –>
<serviceDebug includeExceptionDetailInFaults=”true”/>
<serviceHostingEnvironment multipleSiteBindingsEnabled=”true” />
<modules runAllManagedModulesForAllRequests=”true” />
<defaultProxy useDefaultCredentials=”true”>

Build the project and launch the service, It should be launched on HTTPs protocol. Package the Service and Upload to Windows Azure with following

  •   Service Package
  •   Service Configuration
  • Certificate Private Key

 Configure Client on Secure Channel (HTTPs)

Once the Service reference is added of above service following code change is required at client-
Client Credential need to be passed on Proxy.
Sample code:  AzureZoneContractClient proxy = new AzureZoneContractClient();
              if (proxy.ClientCredentials.UserName.UserName == null)
                   proxy.ClientCredentials.UserName.UserName = CommonFunction.UserID;

Windows and Web Client: 

During the development and testing self sign certificate are used, which is not recognized by standard CA and application throws error.  To suppress the error following modification to made to client side code.

Note: This steps is not required, If Service is configured with valid SSL certificate.

a)     Add following class to client solution

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Net;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;
public static class CertificateUtils
        /// <summary>
        /// Sets the cert policy.
        /// </summary>
        public static void SetCertificatePolicy()
            += RemoteCertificateValidate;
        /// <summary>
        /// Remotes the certificate validate.
        /// </summary>
        private static bool RemoteCertificateValidate(
        object sender, X509Certificate cert,
        X509Chain chain, SslPolicyErrors error)
            // trust any certificate!!!
           // System.Console.WriteLine(“Warning, trust any certificate”);
            return true;

a)     Add the following code only once before making service call. This would suppress the certificate error.


Configuring The ACS Management Portal

This sample illustrates how to implement federated authentication using ACS and an active Directory Federation Services (AD FS) 2.0 identity provider with a WCF relying party web service. The sample includes a WCF service and a WCF client as command line applications. The WCF service requires that clients authentication using a SAML token from ACS, which is obtained via another SAML token acquired from an AD FS 2.0 identity provider. The web service client requests a SAML token from AD FS 2.0 using Windows Authentication, and then exchanges this token for the ACS token required to access the WCF service.


To run this sample, you will need:

  • To create an account at and create an Access Control Service namespace.
  • Visual Studio 2010
  • Windows Server 2008
  • AD FS 2.0 and its requirements

 System Requirements For Development

  • Visual Studio 2010
  • .NET Framework 4.0 or .NET Framework 3.5 SP1 with KBs 976126 or 976127 applied
  • Windows Identity Foundation SDK

Windows Azure Account Requirements

To use ACS, you must first obtain a Windows Azure subscription by browsing to the Windows Azure AppFabric Management Portal and signing up. Once you have a subscription, on the Windows Azure AppFabric Management Portal, browse to the Service Bus, Access Control, and Caching section and create an Access Control Service namespace.

Platform Compatibility

ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby. ACS can be accessed from applications that run on almost any operating system or platform that can perform HTTPS operations.

Configuring the Sample

The ACS configuration required for this sample can be performing using either the ACS management portal, or the ACS management service.   Select one of the two options below to go to the relevant section.

  • Option 1: Configuring via the ACS Management Portal
  • Option 2: Configuring via the ACS Management Service

Note that since I am using AD FS 2.0 as the federation server, AD FS 2.0 must be installed and running.

For more information about installing AD FS 2.0, see

Configuring via the ACS Management Portal

    Step 1 : Open a browser and navigate to and sign in. From there, navigate to the Service Bus, Access Control, and Caching section to configure your ACS service namespace. Once you have created a namespace, select it and click Manage > Access Control Service at the top of the page. This should launch the following page  in a new window

Step 2:   Next, add your AD FS 2.0 identity provider. To do this, you will need to have your WS-Federation metadata document, which is hosted in your AD FS 2.0 server at /FederationMetadata/2007-06/FederationMetadata.xml. For example, if your AD FS 2.0 server is installed on a computer with the name, then the metadata URL will be:

   if the computer running AD FS 2.0 is accessible from internet and not placed behind a firewall, then you can use this URL directly. Otherwise, you will need to save this document to your computer and upload it to ACS when adding your identity provider.

Step 3:     Click Identity Provider in the left panel and then click Add.

Step 4 : Select WS-Federation identity provider and click Next. Depending on the Metadata document’s location, complete the form either entering the URL or using the saved file.

Step 5 :  Next, register your application with ACS by creating a relying party application. Click the Relying Party Applications link on the main page, then click Add and enter the following information in the subsequent form.

  • In the Name field, enter some name which you want for example “Federation Sample “
  • In the Realm field, enter your app url ex:  http://localhost:7200/Service/Default.aspx
  • In the Token format field, select SAML 2.0
  • In the Token encryption policy field, select “Require Encryption”
  • In the Identity Providers field, check only the AD FS 2.0 identity provider added in the previous step
  • For Token signing, select “Use a dedicated certificate”. For the certificate file, browse for the ACS2SigningCertificate.pfx file in the Certificates folder of this sample. Enter a password of “password”.
  • For the Token encryption certificate, browse for the WcfServiceCertificate.cer file in the Certificates folder of this sample and save the settings.

Step 6      When complete, click the Save button and then navigate back to the main page.

Step 7 :  With your relying party registered, it is now time to create the rules that determine the claims that ACS will issue to your application. To do this, navigate to the main portal page and select Rule Groups. From there, select the Default Rule Group for Federation Sample RP. Click Generate and then select AD FS 2.0 in the subsequent form. Complete the form by clicking on the Generate button. This will create passthrough rules fo AD FS 2.0 based on the claim types present in the WS-Federation metadata.

Step 8:  Now it is time to add the decryption certificate. This certificate is needed for ACS to decrypt incoming tokens from the AD FS 2.0 identity provider. To do this, click Certificates and keys in the left panel, and click the Add link for Token Decryption.

Step 9:  In the Certificate field of the subsequent form, browse to Certificates folder of this sample and pick ACS2DecryptionCert.pfx. The password for this certificate is “password”.

Step 10: Complete the form by clicking Save.