Dette innholdet er ikke tilgjengelig på ditt språk, men her er den engelske versjonen.
This documentation is archived and is not being maintained.

Deploying ACS Federated Applications and Service To Azure

Updated: June 19, 2015

  • Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS)

  • Windows Identity Foundation (WIF)

  • Microsoft Azure

This topic consolidates the guidelines that you should take into account when you develop applications and services that use ACS and that will be deployed to Azure.

  1. Work around dynamically generated ports with Compute Emulator.

  2. Deploy Windows Identity Foundation (WIF) runtime to Azure.

  3. Encrypt cookies using RSA.

  4. Configure assemblies invoked through reflection to be deployed to Azure.

This section is relevant when you create web applications. It is not relevant when you create web services. Compute Emulator is part of Azure SDK tools. You can use it to run, test, debug, and fine-tune your application before you deploy it as a hosted service to Azure. In Compute Emulator, it is not possible to allocate a unique IP address. Compute Emulator attempts to assign the requested port. If that port is not available, it allocates the next best available port number. This means that in the Compute Emulator, your service might be assigned a different port number from the port number that you specified in the definition file. For more information about Compute Emulator, see Overview of the Windows Azure Compute Emulator (http://go.microsoft.com/fwlink/?LinkId=221212).

If Compute Emulator allocates an IP address different from the IP address that is configured as the Return URL in the ACS Management Portal, ACS will redirect authenticated requests to the URL that is configured in the Return URL field of the relying party configuration, but no matching page in this URL will exist. As a result you will be presented with blank page.

To work around this behavior, configure your cloud web application’s endpoint public port to a port that is available on your computer. Then, Compute Emulator will not assign a random port to avoid a collision.

  1. To open the command prompt, click Start, type cmd, and then press Enter.

  2. Run the following command to display the list of local host IP addresses with used ports: netstat –a –n | findstr

  3. Scan through the list, and identify a port that is not currently in use. You will use this port in the following steps.

  4. In Solution Explorer, double-click your role, which is located under the Roles folder in the cloud project. The role properties page opens.

  5. On the Web Role Properties page, click the Endpoints tab.

  6. In the Public Port  file, specify the port value that you identified in Step 3.

  7. To save your work, press Ctrl+S.

Windows Identity Foundation (WIF) is an out-of-band runtime that must be installed on the computer so that your claims-aware application can use it. WIF is not installed by default on Azure instances. To run your cloud claims-aware application, you must make WIF runtime available on the Azure instance. The easiest way is to do this is to include the WIF assembly with the deployment package.

  1. In the Solution Explorer, locate your claims-aware application.

  2. Expand the References folder.

  3. Locate the Microsoft.IdentityModel assembly under the References folder.

  4. Right-click the assembly, and then click Properties.

  5. In the properties window, specify Copy Local  as True and Specific Version as False.

This section is relevant when you create web applications. By default, WIF protects cookies cryptographically using data protection application programming interfaces (DPAPI). DPAPI is not available on Azure. To make sure that your cloud claims-aware web application functions correctly when it is deployed to Azure, you must add cookies encryption functionality using RSA.

  1. In the Solution Explorer, locate your cloud claims-aware web application.

  2. Open the global.asax.cs file, which is the code behind the global.asax file, in the Visual Studio editor.

  3. Add the following declarations:

    using Microsoft.IdentityModel.Tokens;
    using Microsoft.IdentityModel.Web;
    using Microsoft.IdentityModel.Web.Configuration;
  4. Add the following code:

    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());
    void Application_Start(object sender, EventArgs e)
        FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
    If you have already added the Application_Start event handler, you can update it to include this code.

  5. Save your work.

In some cases, assemblies are invoked through reflection, for example, when developing Representational State Transfer (REST) wcf services or HttpModules that inspect incoming SWT tokens. To make sure these assemblies are deployed to Azure, you must perform extra steps to add them to the deployment package.

  1. Expand the bin folder of the cloud claims-aware web application or service.

  2. Right-click the assembly, and then click Include In Project.

  3. Right-click the same library, and then click Properties.

  4. In the Properties window, click Copy if newer for the Copy to Output Directory.

See Also