By default web services do not run in ASP.net compatibility mode, and without this, many system.web settings in the web.config do not take effect, the MSDN article Hosting and Consuming WCF Services contains the following paragraph (bold is mine) –

ASP.NET Compatibility Model

When hosting your WCF services in a load-balanced or even a Web-garden environment where subsequent requests in a session can be processed by different hosts or processes in the environment, you need out-of-process persistent storage for your session state. Out-of-the box WCF doesn’t support persistent storage for session state. Instead, WCF stores all its session state in memory. When your WCF services are hosted in IIS, you can end up with recycling scenarios, as described in the previous section. Instead of building persistent storage for sessions all over again, WCF relies on the ASP.NET implementation for session state. This approach has one serious limitation: you limit your services to HTTP.

ASP.NET session state is not the only feature that is supported by the ASP.NET compatibility mode. It also supports features such as the HttpContext, globalization, and impersonation, just like you are used to with ASP.NET Web services (ASMX). Refer to MSDN Help for the ASP.NET–specific features to enable out-of-process session state.

And so – if you wanted to use the <globalization> element to control the locale of WCF service you must ensure your services are running in ASP.net compatibility mode, as shown in the MSDN article, this can be done by adding the following attribute to the service implementation –

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
    public class Service1 : IService1

But to allow that you would also need to add the following entry to the web config –

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

If you’d rather not run in compatibility mode, an alternative is to set the thread’s UI culture, as shown in my previous post, in the service’s constructor.

Note: for completeness I should add that this applies to WebServiceHost and REST services as much as it does for ServiceHost and SOAP based services, I have tested both.

Windows Azure’s Access Control Service (ACS) enables developers of web application and services to provide a seamless single-sign-on experience for their users, easily and quickly, building on standard protocols such as OAuth, WS-Federation and SAML.

ACS’ built in support for Live, Google, Yahoo and Facebook Identities as well as the easy integration with ADFS and AD means that authentication with the most used identities is literally done with a few clicks and a little bit of configuration.

For an overview of the ACS service and a useful how-to tutorial see MSDN on – http://msdn.microsoft.com/en-us/library/gg429781.aspx

Using ACS with well-known identity providers, other than custom authentication solutions, as part of the application provides several benefits -

From the users’ perspective it prevents the need to remember a different set of credentials for the application, instead using existing identities to sign-in; this also increases security as users tend to use the same credentials for many applications, not all are good at protecting this information.

From the application’s perspective it removes some of the effort required in building scenarios such as managing credentials – storing them securely, implementing authentication functionality as well as capabilities such as reminding/resetting passwords, etc.

However – whilst integrating an application with an identity provider (or several) provides two (generally trust-worthy) facts – the knowledge that the user has been authenticated by the approved identity provider(s) and a unique identifier for that user – it does not, on its own, provide a complete end-to-end solution for authentication and authorisation; several pieces are needed on top of the ACS and IP integration beyond uniquely identifying a user, such as managing the user’s profile and implementing role based authorisation.

In this post I will be looking at the steps that are required to provide an end-to-end story for an ASP.net / MVC application using ACS with multiple identity providers to drive authentication and authorisation scenarios, I’ll start by discussing managing users’ profiles -

Managing Users’ Profiles

The Identity Providers, through ACS, will provide the application a unique identifier for the user -

The initial request from the user’s browser to the application will come as unauthenticated; at this point, given the right configuration,  Windows Identity Foundation will redirect the request to ACS which will, in turn, interact with the identity provider (as needed) before redirecting back to the application, this time with a bunch of claims regarding the details of the identity provider and the user’s identity provided through the IClaimsPrincipal object.

It does not, at this point, give you much information about the user – some identity providers, such as Google, might provide the user’s first and last name and perhaps an email address, others, such as Live ID, will only provide a unique identifier – nor does it tell you whether the user is allowed to access your application. All you know is that this is user x as declared by identity provider y.

This might be good enough for web sites that do not restrict access, and only need to know a unique id for a user, for example for personalisation purposes or to store data for a particular user, http://www.stackoverflow.com is an example for such site.

Most web sites, however, would like to, at the very least, know some basic information about the user, such as full name, perhaps date of birth or email address; some – of course – require a much more elaborate profile.

Some web sites will let anybody in, but will require updating the profile, others are membership only and so – knowing the identity of the user is one half of the story – matching it against a membership database being the other.

To support either of these scenarios, the application will need to have its own store of users’ information, linked to the identity provided through ACS.

As requests arrive from the ACS the application will need to be able to refer to this store to identify whether the user is known or new. Known users will be let in (subject to authorisation, discussed later in this article); unknown users will be, for example, directed to a registration page.

This really isn’t much different from how this would be implemented without the ACS- if identity was provided by ASP.net membership, for example – the main difference is that when implementing single-sign-on the identity piece and the profile management/authorisation piece are separated.

On Windows Azure, table storage is a great option for storing user’s profile – records could be stored, for example, against the identity provider (as the partition key) and user’s identity (as the row key), and given that this will generally be the only access mechanism required (I’ll be discussing a variation of that – for supporting multiple identities for the same user), it keeps the solution nice and simple.

From a technical point of view – the application needs to first pick up the user’s identity, as provided by ACS, and check that against the user’s store, and it needs to do that before running the application’s code so that the user can be considered when evaluation authorisation.

One way of achieving this is leveraging the Windows Identity Framework pipeline by implementing a custom authorisation manager by inheriting from ClaimsAuthenticationManager 

By overriding the Authenticate method you can get access to the identity provided by ACS, interrogate the claims provided with it and even make changes to the claim-set as needed.

The first step in the authenticate method would be to extract the principal as an IClaimsPrincipal –

IClaimsIdentity identity = (IClaimsIdentity)incomingPrincipal.Identity;

The next step would be to ensure that the user has actually been authenticated as this method will get called twice – once for the initial unauthenticated request, before the redirection to ACS, and once when the user is redirected back to the application from ACS with the authentication token; We’re only interested in the second call and so if the user is not authenticated we do nothing. The module’s default behaviour will take care of redirecting unauthenticated users if this was the WIF configuration.

if(identity.IsAuthenticated)
{       //code goes here
}

For authenticated users, we need to extract the claims we’re expecting from the token and ensure they exist – these are the nameidentifier and identityprovider claims

Claim id = identity.Claims.FirstOrDefault(claim => claim.ClaimType ==               "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier");
Claim provider = identity.Claims.FirstOrDefault(claim => claim.ClaimType ==  "http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider");

if (id == null || provider == null)
   throw new ApplicationException(                  "Reuqest did not contain the necessary authenticaiton information");

It might be obvious, but to avoid any doubt it is important to note that the user’s identity has to be composed of these two – the identity is unique in the context of the identity provider, theoretically two provides might use the same identity.

So – now that we have the user’s unique identity we can check whether it exist in our users store, this is straight forward coding against Table storage, so there’s no point repeating all the details, I have it encapsulated in two method calls

UserLineDataServiceContext context = UserLineDataServiceContext.GetContext();
UserLine user = context.FindUser(provider.Value, id.Value);

At this point user either hold the details of the user found or is null if the user has never been registered; if the user has been registered before I populate a bunch of claims specific to my application –

if (user != null)
{
    identity.Claims.Add(new Claim(ClaimTypes.Role, "RegisteredUser"));
    Claim nameClaim = identity.Claims.FirstOrDefault(                                 c => c.ClaimType == ClaimTypes.Name);
    if (nameClaim != null)
         identity.Claims.Remove(nameClaim);

      identity.Claims.Add(new Claim(ClaimTypes.Name,                                 user.FirstName + " " + user.LastName));
     identity.Claims.Add(new Claim(ClaimTypes.GivenName, user.FirstName));
     identity.Claims.Add(new Claim(ClaimTypes.Surname, user.LastName));
}

The first claim I populate is a role claim of a ‘RegisteredUser’, I will be using this in my application to ensure that only users with this role can access pages other than the register page as part of my authorisation implementation.

I then populate the name-related claims; this allows me to present the user’s name as given to my application in the sign-out control and other areas of my application.

Note: some IPs (such as Google) will provide you with the user’s name, others might not, in either case I allow my user to override the name with the one she wishes to use in my application, and so for registered users I need to override any claims provided by the IP.

At the end of the Authenticate method I call the base method to ensure any standard behaviour of WIF is executed –

return base.Authenticate(resourceName, incomingPrincipal);

And so – by using a few lines of code in a custom ClaimsAuthenticationManager and utilising Windows Azure Table, we’ve enabled the application to manage it’s users, distinguishing between registered and unregistered users.

The next  step would be to implement authorisation and allow unregistered users to become registered –

Role Based Authorisation and the registration page

You would have noticed the custom Claims Authorisation Manager added, for known users, the RegisterUser claim – a claim of type ‘ClaimType.Role’ – by default WIF translates claims of this type to ASP.net roles allowing familiar role based authorisation techniques to be used, in my example I’ve used this to control access to the rest of the application and to direct unknown users to the registration page.

In my case I’ve decided that the application can be accessed by any user, but it requires that users register with it application directly.

To this behaviour, preventing unregistered users access to the majority of the application, I’ve added the authorise attribute, requiring the ‘RegisteredUser’ role for access, on all my controllers other than the default controller -

[Authorize(Roles="RegisteredUser")]

By doing so, and given that this role will only be available for users that were found in the applications user’s repository, I ensure that unknown users, even if authenticated by the identity provides supported, will not be able to access any part of the application other than the home controller (which does not have this attribute)

Note: To bulletproof this approach the ClaimsAuthenticationManager should check that incoming requests do not contain the Role Claim with the text ‘RegisteredUser’ 

On the home controller I have two actions, Index and About, both are available for any user, the Index action has the following code –

public ActionResult Index()
        {
            if (!User.IsInRole("RegisteredUser"))
                return RedirectToAction("Register", "Account");
            else
            {
                return View();
            }
        }

As you can see – as users land in the default action for the application, if they are not registered they are redirected to the Register action of the Account Controller – an action that is available to any users, this action will display the registration form asking the user for details such as name and date of birth, the post action for this form looks as follows –

UserLine user = new UserLine(encodeKey(collection["IdentityProvider"]), encodeKey(collection["Identity"]));
            user.FirstName = collection["FirstName"];
            user.LastName = collection["LastName"];
            user.EmailAddress = collection["EmailAddress"];

            UserLineDataServiceContext context = UserLineDataServiceContext.GetContext();
            context.AddUser(user);
            ClaimsIdentity identity = User.Identity as ClaimsIdentity;

            identity.Claims.Add(new Claim(ClaimTypes.Role,"RegisteredUser"));
            //add name claims according to registration information
            identity.Claims.Add(new Claim(ClaimTypes.Name, user.FirstName + " " + user.LastName));
            identity.Claims.Add(new Claim(ClaimTypes.GivenName, user.FirstName));
            identity.Claims.Add(new Claim(ClaimTypes.Surname, user.LastName));

            return RedirectToAction("Index", "Home");

Admittedly not the most robust code in the world, but good enough as a sample it creates a new UserLine, populating it with the information from the form and adds it to the Table before adding all the necessary claims for this user.

These claims, including the RegistredUser role claim would normally be added by the ClaimsAuthenticationManager but in this case they are now added in this form to allow the user to be treated as a recognised user by the application.

With these set the user can be redirected back to the default action, this time with the correct role which would allow the default view to be returned.

Supporting Multiple Identities for same user

Everything that discussed so far assumes the use is only identified using one identity provider and whilst this is a fair assumption for some web sites, most of those who wish to support identity federation want to support more than one provider and to make user’s life as convenient as possible it is important to be able to recognise users using more than one identity provider.

Given that there’s no way for any one IP. or the ACS, to link identities, this is up for the application, or – more accurately- up for the application to allow the user to do so.

I haven’t fully implemented this for my sample, but the approach would be to allow the user, in the registration page, to indicate that she is already known using a different identity and then to be able to provide a token for this identity (through ACS, of course).

The key to this is to expand the user’s repository – every user should be given an ‘internal identity’ – managed by the application and separate table will link any IP-provided identity to the relevant internal identity, any records in the application should always be stored against the internal identity.

Summary

I hope that through this post I was able to demonstrate that whilst enabling ACS for an application is only a first step towards achieving a full end-to-end authentication and authorisation solution for an application, the steps required to complete the solutions are quite straight forward and lean, and that’s the whole point in identity federation – to take away the majority of the work needed, whilst leaving a good level of control in the application.

In Windows Azure all instances are created with the en-US locale by default and if your application is deployed outside the US, and you’re not handling this properly, this may cause some confusion.

To demonstrate this I’ve create a simple application using the ASP.net template and added a textbox, a button and  a label

In the Page_Load I’ve updated the label with DateTime.Now.ToString() and when I run my application on my UK laptop I get the expected result -

However, deploying and testing this on Windows Azure the result is different – the date shown is in US format (MM/dd/yyyy) rather then the UK format (dd/MM/yyyy) -

The same issue exists when trying to parse a date – entering the date 30/1/2012 into the textbox and clicking on the button which includes the logic –

Label2.Text = DateTime.Now.ToString("MM/dd/yyyy");

result with the correct date displayed in the label when running locally, but an exception when running in Azure (as there’s no month 30, of course)

So – what can one do?

Well – theoretically one can change the locale on the machine, either by using remote desktop (hardly a scalable and reliable approach) or, better yet, by employing a startup task to do this, but this has the potential of confusing the fabric controller and generally speaking – one should not meddle with the O/S unnecessarily.

So – this should be handled at the application level rather than the system level, what’s are the options?

Well – in my simple scenario I could have simply provided the required format in my code – if I had my Page_Load logic as DateTime.Now.ToString(“dd/MM/yyyy”)  I would have avoided the different behaviour between environments, similarly I could have provided the format when parsing the date

IFormatProvider cultureInfo = new CultureInfo("en-GB",false);
Label2.Text = DateTime.Parse(TextBox2.Text,cultureInfo).ToString();

But this could be quite cumbersome for a real application.

Another option is to set the Culture on the thread of the application -

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB");

but I would need to do this on every page load, so that might be a bit cumbersome as well (but that’s a good option when you need to set the culture based on the user request, for example)

For a blanket rule option, seems like the web config is the best option – simply add

   <globalization culture="en-GB"
       uiCulture="en-GB"
    /> 

to the system.web section of the web config and this culture will be applied to all requests.

A good summary of the options can be found here

Note: turns out there’s a bit more to the story, read my follow up post

Given that Table Storage is exposed through oData, which is, as you’d expect, a data source fully supported by PowerPivot, my gut feeling was that this should not be a problem and, in fact, a very interesting scenario – many customers use Windows Azure Storage to store vast quantities of data, given how cost-effective it is and the scale that is possible, but ultimately data is there to be used, and PowerPivot is an amazing tool to process data – the two together make a powerful pair.

Looking at it closer, though, I stumbled into a small hurdle – whilst PowerPivot had support for working with data from Azure DataMarket out of the box for some time now and it supports working with oData feeds, I don’t believe it supports, currently, working with Azure Table Storage directly, the stumbling block being the ShareKey authentication mechanism.

However, this is too useful to give up, so I looked at a workaround, and the most obvious one was to take the man-in-the-middle approach and to publish a WCF Data Service onto an Azure Web Role (doesn’t have to be, of course, but makes perfect sense), which would expose a ‘standard’ oData feed to be consumed by PowerPivot and would get the data from the Table Storage. simples.

To do that I needed some data in Azure Tables and so I decided to use Cerebrata’s Cloud Storage Studio to upload the pubs database to Window Azure Storage – quite a cool and useful feature of their product if you ask me!
(Right click on the ‘Table’s’ node, choose ‘Upload Relational Database’ and follow the steps in the short wizard)

I decided to publish data from the roysched table, only because it had the most rows in it; to do that I create a class that represented a roysched entity -

[DataServiceKey("RowKey", "PartitionKey")]
    public class roysched
    {
        public string PartitionKey {get;set;}
        public string RowKey {get;set;}
        public DateTime Timestamp {get;set;}
        public string title_ID {get;set;}
        public int lorange {get;set;}
        public int hirange {get;set;}
        public int royalty {get;set;}

                public roysched()
        {
        }

        public roysched(string partitionKey, string rowKey, DateTime timestamp, string titleId, int lorange, int hirange, int royalty)
        {
            PartitionKey = partitionKey;
            RowKey = rowKey;
            Timestamp = timestamp;
            title_ID = titleId;
            this.lorange = lorange;
            this.hirange = hirange;
            this.royalty = royalty;
        }
    }

You will notice the DataServiceKey attribute I’ve added – this is needed for the Entity Framework to figure out which fields (or combination of keys, as is the case here) can be used as the identity of the entity as I’ve blogged here

With that done I needed to create a context class to be used by the WCF Data Service, this class will read data from Azure and ‘re-publish’ data as the feed behind the data, this is where the majority of the logic would generally go, but as you can expect I’ve kept this to the minimum for the purpose of this demonstration.

public class PubsContext
    {
        public IQueryable<roysched> list
        {
            get
            {
                var account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
                var context = new AzurePubsContext(account.TableEndpoint.ToString(), account.Credentials);
                return context.AzureList;
            }
        }
    }

One thing to note is that whilst technically I could expose the TableServiceContext I’ve used to access Windows Azure Storage directly, I did not do that, following from the guidance that can be found here

Also bear in mind, as these samples often go, this is by no means the best or most efficient way of doing things, but I did want to keep things as simple as possible to focus on the concept rather than lines of code – in a real, production, code I would almost certainly not want to create the Azure TableServiceContext on every call!

The last ‘big’ piece in the puzzle is creating the data service itself – adding a WCF Data Service item to the project adds a handy template in which only the context class and list property are needed to be updated (highlighted in the code below)

public class SomeDataService : DataService<PubsContext>
{
    public static void InitializeService(DataServiceConfiguration config)
    {
        config.SetEntitySetAccessRule("list", EntitySetRights.AllRead);
        config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
    }
}

To get everything working I needed to do a couple more small changes –

I needed to define the DataConnectionString configuration setting in the csdef file and add the connection string value pointing at my Azure Storage (or the local emulator), this is easily done through the Visual Studio UI.

Last – I needed to put the code to initialise set the configuration setting publisher in the Global.asax’ Application_Start handler, this is pretty standard for any project deployed on Azure –

// This code sets up a handler to update CloudStorageAccount instances when their corresponding
            // configuration settings change in the service configuration file.
            CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
            {
                // Provide the configSetter with the initial value
                configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
            });

…and voila – calling this service exposed the information from Windows Azure as a basic oData feed, easily consumable from PowerPivot  –

One last thing to bear in mind, of course, is that I kept my service completely open for anonymous access, which you’d probably not want to do in real life, but as this is now a standard WCF Data Service than the normal configuration applies, and PowerPivot will support both SSPI and basic authentication)

This happened before any of my code executed directly, which buffeled me for a short bit, but then adding the [System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)] attribute to the data service class revealed a little bit more detail –

The server encountered an error processing the request. The exception message is ‘On data context type ‘AzurePubsContext’, there is a top IQueryable property ‘list’ whose element type is not an entity type. Make sure that the IQueryable property is of entity type or specify the IgnoreProperties attribute on the data context type to ignore this property.’

My AzurePubsContext class did not have any public properties that do not return IQueryable, so this was not pointing directly at the problem, but it was clear that I have an issue with the entity I was using.

I was trying to represent pub’s roysched table, migrated to Azure Table Storage and I suspect my problem was that there was no obvious key the Entity Framework could use.

Specifying the [DataServiceKey(“PartitionKey”,"RowKey")] attribute on my entity class sorted this quickly enough.

In his article Alistair suggests, and I paraphrase, that customers’ expectations from the SLAs provided by cloud vendors are unrealistic and he suggest the point that Car makers don’t provide insurance as part of the deal to purchase the car, but rather customers buy insurances they deem necessary separately.

This had got me thinking – the man does have a point. to a point.

I would suggest that analogy stretches further, and actually taking about the warranty is a better viewpoint – Consider you’re a logistics business in need of a fleet – you would make your research and settle on a car from a maker with a good track record of reliability and service.

You might pay premium for these, but you asses the risk and suggest that buying a truck from a reliable manufacturer is worth more than buying one from a less robust maker; I don’t think anybody believes it is possible to buy a truck which ‘5 nines availability, and even businesses that relay on these accept a certain amount of ‘down time’; of course we expect a good maker to have a good service network, that will see our truck fixed in the shortest amount of time possible (and at the first attempt), and we would almost certainly expect a courtesy car/van/truck whilst ours is in the garage, but if it takes half a day to sort this out, in the main, we accept the fact.

Now – I don’t suggest that cloud platform are equivalent to cars and certainly when thinking of the Windows Azure platform I would think closer to the space shuttle – with tons of redundancy and a lot of ‘big brains’ behind it, and so – the chances for failures are indeed much smaller than those of a car or a truck, and recovery is much faster, and certainly at large IT operations in general we tend to aim for the mythical 100% availability and try to hit that 5 nines promise, largely because we believe we can, but I do think I agree with Alistair that organisations increasingly feel more than comfortable with the SLAs on offer, accepting the cost/benefit analysis behind it and – more importantly – accepting that in most cases they could not have achieved better or even similar in most cases!)

I also agree, and would like to emphasise Alistair’s last point on this topic which is that cloud vendors, and certainly the Windows Azure platform, provide a lot of capabilities that allow solutions respond to any issues that emerge and so building high availability solutions is actually much easier on Windows Azure than it is on-premises, or – as he had put it ”In 2012, we’ll realize that the providers have been trying to tell us something: You can have any SLA you want, as long as you code it yourself and find a way to turn risk into economic value.”

As part of a demo I’ve been working on I’ve decided to implement this approach and, initially at least, everything seems to work fine (using my Live ID)

Below is the initial code I’ve written (it’s not pretty, but it does the job ) –

First I check that the user has indeed been authenticated (if not, it has not been through the ACS, which should never have happened), next I extract the claims I expect – name identifier and identity provider – before performing a lookup in an Azure table to see if a user with this token (from this particular provider) already exists.

If I find the user in my table I redirect the request to the home page, if I don’t I redirect to the registration page which would ask the user for more details, add it to the table and then re-run the code below to verify.

    //Check that user is authenticated
    if (!User.Identity.IsAuthenticated)
    {
        throw new ApplicationException("User is not authenticated");
    }

    //get user identity
    ClaimsIdentity ci = User.Identity as ClaimsIdentity;
    if (ci == null)
        throw new ApplicationException("Identity is not ClaimsIdentity");

    //read claims from security token token
    Claim id = ci.Claims.FirstOrDefault(claim => claim.ClaimType == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier");
    Claim provider = ci.Claims.FirstOrDefault(claim => claim.ClaimType == "http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider");

    if (id == null || provider == null)
        throw new ApplicationException("Security token did not contain expected information");

    //check user identity against user store
    UserLineDataServiceContext context = getUserContext();
    context.IgnoreResourceNotFoundException = true;

    var result = from UserLine u in context.Users where (u.RowKey == id.Value) && (u.PartitionKey == provider.Value) select u;
    UserLine user = null;
    //TODO: lookup user - this causes exception for some reason
    user = result.FirstOrDefault();

    //if user is known return view
    if (user != null)
        return Redirect("/Home/Index");
    else
    {
        //if user is not known return register view.
        UserLineModel userModel = new UserLineModel(provider.Value, id.Value);
        //TODO: should move HOme Controller's Register to the account controller?
        return View("Register", userModel);
    }
}

When I ran this with my Google id, however, I got a DataServiceQueryException on the result.FirstOrDefault() call, which took me a while to figure out.

The inner exception’s message was an xml describing an Invalid Input error with the message – “One of the request inputs is not valid”

Turns out that the Google identity is represented as a Uri (absolutely nothing wrong with that, of course), but that key fields in Azure tables do not allow certain characters, see this for more details.

The solution was to base-64-encode both partition and row key fields before performing the lookup, as well as, naturally, before storing them in the registration controller executing after the user had filled in the registration form and hit ok.

Now, with the introduction of SP3, we have announced the ability to run the scheduler directly on Azure, with no need for on-premise software.

To learn more take a look at Getting Started with Application Deployment with the Windows Azure HPC Scheduler

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.

I also often use a metaphor for cloud computing I heard not long ago and really liked – which is one of a water tap –

• When you approach a tap, you expect to be able to open and close it yourself – this is the principle of self-provisioning
• You expect that the more you open it – the more water you are going to get –  in other words – immediate scalability
• You expect to only pay for the water you use, with 0 cost when the tap is fully closed- metering and chargeback
• and you also expect that the utility company will share the water in the most efficient way possible, so that you get the water in the lowest cost possible – resource pooling

I think this metaphor is very useful when discussing what one should expect from a cloud platform, and helps distinguishing traditional virtual hosting farms from cloud platforms.

This is important because in many of the conversations I’m having, somebody will, at some point, suggest that this particular company already has a cloud platform delivered through virtualisation, 3rd party hosting etc., but practically every time, when we explore this point a bit more in conversation, and dig a bit deeper into the capabilities of the Windows Azure platform versus those currently available to the company, significant differences emerge, often enough to suggest that public cloud can add a lot of value.

Private cloud, in its current form, isn’t an overhead-free solution – whilst its true that very large organisations can spread overhead costs of purchasing and maintaining server farms across many business units, and that those who can make some large technological investments can achieve a reasonable high level of automation – overheads still do exist, and, for most, organisations, these appear as significant upfront costs in purchasing (i.e. CAPEX) as well as substantial costs in running (i.e OPEX) servers and software,

Public cloud offering at the scale of Microsoft’s spreads this overhead over many customers, and removes any upfront investment aspect, the cost is strictly on a pay-for-what-you-use basis at a well know rate, there’s not cost to not using resources.

Further more – the scale of the Microsoft investment in the technology in those data centres, driven by the scale of the adoption, means that the level of automation achieved in our data centres is incredibly high (no human interaction required to provision services or to update them, or even to overcome issues in any running service)

This high level of automation helps keeping the cost of the services offered low, certainly lower than most, if not all, private cloud solutions , but it also allows us to provide some capabilities that are unique to the platform, and this is where the majority of value of the platform lies, consider a couple of examples –

When you’re handing your application to the Windows Azure Fabric to be deployed, the fabric makes a decision where to deploy your application to. several factors come into play in this decision, one of which is the concept of failure domains:

Assuming you’ve asked the controller to deploy your application to at least 2 instances, it ensures that the deployment is such that these instances will not have any single point of failure – they will be deployed on separate hosts, on separate racks, with separate network switches and power supply. short of the data centre blowing up, you are pretty much guaranteed that at least one of your instances will remain alive. this is much more than most organisations have the ability to do.

But it doesn’t stop there – the controller also constantly monitors the state of the instances it ‘owns’ and if indeed one fails, it would immediately start deploying it elsewhere. the net result of which is that in minutes after any failure, your application will resume the same level of resiliency as it had initially, and all of this is done with no human intervention.

These are just a couple of examples of the sort of things that we can do on our platform that private cloud initiative can’t easily achieve today. this is at the heart of the strong proposition that is public cloud.

And so – whilst it is true that many organisations have built strong virtualisation platform that provide many cloud-like capabilities, I don’t think that they are quite comparable to the capabilities of Windows Azure – being able to self-provision is great, but being able to do so and in the process consider aspects such as failure domains and performance characteristics is better. private clouds can offer dynamic scaling, but are more sensitive to capacity planning than a massive scale public cloud offering. virtualisation helps increase utilisation, but hosting many many customers across geographies and industries, and cleverly analysing multi-tenancy patterns means that utilisation is greater still.

To beginning was to get a data source to work on, and at the moment, that means SQL Azure database(s), which – of course – makes perfect sense, and so I promptly created a SQL Azure Database server, and, using the SQL Azure Migration Wizard, I’ve migrated good old Northwind onto it.

Now that I have a data source with some familiar data, it was time to create a report.
Given that I’m by no means a reporting expert and that this isn’t really the point of the demonstration, I did not try to get too creative and created a simple report of customers by country

I started by opening Visual Studio 2008 and creating a new project of type ‘Report Server Project Wizard’

The first step in the wizard was to define a data source, and it’s great that SQL Azure is an entry in the list of possible types; all that’s needed is to provide the connection string and the UI helps make that easy too

It was simply a case of typing in my database server name and credentials and provide the database name. The only other thing I needed to do is set the TrustServercertificate to True under the properties accessed through the Advanced button.

I then used the Query Builder to select the entire Customers Table and carried on with the Wizard specifying Tabular Format, Group By Country and the details fields (you can see I’ve been very creative)

Then, at the last page of the wizard, it was time to specify the deployment location I replaced the default value of http://localhost/ReportServer with the address of my Azure-based SQL Reporting ‘Server’, which I copied from the management portal

This, of course, is not necessary at this stage, it is perfectly fine to start working against a local reporting server and deploying the report later either through the management portal or by changing the server property in the report project’s properties and deploying from Visual Studio.

With the wizard complete I could now run my report from Visual Studio and see the results and the only thing I noticed is that I had to provide the credentials to the data source every time I ran the report.

This might be desirable in some cases, but I wanted a more streamlined experience, and so I set the credentials to the database in the data source. the report file itself will be protected through the management portal and the login to that, so these don’t get compromised.

With the data source credentials sorted I now deploy the project straight from visual studio and after minute or so it is visible in the management console. Clicking on the report renders it successfully -

So – at this point the report is fully operatoinal, and can be accessed via a publicly available url. access is governed by username/password pairs setup through the admin console and permissions set on the report itself (or a folder0, and that’s probably good enough for many scenarios for departmental reports inside the organisation.

For more public reports, ones available for external parties for example, I think that re-hosting the report in a web role and leveraging the ACS for access control would be a lot more flexible and manageable, and so I moved on to do this as well –

Embedding the report simply meant, in my little example anyway, using the ReportViewer control on an ASP.net page; I’ve configured the ServerReport property of the viewer with the relevant Uri’s and made sure to set the control ProcessingMode property to ‘Remote”.

I then used code to assign the fixed credentials to reporting services. once again – my application is going to be protected by ACS and this code is server side code, so I am comfortable with embedding these in the code (should be configuration, of course…)

At this point I could run my little ASP.net application locally and that would succesfully access the report in reporting services and display it on screen –

The last step, then, was to add support for STS.

I’ve made all the necessary configuration in the management portal, and copied the ws-federation metadata url, and then used the add STS reference wizard to make the necessary configuration changes to my application –

The result of the wizard was a set of entries added to my web.config, to which I added, under <system.web> the following –

<httpRuntime requestValidationMode=”2.0″/>
<pages validateRequest=”false”/>
<authorization>
  <deny users=”?” />
</authorization>

Running the application now automatically redirects me to the ACS, and – as I have configured to possible identity providers (Windows Live Id and Google) I am presented with a selection screen –

Choosing the provider I want I am redirected to the login screen, hosted by the identity provider, and from there back to my application. the second time I will access my reporting application these redirects will happen, but local cookies in all parties will remember me and I won’t need to sign in again, until I sign out or the cookies expire.

The only thing to note is that the ACS configuration includes the url to the application, so once tested locally this needs to change to include the url on Windows Azure but once done, and deployed to Windows Azure, I can now browse to my reporting application, login using, for example, my Windows Live ID, and view a report on SQL Azure Reporting.