Steve Spencer's Blog

Blogging on Azure Stuff

Add your own Claims to your ADFS Provider

Following on from my previous blog on “Creating your own identity provider …” The following changes can be made to add in your own claims.

Firstly in the App_Data\CustomSecurityTokenService.cs file of your identity provider web site I changed the following code

outputIdentity.Claims.Add( new Claim( System.IdentityModel.Claims.ClaimTypes.Name, principal.Identity.Name ) );
if (principal.Identity.Name.Equals("Steve") == true)
{
outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Administrator"));

outputIdentity.Claims.Add(new Claim("http://schemas.BlackMarble/Identity/Claims/Business",
"Black Marble"));

}
else
{
outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "User"));
}

 

 
The first parameter of the Claim constructor needs to be in the format of a namespace and I added this one up as it was an internal name we are using.
The second parameter of the Claim constructor is the value you want to pass through.
 
Next go to the appfabric portal and add in the following rule to your STS provider. You need to make sure that the schema string you have in your code matches the Input Claim Type you added in your rule.
 
 
 
image
Now you should be passing through the Business claim to your website. To get access to the claim use the following code:
 
using System.Threading;
using Microsoft.IdentityModel.Claims;
IClaimsPrincipal principal = (IClaimsPrincipal)Thread.CurrentPrincipal;
var business = "";
foreach (Claim claim in principal.Identities[0].Claims)
{
if (claim.ClaimType.Equals("http://schemas.BlackMarble/Identity/Claims/Business"))
{
business = claim.Value;
break;
}
}

if (!String.IsNullOrEmpty(business))
{
// we have a claim value for School so lets display it
BusinessLabel.Text = business;
}
else
{
BusinessLabel.Text = "No business claim found";
}
Again, note that the claim type namespace is the same as you specified previously.

The following claims are passed through to my website:

image

Denial of Service and Windows Azure

A question I regularly get asked is whether there is any support in Azure for preventing Denial of Service (DOS) attacks or at least reducing the impact of the DOS attack. In a white paper written by Microsoft called “Security Best Practices For Developing Windows Azure Applications“ in June 2010 the following statement was made:

“Windows Azure’s load balancing will partially mitigate Denial of Service attacks from the Internet and internal networks. This mitigation is done in conjunction with the developer defining an appropriate Service Definition VM instance count scale-out. On the Internet, Windows Azure VMs are only accessible through public Virtual IP Addresses (VIPs). VIP traffic is routed through Windows Azure’s load-balancing infrastructure. Windows Azure monitors and detects internally initiated Denial of Service attacks and removes offending VMs/accounts from the network. As a further protection, the root host OS that controls guest VMs in the cloud is not directly addressable internally by other tenants on the Windows Azure network and the root host OS is not externally addressable.”

The following table shows the types of protection that are available (or planned)

Threat

Layer where mitigation is implemented

Nature of mitigation provided

(if specific to Windows Azure)

Application/Service-layer mitigation required

Is this issue higher risk or more complex in cloud deployments?

Denial of Service

       

Denial of Service attacks via network bandwidth saturation (packet flooding)

Platform

Load balancing & throttling in network infrastructure

None Required

No

Identification of botnets and malicious network traffic

Infrastructure

Windows Azure Live Services monitors and investigates

None Required

Yes

Deep packet inspection for network attacks with known signatures

Platform (Not yet implemented)

 

None Required

Yes

Flooding of Web Role local storage or blob/table storage

Platform

Quotas, ACLs, Reduced privilege execution and flood monitoring protection

None Required

Yes

Request flooding at the customer code/app level

Web Role (Needs coding)

 

Implement application-level request throttling if necessary

No

My understanding is that there is support within Azure to stop someone from launching DOS attacks within Azure itself. It is difficult to stop a DOS attack on your site but there are things that can be done to minimise their impact. Bandwidth throttling and Load balancing are built in to the platform, but the developer has to code around issues at an application level for example implementing a back off policy when trying to access resources that are affected by DOS.

Windows Azure AppFabric CTP February release now available

Microsoft released on Thursday the latest CTP for Windows Azure AppFabric. Details of the release can be found here, in the AppFabric Team blog and in Wade Wegner’s blog

 

The CTP contains changes to the Caching service and the AppFabric portal is now in Silverlight. The changes are as follows:

  • New Silverlight-based LABS portal, bringing consistency with the production Windows Azure portal.
  • Ability to select either a 128MB or 256MB cache size.
  • Ability to dynamically upgrade or downgrade your cache size.
  • Improved diagnostics with client side tracing and client request tracking capabilities.
  • Overall performance improvements.

You can access the CTP by signing in to the AppFabric labs at http://portal.appfabriclabs.com/

Retrieving Role Instance Count in Azure From a Different Role

When using the following code from a worker role the trace information shows that there are one worker role instance and zero web role instances

public override void Run()
{
while (true)
{
Thread.Sleep(10000);
Trace.WriteLine(string.Format("WorkerRole Instances {0}",
RoleEnvironment.Roles["WorkerRole1"].Instances.Count),
"Information");

Trace.WriteLine(string.Format("WebRole Instances {0}",
RoleEnvironment.Roles["WebRole1"].Instances.Count),
"Information");
}
}

This is because an internal endpoint is required on the role in order for the role environment to be able to retrieve the instance count. So add a new end point to the webrole and set it as internal. Running the code again, then shows both roles with 1 instance running.

See the Role.Instances MSDN topic:

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.role.instances.aspx

Windows Azure Training Kit Update

The Windows Azure Training Kit January update is available at:

http://msdn.microsoft.com/en-us/windowsazure/wazplatformtrainingcourse.aspx

The January 2011 update of the training kit includes the following updates:

  • [New demo script] Windows Azure Connect
  • [New demo script] Web and Worker Role Enhancements
  • [New demo script] Windows Azure Virtual Machine Roles
  • [New demo script] Rafiki
  • [New lab] Windows Phone 7 and The Cloud
  • [Improved] Visual Studio code snippets installation
  • [Fixes] Several bug fixes in demos and labs

Migrating an Existing Web Application to Windows Azure

Moving to Windows Azure is not as difficult as you might think. Using a basic MVC 2.0 web application created in Visual Studio 2010, the Azure tools within Visual Studio enable you to migrate the web side really easily.

Load your MVC 2.0 application into Visual Studio and right click on the solution in Solution Explorer and add a new project to this solution.

image

Select Windows Azure Project and enter a new project name.

When the next dialog appears, do not select any role and press OK.

 

image

In the Windows Azure project rigt click on the roles folder and select Add->Web Role Project in solution

image

 

Select the MVC project and press OK

image

You MVC web application should now be ready for deployment to azure. Hit F5 and make sure that the solution builds and runs in development fabric.

For most people this is not the end. There are a number of issues that you may need to resolve for example file access, database access, security and on premise integration. There are solutions for each of these and it depends upon what you are trying to achieve.

With data access, if you are currently using a SQL database and providing the database is not too complicated then it should just port across my running the same SQL scripts on your SQL azure database. You will then just need to change your connection string to point to SQL Azure rather than whatever database you are currently using.  To see the issues the TFS team had converting to the cloud see the PDC video

Information about setting up security using the Access Control Service can be seen in my earlier blog

File access can be done using Azure Drives if there is a lot of file access, but it may be easier to store the file as a single blob or migrate the data you are storing to able storage. I depends upon what you are using the files for.

Connectivity to on premise applications could be done a number of ways by using the service bus or Azure connect. Again it depends on what you are trying to connect to and how “real time” the connection needs to be. I will be putting together a comparison of the methods as soon as I get some free time.

CommunicationObjectFaultedException after checking an Azure project in to TFS

I suddenly started to get a CommunicationObjectFaultedException after I checked my azure code in to TFS

image

I could get it working by editing the web.config file manually, but it didn’t seem to matter what I actually changed!! It was the act of editing the web.config file that made it writable and it could therefore be written to by the development fabric. When comparing the files it looks like the machine key section is changed. Further investigation pointed me in the direction of the changes made in the Azure SDK 1.3 to support full IIS. During deployment “automatic configuration [of the machine key] occurs at the site-level, overriding any user-supplied value”. When the file is read-only the error occurs. Making the file writable fixes the problem.

The following links explain:

http://blogs.msdn.com/b/windowsazure/archive/2010/12/08/specifying-machine-keys-with-windows-azure-sdk-1-3.aspx

http://msdn.microsoft.com/en-us/library/gg494981.aspx

10 March 2011 : Update – Issue now fixed in Azure SDK 1.4. See Azure SDK 1.4 Released

Migration to SQL Azure

During my Azure talks in Ireland we were discussing issues with migrating SQL to SQL Azure.

At PDC 2010 in Redmond there was a good talk about migrating TFS to Windows Azure and covers the issues they found. It details well the SQL Server to SQL Azure issues and discusses how they solved them. Here is a link to the presentation:

http://player.microsoftpdc.com/Session/be3ad63f-74dc-4283-b70d-817b27226175

Keeping an IP address in Windows Azure

During one of my Azure presentation I was asked whether we could fix the ip address of an azure role so that we can use the ip address to access some external service that uses the ip address to verify the calling party. I didn’t think that there was a way to do this but after talking with Simon Davies at Microsoft he pointed me to a blog post he made on this topic.

How does IP address allocation work for Compute Services in Windows Azure? – Simon Davies

Creating your own identity provider for Windows Azure AppFabric Access Control

Whilst doing an access control service demo I was asked whether you could wire in your own existing authentication mechanisms as customers did not want to have to redo their authentication/registration mechanisms to use Live ID, Google, Yahoo! etc. The answer to this was yes but I had never done it so this was a good time to investigate how.

I started off with the Windows Azure Platform Training Kit(VS2010) and worked through the “Introduction to the AppFabric Access Control Service V2” lab to setup a web site that allows login via Live ID, Google and Yahoo!. Once this was running I needed to create my own provider and wire it into the lab solution that I just created. There is an additional lab ""Federated Authentication in a Windows Azure Web Role Application" which gives the basics of creating your own identity provider. Unfortunately this does not link to ACS so I needed to work out how to wire the provider in. The following instructions are how I created the site and wired it in:

Taking the ACS lab solution as the basis, create an ASP.Net website that will carry out the login process. For this I added a “ASP.NET Security Token Service Web Site”. Right click on your solution and select new website. Make sure that the URL you enter for the site includes https at the start. (e.g. https://localhost/MyIDProvider).

When the project is created, you need to change some of the code in the template as it does not handle the return address correctly when redirecting from your identity provider after logging in.

The template for an STS web site needs the following code changing in App_Code\CustomSecurityTokenService.cs

Go to GetScope and change the line

scope.ReplyToAddress = scope.AppliesToAddress;

to

scope.ReplyToAddress = String.IsNullOrEmpty(request.ReplyTo) ? scope.AppliesToAddress : request.ReplyTo; 

This takes the replyto address from the query string and uses this to redirect back to ACS once the login process has been completed. There are 2 other changes required to the basic STS template in order for it to work correctly.

Open web.config and search for IssuerName in the application settings section and change it to be the url of your STS website (e.g. https://localhost/MyIDProvider)

Also change the SigningCertificateName to point to a certificate that exists in your local machine certificate store. This website will now provide a simple mechanism for logging in. Without any changes you can enter any username and it will authenticate. At this point you will need to wire in your own authentication mechanism, but for testing purposes the default site will allow you to set it up correctly and test it out.

We now need to wire this into ACS. I am using the labs version of the access control service at https://portal.appfabriclabs.com/.

Navigate to your Access Control Service at appfabriclabs.

Click “Identity Providers”, “Add Identity Provider” and add a new “Microsoft Active Directory Federation Service 2.0” provider. The two bits that are important are “WS-Federation metatdata” and the relying party application. Browse to the FederationMetadata.xml file of your STS project you have just created. (e.g. C:\inetpub\wwwroot\MyIDProvider\FederationMetadata\2007-06\FederationMetadata.xml). Also ensure that the ACS website created as part of the labs is checked and press Save.

The final piece of configuration that is required is to add in the rules for your provider. still in the Access Control Service portal, click “Rule Groups”, select the rule group that you setup for your ACS lab and select “Generate Rules”. Ensure that your new identity provider is in the list and that it has been checked and press the “Generate” button. Two new rules should have been added for your provider (Pass through for name and role). You are now ready to test this.

To make it easier to see what is happening I added the following to the Default.aspx of my ACS lab

In default.aspx add the following:

    <asp:LoginView ID="LoginView1" runat="server">
        <AnonymousTemplate>
            <asp:Panel Visible="true" CssClass="secretContent" runat="server" ID="unauthorisedContent">
            You are unauthorised to view this page
            </asp:Panel>
        </AnonymousTemplate>
    
        <LoggedInTemplate>
                You are logged in
        </LoggedInTemplate>
        <RoleGroups>
            <asp:RoleGroup Roles="Administrator">
                <ContentTemplate>
                    <asp:Panel ID="SecretContent" runat="server" CssClass="secretContent" 
                        Visible="true">
                        Secret Content (Only administrators can access this section)
                    </asp:Panel>
                </ContentTemplate>
            </asp:RoleGroup>
        </RoleGroups>
    </asp:LoginView>

This will display the login status so you can see whether the login works or not.

Also add the following style to the site.css file in the ACS lab site:

.secretContent
{
  border-style: solid; 
  background-color: Red; 
  padding: 5px;
  color: White;
}

Run the ACS lab application and check to see if your provider appears in the list of providers and also that when you click on the button it redirects to you page. Login and you should be redirected to the Default.aspx page of the ACS lab site with the text “you are logged in”.

You may want to change the claims that are allowed for specific users. This is done in App_Data\CustomSecurityTokenService.cs in your identity provider web site.

Modify GetOutputClaimsIdentity to change depending upon who is logged in.

Change the code that adds a Manager Role to the following code to allow a user called Steve to be an administrator and everyone else as a user.

if (principal.Identity.Name.Equals("Steve") == true)
{
    outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Administrator"));
}
else
{
    outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "User"));
}

Run your ACS website again and login with “Steve” and you should now see the secret content that only administrator should see. Login as anyone else and you will not see the secret content.

All that you need to do now is to wire in your own authentication mechanism and deal with the claims for each user.