CloudCasts Blog

Webcasts in the Cloud
posts - 131 , comments - 71 , trackbacks - 120

My Links

News

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

Bloggers Guides

Website Authentication with Social Identity Providers and ACS Part 3 - Deploying the Relying Party Application to Windows Azure Websites

In the third of the series looking at website authentication with social identity providers I’ll focus on deploying the relying party application to a Windows Azure Website. This will require making some configuration changes in the management console in ACS, and the web.config file, and also changing the way that session cookies are created

The other parts of this series are here:

Website Authentication with Social Identity Providers and ACS Part 1

Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider

The relying party website has now been developed and tested in a development environment. The next stage is to deploy the application to Windows Azure Websites so that users can access it over the internet. The use of the universal profile provider and a Windows Azure SQL Database as a store for the profile information means that no changes in the database or configuration will be required when migrating the application.

Creating a Windows Azure Website

The first step is to create a Windows Azure Website in the Azure management portal. The following screenshot shows the creation of a new website with the URL of relyingpartyapp.azurewebsites.net in the West Europe region.

image

Note that the URL of the website must be unique globally, so if you are working through this solution, you will probably have to choose a different URL.

Configuring a Relying Party Application

With the website created, the relying party information will have to be configured for Windows Azure Active Directory Access Control, formally known as Windows Azure Access Control Service, (ACS). This is because the relying party configuration is specific to the URL of the website.

One option here is to create a new relying party with the URL of the Windows Azure Website, which will allow the testing of the op-premise application as well as the Azure hosted website. This will require the existing identity providers and rules to be recreated and edited for the new application. A quicker option is to modify the existing configuration, which is what I will do here.

The existing relying party application is present in the relying party applications section of the ACS portal.

image

In order to change the configuration for the host application the name, realm and return URL values will be changed to the URL of the Windows Azure Website URL (http://relyingpartyapp.azurewebsites.net/). The screenshot below shows these changes.

image

For consistency, the name of the rule group will also be changed appropriately.

image

With these changes made, ACS will now function for the application when it is hosted in Windows Azure Websites.

 

Configuring the Relying Party Application

For the relying party application website to integrate correctly with ACS, the URL for the website will need to be updated in two places in the web.config file. The following code highlights where the changes are made.

<system.identityModel>

  <identityConfiguration>

    <claimsAuthenticationManager type="RelyingPartyApp.Code.CustomCam, RelyingPartyApp" />

    <certificateValidation certificateValidationMode="None" />

    <audienceUris>

      <add value="http://relyingpartyapp.azurewebsites.net/" />

    </audienceUris>

    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

      <trustedIssuers>

        <add thumbprint="B52D78084A4DF22E0215FE82113370023F7FCAC4" name="https://acsscenario.accesscontrol.windows.net/" />

      </trustedIssuers>

    </issuerNameRegistry>

  </identityConfiguration>

</system.identityModel>

<system.identityModel.services>

  <federationConfiguration>

    <cookieHandler requireSsl="false" />

    <wsFederation

      passiveRedirectEnabled="true"

      issuer="https://acsscenario.accesscontrol.windows.net/v2/wsfederation"

      realm="http://relyingpartyapp.azurewebsites.net/"

      requireHttps="false" />

  </federationConfiguration>

</system.identityModel.services>

 

 

 

Deploying the Relaying Party Application to Windows Azure Websites Website

The next stage is to deploy the relying party application can be deployed to Windows Azure Websites. Clicking the download publish profile link will allow a publish profile for the website to be saved locally, this can then be used by Visual Studio to deploy the website to Windows Azure Websites.

image

Be aware that the publish profile contains the credential information required to deploy the website, this information is sensitive, so adequate precautions must be taken to ensure it stays confidential.

To publish the relying party application from Visual Studio, right-click on the RelyingPartyApp project, and select Publish.

image

Clicking the Import button will allow the publish profile that was downloaded form the Azure management portal to be selected.

image

When the publish profile is imported, the details will be shown in the dialog, and the website can be published.

image

After publication the browser will open, and the default page of the relying party application will be displayed.

image

Testing the Application

In order to verify that the application integrates correctly with ACS, the login functionality will be tested by clicking on the member’s page link, and logging on with a Yahoo account. When this is done, the authentication process takes place successfully, however when ACS routes the browser back to the relying party application with the security token, the following error is displayed.

image

Note that I have configured the website to turn off custom errors.

<system.web>

  <customErrors mode="Off"/>

  <authorization>

    <!--<deny users="?" />-->

  </authorization>

  <authentication mode="None" />

 

The next section will explain why the error is occurring, and now the relying party application can be configured to resolve the error.

Configuring the Machine Key Session Security Token Handler

The default SessionSecurityTokenHandler used by WIF to create a secure cookie is not supported in Windows Azure Websites. The resolution for this is to configure the MachineKeySessionSecurityTokenHandler to be used instead. This is configured in the identityConfiguration section of the system.identityModel configuration for the website as shown below.

<system.identityModel>

  <identityConfiguration>

    <securityTokenHandlers>

      <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

      <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

    </securityTokenHandlers>

    <claimsAuthenticationManager type="RelyingPartyApp.Code.CustomCam, RelyingPartyApp" />

    <certificateValidation certificateValidationMode="None" />

    <audienceUris>

      <add value="http://relyingpartyapp.azurewebsites.net/" />

    </audienceUris>

    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

      <trustedIssuers>

        <add thumbprint="B52D78084A4DF22E0215FE82113370023F7FCAC4" name="https://acsscenario.accesscontrol.windows.net/" />

      </trustedIssuers>

    </issuerNameRegistry>

  </identityConfiguration>

</system.identityModel>

 

With those changes made, the website can be deployed, and the authentication functionally tested again.

image

This time the authentication works correctly, the browser is redirected to the members page and the claims in the security token displayed.

 

 

Print | posted on Monday, April 1, 2013 10:12 PM |

Feedback

No comments posted yet.
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 
 

Powered by: