How to backup Azure databases

As we start using SQL Azure more and more for storing data, we had to come up with a easy and inexpensive way to backup Azure databases. There is a number of various tools available to backup Azure databases, but they usually require a separate install and they are never free. Although, sometimes, they are fairly inexpensive. I like free ones better though.

So, after a bit of research I have discovered an easy way to backup SQL Azure databases to my on-premise (offsite) SQL Server: SQL Data Sync. D’oh! This is an existing functionality in Azure, and it can be accessed through an “old” Windows Azure portal interface (https://windows.azure.com). I am not going to write step-by-step instructions because, in this case, user interface is actually very intuitive and once you get to Data Sync part of Azure portal, you will know what to do. Good luck!

{ Ping me, if you need any help or have any questions about this article }

Cloud with a Chance of…Doesn’t Matter

In the past week, I have seen a couple of articles that discuss the lack of awareness of the Cloud in the general public. The following, from the Globe and Mail summarizes quite nicely.

“While cloud computing is growing increasingly pervasive, a new survey shows how many people are still cloudy in their thinking about the technology.” - http://www.theglobeandmail.com/report-on-business/small-business/sb-tools/small-business-briefing/cloudy-thinking-about-cloud-computing/article4504986/

The survey includes tidbits like 54% of people don’t think they use cloud computer (only 5% don’t), only 16% identify it correctly and (this one is my favorite) 51% believe that stormy weather can interfere with cloud computer.

(As an aside, I just got back from Punta Cana, where the Internet (and thus cloud computing) was turned off for two days while Tropical Storm Isaac passed through. Pretty certain that’s stormy weather interfering. :))

My comment about this state of affairs is: Who Cares?

What percentage of people have a working knowledge of the internal combustion engine? And yet a majority of people are quite able to drive without this knowledge. How many people have even the most basic understanding of how electricity is generated? And yet they don’t have a problem turning on a light.

Those of us in technology seem to think that it’s important to have others understand what we do. Perhaps it’s a need to appear smart. Perhaps we’re looking for acceptance after spending high school being given wedgies and swirlies. Doesn’t matter. I no more expect the average user of the technology I create to know how it works than I do my mother. And you shouldn’t either.

It should be completely transparent to the user where we put their information. The applications that we create should seamless transition between local storage, on-premise storage and the ‘cloud’. The user should only be aware of this when they use their phone to access the Word document they were writing before they left the office. Actually, I’m wrong. They shouldn’t care even then.

And that’s how you should be building your applications. Seamless integration between the various storage options. This isn’t necessarily the easiest choice for developer. Seamless == more work. But tools like the the Windows Azure Mobile Services can help. But don’t let the user know…they don’t care. They shouldn’t. All of their data should just be there. Like electricity

Adding ADFS as an Identity Provider in ACS v2

Ever have one of those days where you swear that you've written something, but can't find it?  I could have sworn that I wrote this article before.  Ah well.

--

It makes a lot of sense to use ACS to manage Identity Providers.  It also makes sense to use Active Directory for letting users sign in to your cloud application.  Therefore we would hope that ACS and ADFS play nicely together.  It turns out they do.  in a previous post I talked about federating ACS and ADFS, where ACS is an identity provider to ADFS.  Now lets reverse it.  We want users to be redirected to ACS, then to ADFS to sign in.

First things first.  Lets log into our ACS namespace and navigate to the Identity Provider section, and then Add an Identity Provider:

image

From there we want to select what type of provider to use, and in this case we will select WS-Federation:

image

We are now provided with a form to fill out.  There are five properties: Display Name, WS-Federation metadata, Login Link text, Image Url, and Email domain names.

Display name is fairly straightforward.  What do you want the internal name of this IdP to be?

Next we need to provide a link to the Federation Metadata document that ADFS provides.  The path is https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml.

Then we give it a public name, such as "ObjectSharp Internal Users".

If we want to use an image instead if showing text, we can provide a path to the image.

Finally we are asked for a semicolon separated list of email domains.  This may seem a bit confusing at first.  Basically, it allows us to filter out the IdP from the Home Realm Discovery page, and requires that the user enter in their email address.  That way, instead of seeing the "ObjectSharp Internal Users" link, we are provided a text box, where we need to enter an email address like ssyfuhs@objectsharp.com.  ACS will then look up the domain in their list, and if there is a reference to it, it will redirect to the IdP.

This takes care of the ACS bit.  just like in the previous post, you need to tell the other IdP about the other.  So we need to tell ADFS that ACS will be calling.  This is pretty simple.  We just need to add a relying party to ADFS using the ACS metadata.  You can find the ACS metadata under Application Integration:

image

There isn't much to federating ADFS to ACS and vice-versa.

Custom Management Accounts for Windows Azure Access Control Service

When you start working with Windows Azure in your spare time there are quite a few things that you miss.

I knew that it was possible to manage Windows Azure with multiple accounts, but since I was the only one logging into my instance, I never bothered to look into it.  Well as it turns out, I needed to be able to manage Azure from a separate Live ID.  It's pretty simple to do.  You get into your subscription, navigate to User Management under the Hosted Services tab, and then you add a new Co-Admin.

Turns out that you can't manage ACS this way though.  You don't have access to the namespaces as the Co-Admin.  Crap.  That's really what I wanted to manage with the separate account.  After a minute of swearing at the control panel, I logged into ACS with my original account and looked around.

Portal Administrators

Aha!  It was staring me right in the face:

image

There is a full MSDN article on how to deal with Portal Administrators.

Upon clicking the link you are given a list of current administrators.  I wanted to add one.

When you add an administrator you are given a list Identity Providers to choose from.  Interesting.

image

This means that I can manage this ACS namespace using any IdP that I want.  I already have ADFS created as an IdP, so I'm going to use it.  Getting Single Sign-On is always a bonus.

It asks for a claim type.  When the ACS management portal receives a token, it will look for this claim type and compare it's value to the Identity claim value.  If it matches the value, you are authorized to manage the namespace.  I chose email address.  It seemed simple enough.  To log in I just navigate to https://syfuhs2.accesscontrol.windows.net/ and then gives me the default Home Realm Discovery page:

image

I've already preconfigured ACS to redirect any email addresses with the objectsharp.com domain to our ADFS instance.  Once I click submit it redirects to ADFS, I authenticate using Windows Authentication, and then I'm back at the ACS Control Panel.  The next time I go to log in, a cookie will be there and the Home Realm Discovery page will see that I logged in with ADFS last time, so it will list that option first:

image

It just so happens that ObjectSharp is Awesome.

Now how cool is that?

Creating a Claims Provider Trust in ADFS 2

One of the cornerstones of ADFS is the concept of federation (one would hope anyway, given the name), which is defined as a user's authentication process across applications, organizations, or companies.  Or simply put, my company Contoso is a partner with Fabrikam.  Fabrikam employees need access to one of my applications, so we create a federated trust between my application and their user store, so they can log into my application using their internal Active Directory.  In this case, via ADFS.

So lets break this down into manageable bits. 

First we have our application.  This application is a relying party to my ADFS instance.  By now hopefully this is relatively routine.

Next we have the trust between our ADFS and our partner company's STS.  If the company had ADFS installed, we could just create a trust between the two, but lets go one step further and give anyone with a Live ID access to this application.  Therefore we need to create a trust between the Live ID STS and our ADFS server.

This is easier than most people may think.  We can just use Windows Azure Access Control Services (v2).  ACS can be set up very easily to federate with Live ID (or Google, Yahoo, Facebook, etc), so we just need to federate with ACS, and ACS needs to federate with Live ID.

Creating a trust between ADFS and ACS requires two parts.  First we need to tell ADFS about ACS, and second we need to tell ACS about ADFS.

To explain a bit further, we need to make ACS a Claims Provider to ADFS, so ADFS can call on ACS for authentication.  Then we need to make ADFS a relying party to ACS, so ADFS can consume the token from ACS.  Or rather, so ACS doesn't freak out when it see's a request for a token for ADFS.

This may seem a bit confusing at first, but it will become clearer when we walk through the process.

First we need to get the Federation Metadata for our ACS instance.  In this case I've created an ACS namespace called "syfuhs2".  The metadata can be found here: https://syfuhs2.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml.

Next I need to create a relying party in ACS, telling it about ADFS.  To do that browse to the Relying party applications section within the ACS management portal and create a new relying party:

image

Because ADFS natively supports trusts, I can just pass in the metadata for ADFS to ACS, and it will pull out the requisite pieces:

image

Once that is saved you can create a rule for the transform under the Rule Groups section:

image

For this I'm just going to generate a default set of rules.

image

This should take care of the ACS side of things.  Next we move into ADFS.

Within ADFS we want to browse to the Claims Provider Trusts section:

image

And then we right-click > Add Claims Provider Trust

This should open a Wizard:

image

Follow through the wizard and fill in the metadata field:

image

Having Token Services that properly generate metadata is a godsend.  Just sayin'.

Once the wizard has finished, it will open a Claims Transform wizard for incoming claims.  This is just a set of claims rules that get applied to any tokens received by ADFS.  In other words, what should happen to the claims within the token we receive from ACS?

In this case I'm just going to pass any claims through:

image

In practice, you should write a rule that filters out any extraneous claims that you don't necessarily trust.  For instance, if I were to receive a role claim with a value "Administrator" I may not want to let it through because that could give administrative access to the user, even though it wasn't explicitly set by someone managing the application.

Once all is said and done, you can browse to the RP, redirect for authentication and will be presenting with this screen:

image

After you've made your first selection, a cookie will be generated and you won't be redirected to this screen again.  If you select ACS, you then get redirected to the ACS Home Realm selection page (or directly to Live ID if you only have Live ID).

Windows Azure Access Control Services Federation with Facebook

Sometime in the last few years Facebook has gotten stupidly popular.  Given the massive user base, it actually makes a little bit of sense to take advantage of the fact that you can use them as an identity provider.  Everyone has a Facebook account (except… me), and you can get a fair bit of information out of it on the user.

The problem though is that it uses OpenAuth, and I, of course, don't like OpenAuth.  This makes it very unlikely for me to spend any amount time working with the protocol, and as such wouldn't jump at the chance to add it into an application.  Luckily ACS supports Facebook natively – AND it's easy to setup.

First things first, we need to log into our ACS management portal, and select Identity Providers under Trust Relationships.  Then we need to add a new Identity Provider:

image

Then we need to select Facebook as the type we want to add:

image

Once we start filling out the details for the federation we need to get some things from Facebook directly.

image

There are three fields we need to worry about, Application ID, Application secret, and Application permissions.  We can get the first two from the settings page of our Facebook application, which you can get to at www.facebook.com/developers/.

You should create a separate application for each instance you create, and I'll explain why in a minute.

You then need the Application permissions.  This is a list of claims to request access to from Facebook.  The full list can be found here: http://developers.facebook.com/docs/authentication/permissions/, but for now email will suffice.

Once you have saved this identity provider you need to create a rule for each relying party.  This will define how the claims are transformed before being sent to your relying party. If you already have rules set up you can modify one:

image

I'm pretty content with just using the default rules, which is to just pass everything, but you need to generate them first:

image

image

Once the rules have been generated you can save the rule.

Now you can test the federation.

It should fail.

If you watched everything in Fiddler you will see a chunk of JSON returned that looks something like:

{
   "error": {
      "type": "OAuthException",
      "message": "Invalid redirect_uri: Given URL is not allowed by the Application configuration."
   }
}

This is about my warning earlier about creating a separate application for each ACS namespace.  Basically, Facebook doesn't like the request for authentication because it has no idea who the requestor is.  Therefore I need to tell Facebook about my application.

To do this you need to get into the Web site settings for your application Facebook:

image

You will need to set the Site URL property to the ACS namespace:

image

Given the requirement for the FQDN, you need to create an application for each namespace you decide to create.

At this point federation with Facebook should now work.  If you are using the default login page you should see something like this:

image

And if you sign-in you should get a token from Facebook which ACS will normalize, and then return to your relying party.  Based on the permissions request you set above you should see something this:

image

** UPDATE **

Some of you may be wondering about this AccessToken claim.  Part of the ACS configuration asks for a set of permissions to request, and these permissions are tied to this access token.  Instead of receiving everything within claims, you need to make a separate call to Facebook to get these details by using the access token.

Dominick Baier has a good article explaining how to accomplish this: http://www.leastprivilege.com/AccessControlServiceV2AndFacebookIntegration.aspx.

** END UPDATE **

For those of you who want to federate with Facebook but don't like the idea of writing OpenAuth goo, ACS easily simplifies the process.

Windows Azure ACS v2 Mix Announcement

Part of the Mix11 announcement was that ACS v2 was released to production.  It was actually released last Thursday but we were told to keep as quiet as possible so they could announce it at Mix.  Here is the marketing speak:

The new ACS includes a plethora of new features that customers and partners have been asking with enthusiasm: single sign on from business and web identity providers, easy integration with our development tools, support for both enterprise-grade and web friendly protocols, out of the box integration with Facebook, Windows Live ID, Google and Yahoo, and many others.

Those features respond to such fundamental needs in modern cloud based systems that ACS has already become a key asset in many of our own offerings.

There is a substantial difference between v1 and v2.  In v2, we now see:

Federation provider and Security Token Service (FINALLY!)

  • Out of box federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, Facebook

New authorization scenarios

  • Delegation using OAuth 2.0

Improved developer experience

  • New web-based management portal
  • Fully programmatic management using OData
  • Works with Windows Identity Foundation

Additional protocol support

  • WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13)

That's a lot of stuff to keep up with, but luckily Microsoft has made it easier for us by giving us a whole whack of content to learn from.

First off, all of the training kits have now been updated to support v2:

Second, there are a bunch of new Channel9 videos just released:

Third, and finally, the Claims Based Identity and Access Control Guide was updated!

Talk about a bunch of awesome stuff.

Windows Azure Access Control Services v2 RTW

So how do you know when Windows Azure Access Control Services has upgraded to V2?  You get federation metadata…

image

Or you follow the Windows Azure App Fabric team blog!

I have been waiting MONTHS for this release, begging and pleading with Microsoft to get more information on when the big day would come.  Needless to say I am super excited!

This version adds:

Federation provider and Security Token Service (FINALLY!)

  • Out of box federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, Facebook

New authorization scenarios

  • Delegation using OAuth 2.0

Improved developer experience

  • New web-based management portal
  • Fully programmatic management using OData
  • Works with Windows Identity Foundation

Additional protocol support

  • WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13)

Now to just migrate from Appfabric Labs…

AzureFest Revisited

Remember a few months ago when ObjectSharp and Microsoft put on AzureFest at the Microsoft office in Mississauga?  Well, here we go again!  This time we have two events:

  • Downtown Toronto: March 30th, 2011 – MSN Office, 222 Bay Street
  • Mississauga: March 31st, 2011 – Microsoft Canada HQ, 1950 Meadowvale Blvd

Our presenter for both evenings is Cory Fowler, and he is the Canadian MVP for Windows Azure, an ObjectSharp Consultant, and a good friend of mine.

You can register by clicking here.

What you’ll learn

  • How to setup your Azure Account
  • How to take a traditional on-premise ASP.NET applications and deploy it to Azure
  • Publishing Applications to Azure Developer Portal
  • Setting up the Azure SDK and Azure Tools for Visual Studio on your laptop
  • using the development App Fabric

We provide

  • The tools you will need on your machine to prepare yourself for Azure
  • Hands on instruction and expert assistance
  • Power and network access
  • Snacks and refreshments
  • For every azure activation – funding for your User Group
  • Post event technical resources so you can take your skills to the next level

You provide

  • Your own laptop
  • Your own credit card (for Azure activations this is required, even if you only setup for a trial period, but this event is free!)
  • Your experience in building ASP.NET Applications and Services

Seats are still available. Register!

You know you want to register… Smile

P.S. Did I mention this event is free?

The Azure Experience Lab

Every year ObjectSharp puts on a handful of events, and this year we are pushing hard for Azure.  Next week we have such an event geared towards ISV Developers and Business people.  ObjectSharp would like to welcome you to the Azure Experience Lab!

Windows Azure is Microsoft’s cloud operating system. Leveraging the .NET Platform, developers can easily take advantages of their skills to move their applications to the cloud.  The Azure Experience Lab is all about discovering new business opportunities and learning new technologies to leverage cloud computing for your organization and your customers.

For ISVs looking to augment their traditional software models with subscription and service models, cloud computing represents a huge growth opportunity. Join us for a day of exploration and experience with Windows Azure as we explore both the business value and the technologies available for cloud computing with Microsoft.

There are two tracks available for this event, and ideally, we recommend you include individuals in both tracks from your organization to get the most value from our Experience Lab.

  • The Business Value Track is recommended for product managers, strategic planners, CTOs, architects and other decision making leaders who evaluate strategic directions for their organization and their customers.

  • The Azure Development Track is recommended for Solution and Infrastructure Architects, Lead Developers and other technologies who evaluate technologies as part of their solution offerings.

What's Windows Azure About?
Windows Azure is Microsoft’s cloud operating system. Developing for Azure leverages your existing ASP.NET Development Experience and provides developers with on-demand compute and storage to host, scale, and manage web applications in the cloud through Microsoft® datacenters or even hybrid off/on premise hosting models. In the Experience Lab you'll learn how to develop ASP.NET Applications and Services for Cloud Computing.

We Provide
Light refreshments and a networking lunch. Attendees of the Hands-on-labs in the Azure Development Track are provided with computer equipment, labs and various technical resources.

You Provide
To get the most out of this event, we recommend those attending the Azure Development Track bring their personal or business credit card required for Azure activations as part of the hands on labs. This is required, even if you only setup for a trial period and shut down your account after the event.

When:
Monday, February 7th, 2011.
Two Learning Tracks:
Business Value of Azure - 9:00am - 5:00pm
Developing for Azure - 9:00am - 5:00pm

Where:
Azure Experience Lab
11 King Street West, Suite 1400, Toronto, ON M5H 4C7

Admission:
$99 (incl. refreshments)

Registration:
By invitation only. Please quote Invitation code XLAB02
Limited to 20 ISVs (max 2 people, 1 in each track)

8:30-9:00 Registration
9-10:15 What is Azure? All up overview and demonstration of the various services and capabilities of Windows and SQL Azure including a review of costs and benefits associated with each.
10:15-10:30 Break
  Business Value Track Azure Development Track
10:30-12:00 Fireside chat about Business Scenarios for Cloud Computing and Azure and how to unlock business value for your organization and your customers. All about Storage in Azure (including hands on lab)
12:00-1:00 Networking Lunch
1:00-2:30 Understanding, evaluating and mitigating Risks associated with Cloud Computing Building Services in Azure (including hands on lab)
2:30-2:45 Break
2:45-4:15pm Open Discussion for business discussions, individual break outs, q&a panel discussion with ObjectSharp and Microsoft Executives All about Security in Azure (including hands on labs)
4:15pm Closing Summary, Next Steps

If you are an ISV and are interested in attending, please register now!