Secure Azure Web Role ASP.NET Web Application Using Access Control Service v2.0

Artículo
1/17/2024

Introduction

This article walks you through creating an Azure Web Role ASP.NET application protected using Windows Azure AppFabric Access Control Service v.2.0. After completing this walkthrough you will have a web application running in Windows Azure production environment that requires authentication using Windows Live ID or Google account. Live demo is available here https://wawithacsv2.cloudapp.net/

As a prerequisite of completing this walk through you should have an active Windows Azure account (sign up here, fees apply) and active Windows Azure AppFabric labs account (sign up free here)

Summary of steps

Step 1 – Create Azure Web Role ASP.NET application project in Visual Studio 2010

Content in this step adopted and adapted from Code Quick Launch: Create and deploy an ASP.NET application in Azure.

To create and run an ASP.NET service for Azure

Launch Microsoft Visual Studio 2010 with administrator privileges. To launch Visual Studio with administrator privileges, right-click Microsoft Visual Studio 2010 and then click Run as administrator.
On the File menu, click New, and then click Project.
Within the New Project dialog, navigate to Installed Templates, Visual C#, and click Cloud.
Click Windows Azure Project. If needed, modify the Location: field, which indicates where your solution will be stored. Click OK to close the New Project dialog.
Within the New Windows Azure Project dialog, navigate to Visual C#, click the ASP.NET Web Role, and then click the > symbol. This will add a web role to your Windows Azure solution. A web role provides an environment for running web sites or applications as supported by Internet Information Services (IIS) 7.0. Click OK to close the New Windows Azure Project dialog.
[Optional] At this point you could compile and run the application. However, you could also customize the text displayed in the web page by modifying Default.aspx. This won’t fundamentally change the application, but it will show you how similar this application is to a traditional (non-cloud) ASP.NET application. To modify Default.aspx, open Solution Explorer. If Solution Explorer is not visible, from the View menu click Solution Explorer. Within Solution Explorer, expand WebRole1 and double-click Default.aspx. Modify the Welcome to ASP.NET! text to become Welcome to ASP.NET in Windows Azure!. Save and close Default.aspx.
Compile and run the service by clicking Debug from the menu and then clicking Start Without Debugging.

Assuming no compile errors or client machine errors, at this point you should have the service successfully running in the local development environment.

Step 2 – Create and configure ASP.NET web application as relying party in ACS v2 Management Portal

Content in this step adopted and adapted from How To: Create My First Claims Aware ASP.NET application Integrated with ACS v2

If you have not created Windows Azure AppFabric project follow the steps below. If you already created Windows Azure AppFabric Project you can skip to creating a namespace which is next.

To create a Windows Azure AppFabric project

Navigate to https://portal.appfabriclabs.com/ [this is lab environment and will change when shipped to production]
If you were not authenticated using Windows Live ID you will be required to do so.
After being authenticated with your Windows Live ID you are redirected to My Projects page on the Windows Azure AppFabric portal.
Click the create a project link.
On the Sign Up page type your project name in the text box, and the click OK. The project name is a logical container that will hold your namespaces. The project name will not appear publicly in any way.
You should be redirected back to My Projects page.
You should see your project created and listed, and its status should be Active.

If you have not created Windows Azure AppFabric namespace follow the steps below. If you already created Windows Azure AppFabric namespace you can skip to launching Access Control management portal which is next.

To create namespace within your Windows Azure AppFabric project

Navigate to https://portal.appfabriclabs.com/. [this is lab environment and will change when shipped to production]
If you were not authenticated using Windows Live ID you will be required to do so.
After being authenticated with your Windows Live ID you are redirected to My Projects page on the Windows Azure AppFabric portal.
Click the desired project name on the My Project page.
Click the Add Service Namespace link.
Type the desired namespace name in the text box, and click the Validate Name link. The namespace will appear as a subdomain names in the list of URLs. It should be unique and it is publicly visible.
If the name space is available—click the Create button.
You should be redirected to the project’s details page
Note that your new namespace shows under Service Namespace and its status is Active.

To launch the ACS v2.0 Management Portal

On the Project page, once the service namespace you created in Step 2 is active, click Access Control.

You are redirected to the page that displays your project ID, allows you to delete the Service Namespace, or launch the ACS v2.0 Management Portal.
To launch the ACS v2.0 Management Portal, click Manage Access Control.

This section describes how to add identity providers to use with your relying party application for authentication. Identity Provider is a service that lets end users authenticate themselves to your application. For more information about identity providers, see Identity Providers.

To add identity provider

On the ACS v2.0 Management Portal, click Identity Providers.
On Identity Providers page, click Add Identity Provider, and then click Add button next to Google, doing so your users will be able to authenticate to your Web Application using their Google credentials. You can optionally choose other Identity Providers such as Live ID, Facebook, Yahoo!
The Add Google Identity Provider page prompts you to enter a login link text (the default is Google) and an image URL. This URL points to a file of an image that can be used as the login link for this identity provider (in this case, Google). Editing these fields is optional. For this demo, do not edit them, and click Save.
On Identity Providers page, click Return to Access Control Service to go back to the ACS v2.0 management portal main page.

This section describes how to setup a Relying Party Application. In ACS v2.0, a Relying Party Application is a projection of your web application into the system. It defines the URLs for your application, token format preference, token timeout, token signing options, and token encryption options. For more information about relying party applications, see Relying Party Applications

To setup a relying party application

On the ACS v2.0 Management Portal, click Relying Party Applications.
On Relying Party Applications page, click Add Relying Party Application.
On Add Relying Party Application page, do the following:
1. In Name, type the name of the relying party application. For example, type Azure Web App.
2. In Mode, select either Enter settings manually.
3. In Realm, type the URI that the security token issued by ACS v2.0 applies to. It should be the URL of your Azure Web Application. Return to your cloud project in Visual Studio 2010. Run the application using Ctrl+F5 (not right click, Browse on the Default.aspx page). When the application appears in the browser, copy the URL and paste to the Realm filed. Similar to this: http://127.0.0.1:81/. This should work for Compute Emulator – your desktop cloud dev environment - but it would change when moving to Windows Azure environment.
4. In Return URL, type the URL that ACS v2.0 returns the security token to. Use same URL as for Realm field.
5. In Token format, select a token format for ACS v2.0 to use when issuing security tokens to this relying party application. For this demo, select SAML 2.0. For more information about SAML tokens, see Token Formats Supported in ACS v 2.0.
6. In Token encryption policy, select an encryption policy for tokens issued by ACS v2.0 for this relying party application. For this walkthrough, accept the default value of None. For more information about token encryption policy, see Certificates and Keys.
7. In Token lifetime (secs):, specify the amount of time for a security token issued by ACS v2.0 to remain valid. For this walkthrough, accept the default value of 600. For more information about tokens, see Token Formats Supported in ACS v 2.0.
8. In Identity providers, Select the identity providers to use with this relying party application. For this demo, accept the checked defaults (Google and Windows Live ID). For more information about relying party applications, see Identity Providers.
9. In Rule groups, select rule groups for this relying party application to use when processing claims. For this demo, accept Create New Rule Group that is checked by default. For more information about rule groups, see Rules, Rule Groups, and Token Transformation.
10. In Token signing, select whether to sign SAML tokens using the default service namespace certificate, or using a custom certificate specific to this application. For this demo, accept the default value of Use service namespace certificate (standard). For more information about token signing, see Certificates and Keys.
Click Save.
On Relying Party Applications page, click Return to Access Control Service to go back to the ACS v2.0 management portal main page.

This section describes how to define rules that drive how claims are passed from identity providers to your relying party application. For more information about rules and rule groups, see Rules and rule groups.

To create rules

On the ACS v2.0 Management Portal main page, click Rule Groups.
On Rule Groups page, click Default Rule Group for Azure Web App (since you named your relying party application Azure Web App).
On Edit Rule Group page, click Generate Rules.
On Generate Rules: Default Rule Group for Azure Web App page, accept the identity providers selected by default (in this walkthrough, Google and Windows Live ID), and then click Generate.
On Edit Rule Group page, click Save.
On Rule Groups page, click Return to Access Control Service to return to the main page of the ACS v2.0 management portal.

You can find all the information and code necessary to modify your relying party application to work with ACS v2.0 on the Application Integration page. You will use this information when configuring your cloud web application for federated authentication.

To view the Application Integration page

On the ACS v2.0 Management portal main page, click Application Integration.
The ACS URIs that are displayed on the Application Integration page are unique to your service namespace.
For this walkthrough, it is recommended to keep this page open in order to perform future steps quickly.
Copy the URI next to WS-Federation Metadata. You will using it in your cloud web project when adding STS (Security Token Service) Reference in the next step. It should look similar to the following:

https://YOURNAMESPACE.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml

Step 3 – Configure Windows Azure Web Role ASP.NET project for federation with ACS v2

Content in this step adopted and adapted from Code Quick Launch: Create and deploy an ASP.NET application in Windows Azure.

This section describes how to integrate ACS v2.0 with the Windows Azure Web Role ASP.NET cloud application that you created in step 1. The essence of the step is configuring trust between the ASP.NET application (Relying Party) and ACS v2.0.

To configure trust between the ASP.NET Relying Party Application and ACS v2.0

In Visual Studio 2010, in Solution Explorer for Azure Web App, right-click Azure Web App and select Add STS Reference.
In Federation Utility wizard, do the following:
1. On Welcome to the Federation Utility Wizard page, in Application URI, enter the application URI and then click Next. In this walkthrough, the application URI is http://127.0.0.1:81/. Yours will be different, Compute Emulator assigns dynamic ports you cannot control, and “it is not possible to allocate unique IP address.”
2. Note: The trailing slash is important because it matches the value you entered in ACS v2.0 Management Portal for your relying party application in previous step.
3. A warning pops up: ID 1007: The Application is not hosted on a secure https connection. Do you wish to continue? For this walkthrough, click Yes.
4. Note: In a production environment, this warning about using SSL is valid and should not be dismissed.
5. On Security Token Service page, select Use Existing STS, enter the WS-Federation Metadata URL published by ACS v2, and then click Next. This is the URL you copied last in the previous step, it should look similar to the following:"
  
  https://YOURNAMESPACE.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml
6. On STS signing certificate chain validation error page, click Next.
7. On Security token encryption page, click Next.
8. On Offered claims page, click Next.
9. On Summary page, click Finish.
Once you successfully finish running the Federation Utility wizard, it adds a reference to the Microsoft.IdentityModel.dll assembly and writes values to your Web.config file that configures the Windows Identity Foundation in your ASP.NET MVC 2 Web Application (TestApp).
Open Web.config and locate the main system.web element. It should look like the following:
```
<system.web>
    <authorization>
      <deny users="?" />
    </authorization>
```
Modify Web.config to enable request validation by adding the following code under the main system.web element:
```
    
    <httpRuntime requestValidationMode="2.0"/>
```

After you perform the update, this is what the above code fragment must look like:

   <system.web>
    <!--set this value-->
    <httpRuntime requestValidationMode="2.0"/>
    <authorization>
    <deny users="?" />
    </authorization>

Test your work using Ctrl+F5 to run the application using Compute Emulator. Here is what you should expect:
1. The browser opens and you are navigated to a Home Realm Discovery (HRD) page which displays Windows Live ID and Google as and options for your authentication.
2. Click on any of these, you will be redirected to a familiar for your authentication page. Either Google or Live.com.
3. After successful authentication you will be automatically redirected to your ASP.NET Web application��s default page.
4. Note: If you have chosen Google for authentication you will be presented with additional page that requires your consent – agree by clicking on allow button.

Step 4 – Prepare ASP.NET cloud web application’s dependencies to be deployed to Windows Azure Environment

Content in this step is adapted from Exercise 1: Enabling Federated Authentication for ASP.NET applications in Windows Azure

This step helps you prepare your ASP.NET cloud web application to be deployed to Windows Azure with its prerequisites such as WIF assembly. WIF runtime is not installed as part of Windows Azure environment. It also helps creating and configuring server certificates to enable secure communications over SSL. Server certificate is also required for WIF related functions work properly on Windows Azure.

To prepare application’s dependencies to be deployed to Windows Azure

Switch to your solution in Visual Studio 2010.
Add reference to the Microsoft.IdentityModel assembly To add the reference right click on Reference folder in the solution explorer, choose Add Reference…, Click on .Net tab, locate and choose the Microsoft.IdentityModel assembly from the list and click OK.
Locate and choose the referenced assembly, Microsoft.IdentityModel, in the References folder.
Click F4 to bring up the assembly’s properties window.
In the Properties window specify Copy Local to true and Specific Version to false.
Open global.asax.cs code behind file.

Add the following using declarations:

using Microsoft.IdentityModel.Tokens;
using Microsoft.IdentityModel.Web;
using Microsoft.IdentityModel.Web.Configuration;

Add the following code to it (note, that you may already have Application_Start event handler added to it, just update it) . The reason for the following code is that by default the cookies are protected using DPAPI which is not available in Azure environment.

void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
{
    //
    // Use the <serviceCertificate> to protect the cookies that are
    // sent to the client.
    //
    List<CookieTransform> sessionTransforms =
        new List<CookieTransform>(new CookieTransform[] {
        new DeflateCookieTransform(), 
        new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
        new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)  });
    SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
    e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}

void Application_Start(object sender, EventArgs e)
{
    FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
}

The following procedure will help you create self signed certificate and configure it for Compute Emulator and the application’s usage

To create and configure self signed certificate

Open IIS Manager MMC by clicking on Windows button on the task bar and typing IIS Manager (case is not important). You should see Internet Information Services (IIS) Manager appears in search results. Click it to open the Manager.
When the IIS Manager appears type cert in the Filter: text area at the top middle of the screen. It should leave only Server Certificates option. Run it by double clicking on it.
On the right-hand side, on the Actions pane, click on Create Self-Signed Certificate… option.
In the dialog specify friendly name for your certificate and click OK to dismiss it.

This procedure will help you configure the certificate for usage in your Compute Emulator.

To configure certificate for Compute Emulator

Switch to your solution in Visual Studio.
Right click on the web role under Roles folder in Solution Explorer and choose Properties option.
Click on the Certificates tab.
Click on Add Certificate.
The new row appears.
Type the certificate’s arbitrary name in the Name field.
Leave Store Location value LocalMachine.
Leave Store value My.
In the Thumbprint field click on ellipses (...), you should see list of the certificates. Locate the one you have created in previous step and click OK. Thumbprint field shows the certificate’s thumbprint.
Save your work using Ctrl+S.
Select and copy the thumbprint into clipboard using Ctrl+C. You will use it for configuring WIF related sections in web.config.

This procedure will help you configure Windows Azure Role’s Endpoint to use the certificate for SSL/HTTPS communications.

To configure Windows Azure Role’s Endpoint for SSL/HTTPS

While in the Web Role Properties page click on Endpoints tab.
Click on Add Endpoint option at the top, new row appears.
Type new endpoint’s arbitrary name in the Name filed.
Specify Type value of Input.
Specify Protocol value of SSL.
Specify Public Port arbitrary value. Note: Compute Emulator cannot be configure for specific IP addresses and ports, so if the IP address and port value are unavailable the Compute Emulator will assign its own. You want to avoid this since you need exactly to know the IP address and the port as it needs to be specified in exact way in ACSv2 portal. To identify used ports on local machine open command prompt and run the following command netstat –a –n | findstr 127.0.0.1. use the one that is not listed there.
In the SSL Certificate Name specify the certificate you have just configured in previous step.
Save your work by using Ctrl+S.

Next procedure will help you configure the certificate for usage by WIF related functionality.

To configure certificate for WIF functionality

Open web.config file and locate microsoft.identityModel/service section.

Add the following markup to the section. For the findValue value specify the thumbprint value from the previous step.

<serviceCertificate>
  <certificateReference x509FindType="FindByThumbprint" findValue="YOURTHUMBPRINTFROMPREVSTEP" storeLocation="LocalMachine" storeName="My" />
</serviceCertificate>

Locate audienceUris/add section and change the value reflecting on the changes you have done. Change http to https change the port number according to what you have specified in the previous step.
Locate federatedAuthentication/wsFederation section and change the realm to the same value as in audienceUris.

This procedure helps you configure your ACS v2.0 configuration to proper values. Since the URL changed (HTTPS vs. HTTP and the port number) it needs also to be updated in the ACS v2.0 Management Portal

To update your relying party configuration on ACS v2.0 Management Portal

Log on to ACS v2.0 Management Portal at https://portal.appfabriclabs.com/
Click on the Service Bus, Access Control & Caching on the left.
Click on the Access Control in the tree under AppFabric node.
You should see the list of your namespaces.
Click on desired namespace you configured in previous steps.
Click on the Access Control Service ribbon at the top of the page, new page or tab will open.
Click on the Relying Party Applications link on the left.
Your replying parties should be listed.
Click on desired replying party you configured earlier, you should be presented with Edit Relying Party Application page.
Change the Realm and the Return URL fields to the values reflecting recent changes. It should match audienceUris and realm you specified configuring web.config in previous step.
Click Save button to save your changes.

This procedure will help you configure permissions for the application to access your certificate. The application by default runs in application pool under Network Service account. You need to grant permissions to this account so that it can use the certificate.

To grant certificate access permissions to application pool account

Click on the Windows button on the taskbar and type mmc. You should see mmc.exe appears in search results. Click on it.
When the MMC console appears, click on** File** and then on Add/Remove Snap-in… option.
In the available snap-ins list choose** Certificates** and click on Add > button.
In the dialog box choose Computer Account option and click Next button.
On the Select Computer wizard page choose **Local computer: (the computer this console is running on)**option and click Finish.
Expand Console Root folder.
Expand Certificates (Local Computer) folder.
Expand Personal folder.
Click on Certificates folder to list the available certificates.
Locate your certificate, right click on it and choose All Tasks option and then click on Manage Private Keys... option.
Add Network Service account to the list under Group or user names: section and click OK button.

This procedure tests your configuration and validates its readiness to be deployed to Windows Azure environment.

To test readiness for Windows Azure deployment

Switch to your solution in Visual Studio.
Run your application using Ctrl+F5.
You should be presented with certificate warning. Accept it. It happens since we are using self signed certificated.
You should be redirected to Home Realm Discovery page presetting Google or Windows Live id options.
Use any of these.
Upon successful authentication you should be presented with your Default.aspx page

Step 5 – Deploy your solution to Windows Azure

Content in this step adopted and adapted from Code Quick Launch: Create and deploy an ASP.NET application in Windows Azure.

In this step you will deploy the application to the cloud using the Windows Azure management portal. First you’ll need to create a service and a service configuration file, called service package, and then upload it to Windows Azure environment using Windows Azure management portal.

To create service package and upload it to Windows Azure environment

In Visual Studio’s Solution Explorer, right-click the project name (the one that’s above Roles folder) and then click Publish….
Within the Deploy Windows Azure project dialog, click Create Service Package Only, then click OK.
Assuming successful compilation, Visual Studio will open a folder that contains two files created as part of the publish process. The files are ServiceConfiguration.cscfg (which we discussed earlier in this topic) and <YourProjectName>.cspkg (such as WindowsAzureProject1.cspkg). The .cspkg extension is for service package files. A package file contains the service definition as well as the binaries and other items for the application being deployed. Make a note of the path to these files, as you’ll be prompted for the path when you deploy the application using the Windows Azure management portal.
Log in to the Windows Azure management portal to deploy the application. Log in at http://windows.azure.com/.
Within the Windows Azure management portal, click Hosted Services, Storage Accounts & CDN.
Click New Hosted Service.
Select a subscription that will be used for this application.
Enter a name for your application. This name is used to distinguish your services within the Windows Azure management portal for the specified subscription.
Enter the URL for your application. The Windows Azure management portal ensures that the URL is unique within the Windows Azure platform (not in use by anyone else’s applications). Note: this is the URL that needs to be then updated in both ACS v2.0 management portal for that relying party’s realm and return URL and in the application’s web.config audienceUri and realm.
Choose a region from the list of regions.
Choose Deploy to stage environment.
Ensure that Start after successful deployment is checked.
Specify a name for the deployment.
For Package location, click the corresponding Browse Locally… button, navigate to the folder where your <YourProjectName>.cspkg file is, and select the file.
For Configuration file, click the corresponding Browse Locally… button, navigate to the folder where your ServiceConfiguration.cscfg is, and select the file.
Click on Add Certificate button to add your certificate to be deployed, but first you need to export the certificate into file. To export the certificate into file follow these steps:
1. Open mmc console by first clicking on** Windows** button in task bar and typing mmc. You should see mmc.exe appears in search results. Click on it.
2. When mmc console appears click on File option and then on Add/Remove Snap-in… option.
3. In the Add or Remove Snap-ins dialog box choose Certificates from the available snap-ins list and click on Add> button.
4. Choose Computer Account option and click Finish button.
5. In the Select Computer wizard page select Local Computer (the computer this console is running on) and click Finish button. The click OK button.
6. Expand Console Root folder.
7. Expand Certificates(Local Computer) folder.
8. Expand Personal folder.
9. Click on Certificates folder to list available certificates.
10. Locate your certificate in the list.
11. Right click on the certificate and choose** All Tasks** and then Export… option.
12. Click** Next** on the welcome page of the wizard.
13. On the** Export Private Key** page choose Yes, export the private key option and click Next button.
14. On the** Export File Format** leave the default option which is** Personal Information Exchange - PKCS #12 (.PFX)** and click Next button.
15. On the Password page of the wizard specify password. You will need it when uploading the certificate to Windows Azure environment via management portal.
16. On the File to Export page of the wizard specify destination file and click Next button. Make a note where you are saving the file. Note, since the certificate being exported has private key extra care should be taken to not exposing it to the public. It’s best if you delete the file altogether after uploading it to Windows Azure environment.
17. Click Finish to complete the wizard. You should be presented with The export was successful message, click OK button to dismiss the message.
Switch back to Windows Azure management portal where you opened a dialog box to locate your certificate (.PFX) file and locate the certificate file you have just exported.
Specify the password for your certificate in the Certificate Password field.
Click OK. You will receive a warning after you click OK because there is only one instance of the web role defined for your application (this setting is contained in the ServiceConfiguration.cscfg file). For purposes of this walk-through, override the warning by clicking Yes, but realize that you likely will want more than one instance of a web role for a robust application.

You can monitor the status of the deployment in the Windows Azure management portal by navigating to the Hosted Services section. Because this was a deployment to a staging environment, the DNS will be of the form http://<guid>.cloudapp.net. You can see the DNS name if you click the deployment name in the Windows Azure management portal (you may need to expand the Hosted Service node to see the deployment name); the DNS name is in the right hand pane of the portal. Once your deployment has a status of Ready (as indicated by the Windows Azure management portal), you can enter the DNS name in your browser (or click it from the Windows Azure management portal) to see that your application is deployed to the cloud.

Although this walk-through was for a deployment to the staging environment, a deployment to production follows the same steps, except you pick the production environment instead of staging. A deployment to production results in a DNS name based on the URL of your choice, instead of a GUID as used for staging.

If this is your first exposure to the Windows Azure management portal, take some time to familiarize yourself with its functionality. For example, similar to the way you deployed your application, the portal provides functionality for stopping, starting, deleting, or upgrading a deployment.

http://i.msdn.microsoft.com/gg651132.Important(en-us,MSDN.10).gifImportant

Assuming no issues were encountered, at this point you have deployed your Windows Azure application to the cloud. However, before proceeding, realize that a deployed application, even if it is not running, will continue to accrue billable time for your subscription. Therefore, it is extremely important that you delete unwanted deployments from your Windows Azure subscription. To delete the deployment, use the Windows Azure management portal to first stop your deployment, and then delete your deployment. These steps take place within the Hosted Services section of the Windows Azure management portal: Navigate to your deployment, select it, and then click the Stop icon. After it is stopped, delete it by clicking the Delete icon. If you do not delete the deployment, billable charges will continue to accrue for your deployment, even if it is stopped.
Publish to production clicking on you deployment node so that Swap VIP ribbon appears.
Click on Swap VIP ribbon and then OK button. The deployment to production should take couple of minutes.

In the next procedure you will update the the package and the ACSv2 to reflect on the address changes from staging environment to production.

To update the package and ACS v2.0 configuration to reflect on production environment

Switch back to your solution in Visual Studio.
Open web.config and change audienceUri and realm to reflect on the changes you made when switching from staging to production environment.
In the Solution Explorer right clock on the role (right above the roles folder) and click on Publish option republish the package with the changes in web.config. You cannot update just web.config, you need to create the new package.
Switch to Windows Azure management portal.
Click on the role so that you see the Upgrade ribbon appears in the tool bar, click on the ribbon and provide path to newly created package and configuration files in Package Location: and Configuration File: fields respectively.
Click OK button. The update should take several minutes.
Go to ACS v2.0 portal and update realm and return URL of the relying party to reflect the changes you made when switching from staging to production, these values should match audienceUris and realm values in the web.config.

Next procedure helps you to verify your application is functional when running in Windows Azure environment.

To verify the application is functional and running in Windows Azure environment

Navigate to your production URL of your application. Make sure that you use SSL (HTTPS) and use the right port you configured in the package.
You should be redirected to the Home Realm Discovery (HRD) page presenting you with two options – Windows Live ID and Google.
Choose one of them to authenticate yourself.
Upon successful authentication you will be redirected to your Default.aspx page.

Compartir a través de