azure cookbook

29
Azure Cookbook Tasks to make Azure development easier This document details common tasks that many Azure applications require, but are not obvious how they might be implemented. This is a work in progress and additional tasks will be added based on community feedback! 6/15/2010

Upload: tushar-mehere

Post on 23-Nov-2014

120 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Azure Cookbook

6/15/2010

Page 2: Azure Cookbook

Table of ContentsAzure Service & Claims Authentication Development Guide.......................................................................2

Convert WCF service to work in Azure....................................................................................................2

Steps....................................................................................................................................................2

Convert azure WCF service to use SSL.....................................................................................................3

Steps....................................................................................................................................................3

Provisioning for claims based authentication (ADFSv2)...........................................................................6

Steps....................................................................................................................................................6

Add claims based authentication.............................................................................................................7

Steps....................................................................................................................................................8

Claims enable a Silverlight application..................................................................................................14

Steps..................................................................................................................................................15

Azure + Silverlight + Intranet Hybrid applications..................................................................................17

Steps..................................................................................................................................................17

Troubleshooting Issues..........................................................................................................................18

The HTTP request was forbidden with client authentication scheme 'Anonymous'..........................19

Could not establish trust relationship for the SSL/TLS secure channel with authority......................19

IIdentity.Name is null.........................................................................................................................19

Things to consider.................................................................................................................................20

Choosing a service account name......................................................................................................20

Service name is case sensitive...........................................................................................................20

Samples.....................................................................................................................................................21

Running the samples.............................................................................................................................21

Trouble Shooting Samples.................................................................................................................21

Page 3: Azure Cookbook

Azure Service & Claims Authentication Development GuideThis guide is a combination what can be found in the WIF (Windows Identity Foundation) Labs and other guides. The purpose of the guide is to be more of a reference once you’re familiar with the concepts in those guides, or as a quick reference to perform particular tasks.

The guide is organized into a number of common tasks that you may want to perform. Each task has a set of detailed steps to ensure easy completion.

This guide makes use of a lot of content that was published in the following areas:

Identity Training Kit: http://bit.ly/9FT0sC Guide to Claims Auth Book: http://msdn.microsoft.com/en-us/library/ff423674.aspx WIF Site: http://msdn.microsoft.com/en-us/security/aa570351.aspx

Convert WCF service to work in AzureWCF services need to have some changes made to them in order to make them work in Azure. You’ll also need to ensure you’ve applied the patch that allows the generation of WSDL to be correct in a load balanced (ie Azure) environment:

http://support.microsoft.com/kb/971842/

In addition to the patch, you’ll need to ensure you’ve installed the required software for Azure development.

StepsHere are the steps required to upgrade any WCF service to correctly work with Azure:

1. Create your service if not already done so in your Azure Webrole that you want to host the service in.

2. Add the following behavior to the Web.Config, which in combination with the installed patch will fix the issue of WCF returning the internal Uri’s when exposing the WSDL.

The port numbers in the xml below should be changed to match those of your services endpoints. Therefore when running on the Dev Fabric, you will want to use 81 and 444 unless you’ve specified specific ports in your configuration.

<behaviors> <serviceBehaviors>

… <behavior name="httpAzureBehavior"> <serviceMetadata httpGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="false" /> <useRequestHeadersForMetadataAddress> <defaultPorts> <add scheme="http" port="80" /> <add scheme="https" port="443" />

Page 4: Azure Cookbook

</defaultPorts> </useRequestHeadersForMetadataAddress> </behavior>

3. Add the new behavior to your service as shown below in this service example

<service behaviorConfiguration="httpAzureBehavior" name="SampleService.GetClaims"> … </service>

4. Ensure you have the following element in your Web.Config

<system.serviceModel>… <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

5. Next you need to ensure your service class has the following attributes applied.[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)][AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

6. Deploy to Azure!

After completing these steps your service should be ready to be deployed to the Azure cloud.

Note: If you plan on using a Silverlight client with this service you must include either the crossdomain.xml file or the clientaccesspolicy.xml file in the root of the Webrole. Sample copies of these files have been included with this package.

Convert azure WCF service to use SSLThis task assumes the steps in Convert WCF service to work in Azure have been completed. This task extends that task by adding support for SSL or https. This task will require a certificate, which can be one that is self-issued, as shown below or one that’s been issues by a trusted authority. The steps here show how to create a self-issued certificate, however for production use one that’s issued by a trusted authority should be used.

Steps1. Create a certificate if you don’t have one already. To do so run the following script that is

included with this package. To ensure you have the correct paths setup you should use the Visual Studio Command Prompt in Administrator mode.

CreateCert.cmd <serviceacountname> <password>

Example: CreateCert.cmd dev-msitactivity p@ssword!

When supplying the service account name use the one you’ve created in Azure in all lower case. The script will add the cloudapp.net suffix for you and create a Certs folder with your new certs. The password is the one used to secure your certificate, and will be asked for again in two dialogs as the script runs, be sure to use the same one each time. When using this cert locally such as in the Dev Fabric you’ll encounter warnings that the cert is not valid, however you can

Page 5: Azure Cookbook

ignore those. When deployed to the Azure production slot, the cert name you specified will match and therefore won’t show these warnings.

2. Once you’ve created your cert install the cert into your personal certificates location on your machine. The easiest way is to run the Local Machine Certificates.msc command included with this package. Then right click on Personal->Certificates and select All Tasks->Import. Select the .pfx file from the Certs directory (note the .cer file will be selected by default). Use the password you used to create the certificate when prompted, and then keep clicking next until finished.

Note: If you right click on the pfx file to import it, the file will be added to the Current User store which will not be visible when attempting to add it to your Azure project. If this is the case, you need to manually move the cert to the Local Machine/Personal/Certificates folder as indicated in the diagram.

3. Next upload the pfx certificate into the service account for the application in the Azure portal. This has to be done manually prior to deploying any secure services. Note that you want to add the certificate to the service account and not the API certificates section.

4. Add the cert to the Webrole that contains your WCF service, using the same name as the domain it was registered with. This can be done via the properties of the Azure solution.

5. Add the new cert to the Https end point for the WebRole

Page 6: Azure Cookbook

6. Ensure the role is running in full trust, which it will be by default. However, its best to check incase it’s been changed.

7. Add a new behavior to your Web.Config which is essentially the same as the one used for http but is configured for https support. See Convert WCF service to work in Azure for more details on this step.

<behaviors> <serviceBehaviors>

… <behavior name="httpsAzureBehavior"> <serviceMetadata httpsGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="false" /> <useRequestHeadersForMetadataAddress> <defaultPorts> <add scheme="http" port="80" /> <add scheme="https" port="443" /> </defaultPorts> </useRequestHeadersForMetadataAddress> </behavior>

8. Add the new behavior to your service as shown below in this service example

<service behaviorConfiguration="httpsAzureBehavior" name="SampleService.GetClaims">

… </service>

Page 7: Azure Cookbook

9. To support https a new binding is required, so you need to add the following custom binding definition to your Web.Config file. If you already have a custom binding section, just add the new binding.

<system.serviceModel> <bindings> <customBinding> <binding name="httpsBinding"> <binaryMessageEncoding /> <httpsTransport allowCookies="true" /> </binding>

10. Update the bindings on your service to make use of this new binding

<service …> <endpoint address="" binding="customBinding" bindingConfiguration="httpsBinding"

contract="SampleService.IGetClaims" />

11. Deploy to Azure!

Note: If you've already deployed your solution after completing Convert WCF service to work in Azure, then you may need to delete the instance and redeploy rather than doing an upgrade. This is due to adding a new https endpoint. Once deployed an upgrade can't add new endpoints.

Provisioning for claims based authentication (ADFSv2)The next section will describe how to add claims based authentication to your service. However, before you can do this you need to have your site provisioned within the corporate ADFSv2 instance. If you don’t do this, then you’ll only be able to make use of the local STS’s (Security Token Service) that can be automatically created for you by Visual Studio (see the Windows Identity Framework Labs for details). The issue with this is that those STS’s require user interaction and so won’t work very well when dealing with services.

Steps1. Visit https://corp.sts.microsoft.com/onboard/adfsonboard.htm2. Define the end points you want for your applications. It’s recommended that you try and

provision as many as you know about up front to reduce the amount of back and forth you’ll need in getting this up and running. Therefore as a recommendation you should request the following:

Relying Party (realm identifier) Endpoint Purposehttps://accountname.cloudapp.net https://accountname.cloudapp.net/ Productionhttps://devaccountname.cloudapp.net https://127.0.0.1:444/ Dev Fabric

Note: The port number for the Dev Fabric is dependent on how you’ve configured your https endpoint in the configuration, see Convert azure WCF service to use SSL step 5. By default your SSL port will be 443, however if you have IIS installed and have a https binding then that port

Page 8: Azure Cookbook

will already be taken, so when the Dev Fabric starts up it will auto-increment the port number until it finds a free one. So in some environments it will be port 444, hence defining this port above. In production the port will be 443 unless you change it. You can check what ports your Dev Fabric is using by looking at the Dev Fabric UI settings:

3. Ensure that all endpoints have a trailing slash as this will cause exceptions later if they don’t.4. Ensure you’ve specified https as the STS requires https.5. Determine what claims your application needs as a minimum you might want the following.

However, you can check out the full list here: https://corp.sts.microsoft.com/FederationMetadata/2007-06/FederationMetadata.xml

Name Uri Description

Account Name

http://schemas.microsoft.com/ws/2008/06/identity/claims

/windowsaccountname

Returns domain/alias

Email Address

http://schemas.xmlsoap.org/ws/2005/05/identity/claims

/emailaddress

Users email address

Note: At present when roles are returned they are returned using their SID, which isn’t the nicest form, especially if you’re accustomed to Windows Authentication. However, there is a project called Matrix which is looking to address this problem. You can find out more information here: http://bit.ly/b5Utyl

6. Complete the onboarding document with the above details and submit.

Add claims based authenticationClaims based authentication makes use of Federated Authentication. This topic is well covered in the WIF (Windows Identity Framework) Labs and the Step-by-Step Guide to Identity Delegation book included with the onboarding package.

Page 9: Azure Cookbook

Figure 1 Redirect & Claims flow when using Windows Identity Foundation Server

As a quick refresher, the above diagram shows the flow of claims when using ADFSv2 and WIF. The steps in the diagram are:

1. Browser makes a request for a secured resource.2. The browser is then redirect to the STS for authentication.3. The STS returns back a token (optionally encrypted) containing the users claims.4. The browser sends the STS token to the web site as its credentials.

Note: Before you can follow the steps for claims based authentication, you need to ensure you’ve installed WIF (Windows Identity Framework) and the WIF SDK which provides tools for Visual Studio.

Steps1. Run the Add STS Reference command by right clicking the WebRole project and selecting the

command from the context menu.

The config section at the top should have the Web.Config for you project and generally can be left as is. However, the Application URI is the full https path to your web site. Here are some examples:

Relying Party (realm identifier) Purposehttps://accountname.cloudapp.net Productionhttps://devaccountname.cloudapp.net Dev Fabric

It’s important to note that the path must have a trailing slash and use https, neglecting this will cause failures which won’t be easy to diagnose!

Page 10: Azure Cookbook

2. Click Next3. If you already have services in your WebRole which you would if you continued from the

previous task. Then you will see a screen like the following:

Page 11: Azure Cookbook

At this point you need to cancel out of the Wizard and comment out your service definitions in your Web.Config, which will prevent the STS attaching directly to the services.

<services> <!--<service behaviorConfiguration="httpsAzureBehavior" name="SampleService.GetClaims"> <endpoint address="" binding="customBinding" bindingConfiguration="httpsBinding" contract="SampleService.IGetClaims" /> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> …</services>

Then go back to Step 1 – this time the dialog asking about services should not show up.

Note: If you’ve not on boarded your application you need to follow the steps in Provisioning for Claims based Authentication (ADFSv2) section.

4. Now add the detail of the corporate ADFSv2 STS. The Uri needed is https://corp.sts.microsoft.com/FederationMetadata/2007-06/FederationMetadata.xml

Note: If you navigate to the ADFSv2 Url you’ll get the meta-data for the STS which will detail all the claims available.

5. Next you need to choose if you want your tokens encrypted. This is optional; however it would be good practice to use it in production sites.

Page 12: Azure Cookbook

6. The next screen details the claims supported by the token service

Note: The claim Uri for windowsaccoutname differs from what is specified in the Web.Config and the screen above. The Web.Config has http://schemas.microsoft.com/ws/2008/

Page 13: Azure Cookbook

06/identity/claims/windowsaccountname. However the actual claim Ui is http://schemas.xmlsoap.org/claims/windowsaccountname.

7. The next screen gives a summary of the options selected

8. If you commented out the services in step 3, they can be uncommented again.9. Add a reference to Microsoft.IdentityModel to your project.

Note: If you’re using Visual Studio 2010 you may not see this dll in the references dialog. If that’s the case you can manually add the reference with this path: . This path may differ depending on where you’ve installed the WIF framework.

10. Due to WIF not being part of Azure yet, you need to modify the Reference Microsoft.IdentityModel which was added by the wizard to be CopyLocal=True. This will force the dll to be copied up to Azure into the local directory.

11. Create a Global.asax file for the WebRole if one is not present12. Add the following element to the new Service element created by the Wizard:

<microsoft.identityModel> <service>

… <certificateValidation certificateValidationMode="None" />

13. When you are using the Dev Fabric, you need to modify the generate configuration so that the local environment is recognized. To do this you need to modify the service element that was generated to include the Dev Fabric Uri.

Page 14: Azure Cookbook

<audienceUris> <add value="https://127.0.0.1:444/" /> <add value="https://devaccountname.cloudapp.net/" /></audienceUris><federatedAuthentication> <wsFederation passiveRedirectEnabled="true"

issuer="https://corp.sts.microsoft.com/adfs/ls/ " realm="https://devaccountname.cloudapp.net" requireHttps="true" />

<cookieHandler requireSsl="true" /></federatedAuthentication>14. Add the following code to the Global.asax.cs file. You only need to include the securing of tokens

if you chose to use encrypted tokens when setting up the STS reference.

using System;using System.Collections.Generic;using System.Web;using Microsoft.IdentityModel.Web;using Microsoft.IdentityModel.Tokens;using Microsoft.IdentityModel.Web.Configuration;using System.Text;

void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e){ // // Use the <serviceCertificate> to protect the cookies that are // sent to the client. // var 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);}

/// <summary>/// Retrieves the address that was used in the browser for accessing /// the web application, and injects it as WREPLY parameter in the/// request to the STS /// </summary>void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object sender, RedirectingToIdentityProviderEventArgs e){ //

Page 15: Azure Cookbook

// In the Windows Azure environment, build a wreply parameter for the SignIn request // that reflects the real address of the application. // HttpRequest request = HttpContext.Current.Request; Uri requestUrl = request.Url; StringBuilder wreply = new StringBuilder();

wreply.Append(requestUrl.Scheme); // e.g. "http" or "https" wreply.Append("://"); wreply.Append(request.Headers["Host"] ?? requestUrl.Authority); wreply.Append(request.ApplicationPath);

if (!request.ApplicationPath.EndsWith("/")) wreply.Append("/"); e.SignInRequestMessage.Reply = wreply.ToString();}

protected void Application_Start(object sender, EventArgs e){

//This is only required if tokens are being encrypted //FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated; FederatedAuthentication.WSFederationAuthenticationModule.RedirectingToIdentityProvider += WSFederationAuthenticationModule_RedirectingToIdentityProvider;}

Note: The default encryption strategy followed by WIF for session tokens is to use DPAPI, would create problems when the client interacts with multiple instances: a session token encrypted by a given instance would not be readable by any other. As an alternative you will use the service certificate for securing the session. The mechanism that WIF provides for customizing the way in which session tokens are processed consists in providing a custom SessionSecurityTokenHandler class. This is only relevant when encrypting your tokens.

15. The application should now be claims enabled with the internal ADFSv2 server.

Claims enable a Silverlight applicationThere are two ways to authenticate using claims, either using passive meaning the browser handles the negotiation of tokens or active where your code or application handles it. The passive approach is the simplest and this task will demonstrate how to make use of the passive approach, which should cover most scenarios. However, one thing to keep in mind is that passive due to it using the browser, will not work in an out of browser scenario. For that scenario you must make use of the active method.

Note: The passive authentication method discussed in this task will not work in an out-of-browser (OOB) scenario. To work in OOB you need to use the active method, which is currently not covered in this document.

Page 16: Azure Cookbook

Figure 2 - Passive Authentication in Silverlight

The process of authenticating using Silverlight is different in that Silverlight doesn’t have native support for claims based authentication. The above diagram shows the flow of claims for a Silverlight based application and the use of the custom service AuthenticationService.svc, provided by the WIF team to provide credentials to the Silverlight Application. The steps in the diagram are:

1. Browser makes a request for a secured resource.2. The browser is then redirect to the STS for authentication.3. The STS returns back a token (optionally encrypted) containing the users claims.4. The browser sends the STS token to the web site as its credentials which goes via the new

handler in the SL.IdentityModel.dll (supplied by the WIF team).5. The credentials are then handed to the requested resource.6. Silverlight Application requests a claims token from the AuthenticationService.svc which it can

then use to populate the ClaimsIdentity.7. The token is then attached to the service call to GymService.svc which can then check the claims

of the caller.

Steps1. Create or add a Silverlight application to the Azure solution.2. Add a reference to the SL.IdentityModel dll to the Silverlight application which is part of this

guides package.3. Add a reference to the SL.IdentityModel.Server.dll to the WebRole of your WCF service.

Note: This is a modified version that comes with the WIF SDK. The version that comes with the SDK will not work in Azure as is. It’s missing the following attribute on the Authentication service class:

Page 17: Azure Cookbook

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]

4. Add a Silverlight compatible WCF service to the Webrole called AuthenticationService.svc5. Delete the code behind file AuthenticationService.svc.cs6. Change the content of the AuthenticationService.svc to the following:

<%@ ServiceHost Language="C#" Debug="true" Factory="SL.IdentityModel.Server.AuthenticationServiceServiceHostFactory" Service="SL.IdentityModel.Server.SL.IdentityModel.Server"%>

7. Add the following XML to the Web.Config under the configuration section to allow anyone to access the service:

<location path="AuthenticationService.svc"> <system.web> <authorization> <allow users="*" /> </authorization> </system.web></location>

8. Add the following namespace, which references the Silverlight version of the Identity model provided by the WIF team to the App.xml in the Silverlight Application:

xmlns:id="clr-namespace:SL.IdentityModel.Services;assembly=SL.IdentityModel"

9. Now add the following Xaml to the App.xml file, which will instantiate the claims identity manager that is used to handle claims authentication in Silverlight.

<Application.ApplicationLifetimeObjects> <!-- Passive Authentication--> <id:ClaimsIdentitySessionManager > <id:ClaimsIdentitySessionManager.IdentityProvider> <id:WSFederationSecurityTokenService/> </id:ClaimsIdentitySessionManager.IdentityProvider> </id:ClaimsIdentitySessionManager></Application.ApplicationLifetimeObjects>

10. In the constructor of the Main.xaml (or the main Xaml page you're using) add the following event handler which will trigger the authentication. The authentication is actually performed by calling the authentication service which was added in a previous step, and asking it for the token.

using System;using System.Linq;using SL.IdentityModel.Services;using SL.IdentityModel.Claims;

public MainPage(){

InitializeComponent();

Page 18: Azure Cookbook

ClaimsIdentitySessionManager.Current.GetClaimsIdentityComplete += new EventHandler<ClaimsIdentityEventArgs>(this.Current_GetClaimsIdentityComplete);…

}

//Passive Authentication Callbackprivate void Current_GetClaimsIdentityComplete(object sender, ClaimsIdentityEventArgs e){ var userAccountClaim =

"http://schemas.xmlsoap.org/claims/windowsaccountname";

var identity = ClaimsIdentitySessionManager.Current.User.Identity as ClaimsIdentity;

if (identity.IsAuthenticated) {

Claim userAccount = identity.Claims .Where<Claim>(c => c.ClaimType == userAccountClaim) .SingleOrDefault();

// Code to make use of claim }

}

Azure + Silverlight + Intranet Hybrid applicationsThere may be times when you want to host your Silverlight application out on Azure as well as some services. This has been covered already in the previous tasks. However, given the restrictions on MBI and HBI data, you may want to also call internal (CorpNet) services too. You typically have two options here:

1. Service Bus : Expose your internal services to the outside world via the service bus.2. Directly call internal endpoint: Keep endpoints internal and access them directly.

The first option is great if you need your application to be used outside of CorpNet. However, for internal applications, the easiest route would be option 2. The issue is option 2 doesn’t work out of the box! The issue lies in the Azure application belonging to the Internet zone and your internal services belonging to the Intranet zone. It seems Silverlight denies cross zone communication by default!

Note: For more details on this see the following Url: http://msdn.microsoft.com/en-us/library/cc189008(VS.95).aspx

Steps1. Add either you site or the Azure root domain to the local intranet zone. This can be done in IE by

selecting Alt (brings up the menu) then:

Page 19: Azure Cookbook

Tools|Internet Options|Security (tab) | Local Intranet (item)| Sites|Advanced.

This should bring you to the same area you have in diagram 3.

2. Then enter either the domain of your site or the root of the Azure cloud.

http://*.cloudapp.net

3. You should now be able to access your internal services via your Silverlight Application. It should be noted that you can continue to use Windows Authentication as you previously did if you were using it. You can combine claims with the cloud with Windows Authentication for the intranet.

Figure 3 - Local Intranet Zone

Troubleshooting IssuesThis section attempts to help solve some of the more common issues that arise during development of Azure solutions.

Page 20: Azure Cookbook

The HTTP request was forbidden with client authentication scheme 'Anonymous'This error is typically caused by the client certificate not being installed correctly. It’s important to note that when you create a self-signed certificate it will have a non-exportable private key. This means that the certificate will work fine on the machine in which it was created, however if the same certificate is used on another machine you will get this error. Where you want to share a certificate you must create one with an exportable private key (-pe option in makecert). To make this easier however, you can use the CreateCert.cmd which will generate the .pfx and .cert files you need. See the task Convert azure WCF service to use SSL step 1 for details on how to run this command.

Note: If you right click on the pfx file to import it, the file will be added to the Current User store which may not be visible to the tool you’re using. If this is the case, you need to move the cert to the Local Machine/Personal/Certificates folder manually as indicated in the diagram.

Could not establish trust relationship for the SSL/TLS secure channel with authorityThis error is due to the certificate not matching the domain you’re using or due to the cert not being trusted. As a work around during development you can intercept the validation of the certificate and provide your own logic. The routine below will allow un-trusted and domain mismatches to be valid. It should be noted that this code really should only be used in development and not put into production.

static void ConfigureDevelopmentSLLHandler(){ // This code is not for production and is only here to avoid issues with self-signed certificates ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback( delegate(object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate, System.Security.Cryptography.X509Certificates.X509Chain chain, SslPolicyErrors sslPolicyErrors) { // Accept if there are no errors or if the only error is RemoteCertifcationChainErrors which is // indicating that the cert is not from a trusted souce - as its a self-signed cert. if (sslPolicyErrors == SslPolicyErrors.None | sslPolicyErrors == SslPolicyErrors.RemoteCertificateChainErrors) return true; else return false; });

}

IIdentity.Name is nullIf you are not getting a value populated for the IIdentity.Name, this is probably due to the claims you’re requesting. The good news is that you can actually get WIF to use any claim for this value, you just need to configure it. The following is what needs to be added to your configuration which specifies the claim to be used. In this case its http://schemas.xmlsoap.org/claims/windowsaccountname.

<service>

Page 21: Azure Cookbook

… <securityTokenHandlers> <remove type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/> <add type="Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"> <samlSecurityTokenRequirement> <nameClaimType value="http://schemas.xmlsoap.org/claims/windowsaccountname" /> </samlSecurityTokenRequirement> </add> </securityTokenHandlers>

Things to considerThis section is about things that you need to consider when doing Azure development or deployments. It’s a section that will grow over time as new best practices are developed.

Choosing a service account nameWhen choosing a service account name keep in mind that you’ll probably want to use the same name for your storage account too. The gotcha is that the storage account Uri only accepts numbers and letters; however the service account Uri will accept any valid Uri. The difference stems from a requirement for REST services that the storage account adheres to. Where this might be an issue is if you decide to use a service account name like the following:

Name Account Type IsValiddev-myaccount.cloudapp.net Service Account Validdev-myaccount.cloudapp.net Storage Account Invalid

This can become an issue if you later try to use the management APIs to auto-deploy your solution. The management APIs will automatically upload your package file to your associated storage account (it assumes that you’ve used the same name as the service account) however, as you can’t create a storage account with the hyphen it will fail. You would then have to ensure that a separate step uploaded the package file to your storage account and explicitly specify the location when making the call.

Service name is case sensitiveWe’ve all become accustomed to Uri’s being case insensitive when using them for web addresses or even service endpoints. However, REST based endpoints based on WCF are case sensitive, for this reason its recommended that you always choose lowercase names for resource endpoints.

Page 22: Azure Cookbook

SamplesIncluded with this package are a number of samples written in Visual Studio 2010 which show a start and end state. The end state is what was added by following the steps for a given task. The samples are not meant to be a guided learning experience, but rather a very simple demonstration of the implementation of the steps within a task. They can also be used to help trouble shoot issues during implementation in your own solutions.

Note: the samples need the code to be cleaned up, but should still be functional. Also work is still needed in this section to explain samples better. Feedback is appreciated!

Running the samplesBefore starting a new sample project you will probably need to delete the reference to the virtual directory in IIS. This is because each sample uses the same Web Site name to keep things simple. As such when you open a sample up it will prompt you if you want to create the virtual directory in IIS.

Convert WCF service to work in Azure: This sample provides a simple console Application which can be used to test against [L]ocalhost, [A]pp Fabric and the [C]loud:

Convert Azure WCF service to use SSL Add claims based authentication Claims enable a Silverlight application

For the samples that make use of IIS and SSL you will need to create a https binding on port 443 to a certificate with a name of localhost.

Trouble Shooting SamplesThere may be times when the samples don’t run as you’d expect, so here are a few things to check when things don’t work correctly.

Is the local host website pointing to the sample you’re running? Is the port number of the App Fabric the same as what’s referenced in the code? Sometimes

when you run multiple projects you’ll get incrementing port numbers. If this happens the easiest thing to do is shut down the App Fabric using the blue icon in the task tray.

Failed to create/load CookBookSample project. Ensure that you don’t already have a CookBookSample virtual directory setup in your IIS. If you do delete it and then try reloading the project.

Cloud samples don’t work. You need to ensure you’ve updated the sample code to work with your hosted service account. This also means that for the claims based authentication tasks that you’ve had it setup in ADFSv2 appropriately.

App Fabric sample isn’t working. Try shutting down the App Fabric this can solve many issues with a solution that should work that doesn’t.