App Fabric ACS -- Explained clearly.

AppFab:ACS

I’m going to assume you understand a little of the basics of federation for this part of the post. If you don’t -  read my federation primer to get yourself up to speed.

When you place an instance in Azure and you “protect” it using AppFab:ACS, you are typically crossing an organisational boundary. There are reasons you might not be doing that – which we’ll come to in a moment. For now, let’s assume you are say, a SaaS service provider. You have written the most fantastic expense submission application and everybody wants to use it.

You don’t want to go to the trouble of having to manage the users. You want to provide the service. So you set up federation trusts with those companies that want to use your service. They create the users, set their passwords, determine if the accounts are enabled or disabled. They delete the accounts when they are no longer relevant, they set password complexity policy, expiration policy and so on. If a user forgets their password they go to their own company’s helpdesk to get it reset, not yours.

They do this by configuring a service that sits on top of their Active Directory called Active Directory Federation Services 2.0 (ADFS 2.0). You in your turn configure the Windows Azure Application Fabric’s Access Control Service (AppFab:ACS) with details of your application and vice versa, you configure your application with details of your partition of AppFab:ACS.

You then set up a federation trust with any company that wants to access your application. This involves the exchange of URLs and certificates between their ADFS2 server and your partition of AppFab:ACS. There are metadata endpoints to simplify this process. Of course, you could set this up between your own company’s ADFS2 server and your own instance of AppFab:ACS, as shown below:

Now, when a user from your application wants to use the application you have deployed to the cloud, it will be as if the application lives inside your AD. It doesn’t, but the experience they would have is like this:

1. It’s 09:00, Fred comes in to the office, hits CTRL-ALT-DEL and enters his AD credentials to log in to the domain.
2. It’s 10:00 and he now needs to enter his expenses. He clicks a desktop icon which is a URL shortcut to the application in the cloud.
3. The application opens, says “Welcome back Fred” and he uses the application to submit his expenses.

He was never prompted for credentials because of the way the dance works with federation/ADFS2 and Active Directory. The dance is explained in my federation primer, but what essentially happens is this:

1. Fred clicks the icon and his browser takes him to the application
2. The application redirects his browser to your partition of AppFab:ACS
3. AppFab:ACS sees that Fred has come from its federation partner and redirects Fred's browser to his own ADFS2 server.
4. On trying to reach the ADFS2 server, an authentication takes place. It’s all built-in to Windows and done through Kerberos. It’s entirely invisible to Fred as a user, the same as when he goes to a domain-joined IIS machine using Windows authentication. The authentication just works under the covers.
5. On successful authentication, the ADFS2 server pushes Fred back to AppFab:ACS and appends a SAML token which it encrypts and digitally signs. If you need to understand encryption and signatures, read my crypto primer.
6. AppFab:ACS receives the token, decrypts it and checks the digital signature. It is now assured the token has been issued by its federation partner.
7. AppFab:ACS creates a new token and copies the claims in the original token in to the new token. At this point it might also do something called claims transformation. If you need to understand this – again, read the federation primer.
8. It digitally signs and encrypts the token (optional) and redirects Fred’s browser back to the application it started appending the new SAML token.
9. The application decrypts the token and checks the signature. It verifies the token was definitely issued by your partition of AppFab:ACS and grants access to Fred. Fred never had to enter a password, other than the password he entered when he logged on to AD at 09:00 when he started work. 

Taken from Link : http://blogs.msdn.com/b/plankytronixx/archive/2010/11/06/difference-between-an-azure-app-domain-joined-to-your-active-directory-and-an-azure-app-joined-to-your-active-directory-through-appfab-acs.aspx

Article written by: Planky

Why you SHOULD NOT deploy an AD domain controller using Azure Connect with VM Role

I’ve heard a lot of talk recently about the forthcoming Windows Azure Connect service, combined with the soon-to-be-released-to-CTP of VM Role giving the possibility of hosting an Active Directory Domain Controller in the cloud. Although technically feasible, this post is designed to tell you why you shouldn’t do that.

The Web Role, Worker Role and VM Role all include local storage. Even a Windows Server at idle is actually doing quite a lot and making constant updates to the disks – and so it is with an instance deployed to the cloud as well. In Windows Azure, the state of a virtual machine (an instance) is not guaranteed if ever it restarts because of some sort of failure.  

Web and Worker Roles do persist the OS state across re-starts generated by automated updates; ones initiated by the fabric. With the VM Role there is no automated update process. It’s down to the owner of the VM Role to keep it up-to-date. Yes – there is a process for this which involves a differencing disk that is added to the base VHD that you supply when you first startup a VM Role in Windows Azure. However, the problem really exists with failures. 

A failure of a VM Role can be caused by any number of things. Power Supply failure to the rack, hard drive head-crash, failure of the hardware server the VM is hosted on plus a decent range of other hardware problems. The same for software. As they say “there’s no such thing as bug-free software”. Every so often the host OS or even the guest OS – the OS running in the VM you created, could happen across an unusual set of conditions while in kernel mode for which there is no handler. 

Well, if there is no handler, it means nobody thought such a condition would ever occur. The default behaviour of the kernel is to assume something has gone wrong with the kernel itself: it’d be dangerous to continue with a kernel in an unknown state. Think of the damage that could be caused. And so control is handed to a special handler – the one that causes the blue-screen fatal bugcheck. The resulting dump file may be useful in debugging what caused the problem after the event, after the operating system was stopped in its tracks by the bugcheck code. But this could happen to either the host OS or your VM. 

When it does happen, the heartbeat that is emitted to the fabric by a special Windows Azure Agent installed in every instance managed by the cloud will stop. Eventually the fabric will recognise a timeout has occurred. It’s first concern is to get a new responsive instance up and running. It is very likely it won’t be on a host even in the same rack, let alone exactly the same host. Therefore, no guarantee is ever given for these situations that state will be preserved.

The fabric will take the base VHD, plus the collection of differencing disks (the ones that contain your OS updates) and “boot” that back in to the configuration specified in your service model. This diagram explains the problem.

Use the numbered points in the diagram to follow along:

1. The base VHD plus the differencing VHD is used to create…
2. ..a running instance of a Domain Controller as a Windows Azure VM Role
3. The downward pointing green arrow represents the life of this Domain Controller. Let’s assume the life between instantiating the VM and the catastrophic failure (at step 5) is 61 days (or longer).
4. As time advances, more and more changes are written to the Domain Controller. In the diagram I have shown this as being performed by a series of administrators. In reality  though, it doesn’t matter how the changes get to the DC. Either directly or because of AD replication, say from an on-premise DC. The rules for hanging on to objects are the same. Deleted objects are tombstoned.
5. A catastrophic failure of some description occurs and the instance immediately goes offline.
6. The Windows Azure Fabric recognizes the absence of the heartbeat and builds a new instance from the base and differencing VHDs. These VHDs are used to create a new instance…
7. …and the result is that all the changes that have accrued in the intervening 61 days are now lost. If there is another online DC, say in an on-premise environment, it will refuse to speak to this “imposter”. The password will have changed twice in the intervening 60 days and the tombstone timeout will have occurred. You therefore cannot rely on replication to get this DC back in to the state it was before the failure.

Essentially, having the fabric fire-up a new DC based on an out-of-date image is a bit like the not-recommended practice of running DCPromo on a Virtual Machine and therefore getting a copy of the domain database on to the machine. Then taking it offline and storing the VHD as the “backup” of AD. Re-introducing that DC back in to the network after a time will cause it to be ignored in the same way for all the same reasons.

The risk with having applications that can use Windows Integrated Authentication in the cloud is that if the network between your on-premise Domain Controllers and the apps you have in the cloud goes down, the apps can’t be used. 

It therefore appears to be the case that a VM Role deployed as a Domain Controller up in the cloud and using Windows Azure Connect to give full domain connectivity is a good idea. And indeed it is – until a failure occurs. 

But remember, you can domain-join your Azure based apps to a local DC, and on that point, Windows Azure Connect is a great way to be able to quickly deploy AD-integrated apps to Azure without massive re-engineering effort.  Because your local DC is part of your infrastructure it will be managed as such and won’t be subject to the service model that is the basis for anything running in Azure. If anything this scenario is a very practical demonstration of why it is that VM Role !== IaaS.

Of course if somebody could come up with a way for the DC to store its directory data in blob storage, which is persistent across instance reboots, then we’d have a neat solution. Maybe that’s an opportunity for a clever ISV partner to exploit. In the meantime – take the opposite sentiment to Nike’s strapline – “Just Don’t Do It”.

Windows Azure VM Role: Looking at it a different way

The debate regarding PaaS vs. IaaS continues at pace. It seems as though no mention of this debate where Windows Azure is concerned, is complete without a frequently misunderstood notion of what the recently announced VM Role is. Many commentators are saying “It’s Microsoft’s IaaS offering”.

Let me put forward a way of explaining what it is:

With a PaaS service like Windows Azure, the developer creates an application package and hands that, plus a configuration, over to Microsoft and says “can you run this package in your Data Centre, according to this configuration”. Windows Azure goes ahead and runs the application. The fact that it spins up a VM to house the application, in theory, should not concern the developer. The existing Web and Worker Roles work in exactly this way.

When you hand over the package, it consist of all the files and resources needed to run the application. It’s rolled in to a file called a .cspkg file, a “cloud service package” file. The configuration or .cscfg accompanies the package. There is no guarantee of state for the application. If it fails for some reason, it must be capable of picking up where it left off and it’s down to the developer to work out how that is going to happen – perhaps by using persistent storage like blob or table storage.

The Windows Azure fabric has no knowledge of the internals of the application. Imagine a bug is identified – Windows Azure will not create and apply a patch to the application. We know that for the Web and Worker Roles, it will apply patches and fixes – ones that Microsoft has identified – to the operating system but not to the application itself.

The way to look at the VM Role is that the entire thing is a Windows Azure application. You don’t send a .cspkg file, but instead, the package is a .vhd file. Now, because these files are likely to be huge in comparison to a .cscfg, Windows Azure has created a method of updating with differencing disks, but that’s just an implementation detail. You can think of a VM Role application package as the .vhd file.

As is the case with the .cspkg, Windows Azure has no visibility to the internals of the application. Just as with a .cspkg application, it is the developer’s responsibility to keep it up to date, apply bug fixes, patches, updates etc. Only with an entire .vhd, the “application” updates are the patches, fixes and service packs of the OS itself plus any updates to the developer-built part of the “app”.

The application is still subject to the service model, it’s just the application package file-type that is diferent (.vhd) and the scope of the application is different (it includes the entire OS). Other than those differences, it’s a PaaS application that runs on Windows Azure, subject to the service model and all the other benefits and constraints, just like the Web and Worker Roles.

I hope this viewpoint helps describe VM Role as a PaaS offering and not the confusing IaaS that many folks think it mimics.

Article posted at http://blogs.msdn.com/b/plankytronixx/archive/2010/11/27/windows-azure-vm-role-looking-at-it-a-different-way.aspx

Article written by: Planky

BidNow Sample for Windows Azure

BidNow has been significantly updated to leverage many pieces of the Windows Azure Platform, including many of the new features and capabilities announced at PDC and that are a part of the Windows Azure SDK 1.3.  This list includes:

• Windows Azure (updated)
  • Updated for the Windows Azure SDK 1.3
  • Separated the Web and Services tier into two web roles
  • Leverages Startup Tasks to register certificates in the web roles
  • Updated the worker role for asynchronous processing
• SQL Azure (new)
  • Moved data out of Windows Azure storage and into SQL Azure (e.g. categories, auctions, buds, and users)
  • Updated the DAL to leverage Entity Framework 4.0 with appropriate data entities and sources
  • Included a number of scripts to refresh and update the underlying data
• Windows Azure storage (update)
  • Blob storage only used for auction images and thumbnails
  • Queues allow for asynchronous processing of auction data
• Windows Azure AppFabric Caching (new)
  • Leveraging the Caching service to cache reference and activity data stored in SQL Azure
  • Using local cache for extremely low latency
• Windows Azure AppFabric Access Control (new)
  • BidNow.Web leverages WS-Federation and Windows Identity Foundation to interact with Access Control
  • Configured BidNow to leverage Live ID, Yahoo!, and Facebook by default
  • Claims from ACs are processed by the ClaimsAuthenticationManager such that they are enriched by additional profile data stored in SQL Azure
• OData (new)
  • A set of OData services (i.e. WCF Data Services) provide an independent services layer to expose data to difference clients
  • The OData services are secured using Access Control
• Windows Phone 7  (new)
  • A Windows Phone 7 client exists that consumes the OData services
  • The Windows Phone 7 client leverages Access Control to access the OData services 
  
  
  For  more details and to download Code sample of BidNow, Check this link
  http://www.wadewegner.com/2010/11/significant-updates-released-in-the-bidnow-sample-for-windows-azure/

Windows Azure SDK 1.3 Released with Many New Features!

Hi Friends,

Check this link below for more details 

http://blogs.msdn.com/b/ignitionshowcase/archive/2010/11/30/windows-azure-sdk-1-3-released-with-many-new-features.aspx?utm_source=AzureMagic&utm_medium=twitter

Windows Azure Platform Training Kit November 2010 Update

The November release of the training kit includes several new hands-on labs for the new Windows Azure features and the new/updated services we just released a few weeks ago PDC.  The updates in this training kit include:

• [New lab] Advanced Web and Worker Role – shows how to use admin mode and startup tasks
• New lab] Connecting Apps With Windows Azure Connect – shows how to use Project Sydney
• [New lab] Virtual Machine Role – shows how to get started with VM Role by creating and deploying a VHD
• [New lab] Windows Azure CDN – simple introduction to the CDN
• [New lab] Introduction to the Windows Azure AppFabric Service Bus Futures – shows how to use the new Service Bus features in the AppFabric labs environment
• [New lab] Building Windows Azure Apps with Caching Service – shows how to use the new Windows Azure AppFabric Caching service
• [New lab] Introduction to the AppFabric Access Control Service V2 – shows how to build a simple web application that supports multiple identity providers
• [Updated] Introduction to Windows Azure - updated to use the new Windows Azure platform Portal
• [Updated] Introduction to SQL Azure - updated to use the new Windows Azure platform Portal

In addition, all of the HOLs have been updated to use the new Windows Azure Tools for Visual Studio version 1.3 (November release).   In the next update we will also include presentations and demos for delivering a full 4-day training workshop. 

You can download the November update of the Windows Azure Platform Training kit from here:  http://go.microsoft.com/fwlink/?LinkID=130354

Finally, we’re now publishing the HOLs directly to MSDN to make it easier for developers to review and use the content without having to download an entire training kit package.  

You can now browse to all of the HOLs online in MSDN here:  http://go.microsoft.com/fwlink/?LinkId=207018

SQL Azure Federation

Redmond Diary

SQL Azure Federation: Is it "NoSQL" Azure too?

With all the noise (not to mention the funk) around HTML5 and Silverlight at PDC 2010, we could be forgiven for missing the numerous keynote announcements about Windows Azure and SQL Azure. And with all those announcements, we could be forgiven for missing the ostensibly more arcane stuff in the breakout sessions. But one of those sessions covered material that was very important.

That session was Lev Novik's "Building Scale-out Database Applications with SQL Azure," and given the generic title, we could be further forgiven for not knowing how important the session was. But it was important. Because it covered the new Federation (aka "sharding") features coming to SQL Azure in 2011. Oh, and by the way, you'd also be forgiven for not knowing what sharding was. Perhaps a little recent history would help.

When SQL Azure was first announced, its databases were limited in size to 10GB, in the pro version of the service. That's big enough for lots of smaller Web apps, but not for bigger ones, and definitely not for Data Warehouses. Microsoft's answer at the time to criticism of this limitation was that developers were free to "shard" their databases. Translation: you could create a bunch of Azure databases, treat each one as a partition of sorts, and take it upon yourself to take the query you needed to do, and divide it up into several sub queries -- each one executing against the correct "shard" -- and then merge all the results back again.

To be honest, while that solution would work and has architectural merit, telling developers to build all that plumbing themselves was pretty glib, and not terribly actionable. Later, Microsoft upped the database size limitation to 50GB, which mitigated the criticism, but it didn't really fix the problem, so we've been in a bit of a holding pattern. Sharding is sensible, and even attractive. But the notion that a developer would have to build out all the sharding logic herself, in any environment that claims to be anything "as a service," was far-fetched at best.

That's why Novik's session was so important. In it, he outlined the explicit sharding support, to be known as Federation, coming in 2011 in SQL Azure, complete with new T-SQL keywords and commands like CREATE/USE/ALTER FEDERATION and CREATE TABLE...FEDERATE ON. Watch the session and you'll see how elegant and simple this is. Effectively, everything orbits around a Federation key, which then corresponds to a specific key in each table, and in turn determines what part of those tables' data goes in which Federation member ("shard").

Once that's set up, queries and other workloads are automatically divided and routed for you and the results are returned to you as a single rowset. That's how it should have been along. Never mind that now.

Sharding does more than make the 50GB physical limit become a mere detail, and the logical size limit effectively go away. It also makes Azure databases more elastic, since shards can become more or less granular as query activity demands. If a shard is getting too big or queried too frequently, it can be split into two new shards. Likewise, previously separate shards can be consolidated, if the demand on them decreases. With SQL Azure Federation, we really will have Database as a Service... instead of Database as a Self-Service.

But it goes beyond that. Because with Federation, SQL Azure gains a highly popular feature of so-called document-oriented NoSQL databases like MongoDB, which features sharding as a foundational feature. Plus, SQL Azure's soon-to-come support for decomposing a database-wide query into a series of federation member-specific ones, and then merging the results back together, starts to look a bit like the MapReduce processing in various NoSQL products and Google Hadoop. When you add to the mix SQL Azure's OData features and its support for a robust RESTful interface for database query and manipulation, suddenly staid old relational SQL Azure is offering many of the features people know and love about their NoSQL data stores.

While NoSQL databases proclaim their accommodation of "Internet scale," SQL Azure seems to be covering that as well, while not forgetting the importance of enterprise scale, and enterprise compatibility. Federating (ahem!) the two notions of scale in one product seems representative of the Azure approach overall: cloud computing, with enterprise values. 

Posted by Andrew J. Brust on 11/23/2010 at 6:46 AM

All-In-One Windows Azure Code Samples

Download Windows Azure Code Samples

 http://www.blogger.com/post-create.g?blogID=1293666849220235595

Connect SQL Azure DB using Web Role

Hi Friends,

Unable to connect to SQL Azure DB directly? Having Firewall problems? 

Want an alternate way ??

Check this link below for answers:

http://geekswithblogs.net/JoshReuben/archive/2010/11/25/sql-azure-and-windows-azure-together.aspx

Windows Azure AppFabric: A Strategic Core of Microsoft's Cloud Platform

Check the link below.

http://www.gartner.com/technology/media-products/reprints/microsoft_mapp/vol2/article14/article14.html