On Tuesday night last week I attended my first London Windows Azure user group meeting – it’s the second time this new group have met, but the first one I’m managed to make it to. My colleague Simon Hart blogged about the inaugural event here.
There were about 35 attendees or so and it felt like a good crowd, asking intelligent questions and I had some interesting chats during the breaks with some other user group members and I also caught up with Yossi Dahan (a Microsoft technical architect I’ve met before) – it really feels like this young user group has some momentum – so hats off to the organisers for getting this off the ground! The good pizza, chips, and beer also always helps 
– this must be one of the best catered user group meetings I’ve ever been to – there was even someone opening my beer bottle for me…
Planky (aka Steve Plank from Microsoft) presented on two topics relating to different strategies for identity federation and application access control – Azure’s Access Control Service (ACS) and Azure Connect.
Most of the the presentation time was allocated to ACS – which is pretty intricate to use. Well – it’s probably fairer to say that there are plenty of moving parts and technologies to get to grips with if you want to federate identities from Active Directory on-premise using ADFS2, via ACS in Azure to a set of applications hosted in Azure (which will typically using Windows Identity Foundation – WIF – to process the security token issued by ACS). None of it is particularly tricky in itself, but the great man himself hit some issues along the way (which always makes for a better presentation anyway ) and I was left thinking that it was a bit of nightmare to troubleshoot exactly why user access to the end application (the “relying party”) was being denied (see the image above) – it’s just the joys of debugging a distributed architecture I guess.
Azure Connect is essentially a VPN and IPSEC tunnel offering that I guess is very roughly equivalent to the Virtual Private Cloud (VPC) offering from AWS, but with some significant differences – but it’s trying to address the same key requirement – seamless but secure network connectivity between on-premise and cloud-based networks. It’s still in beta (at least until Summer 2012) and has some inherent limitations such as the fact that it requires a separate installation of agent software on every on-premise server that will talk to/from Azure, but it looks like an interesting technology. My main concern was just whether our customer’s security team’s could live with this model though – as in addition to the installation requirement, it essentially avoids any corporate firewall by creating an out bound SSL (port 443) connection to the Relay Service on Azure, effectively creating a client-to-site VPN from each individual on-premise server to the Relay Service.
So overall – a very useful and interesting evening, I’m glad I attended and I recommend my Smart421 colleagues to make the effort to attend future events (which are planned to be monthly) – the next event (register here) is on the 7th Feb and relates to “Parallel Processing with Azure and HPC Server“, so I’m personally very interested to hear how this compares to AWS’s offerings in this area.
