Bilder från TechDays-presentationer

Actives gaddning

Sveriges största Microsoft-konferens Techdays som hölls förra veckan i Örebro blev ett riktigt roligt event för oss på Active Solution: vi hade fyra talare på nio olika sessioner; vi vann Microsoft Awards med Azure-lösningen vi byggt åt film2home och vi lyckades få en stor andel Techdays-deltagare, inklusive Microsofts VD Per Adolfsson, att bära vår tatuering 🙂

I tisdags höll jag en session på pre-konferensdagen om REST-baserade tjänster med det nya ramverket ASP.NET Web API. Powerpoint-bilderna från presentationen “REST på Microsoft-stacken” finns här.

I onsdags höll jag en presentation som handlade om hur du migrerar befintliga system till Windows Azure. Powerpoint-bilderna från presentationen “Migrera befintliga system till Azure” finns här. Denna session spelades också in och kommer (hoppas jag) göras tillgänglig via TechDays-webben.

Category: Techdays

SDC2012, TechDays och Devsum12 – konferensvåren är här!

*måste. låta bli. kommentera. att jag inte bloggat på länge…*

Äntligen är våren här! (även om det inte känns som det i Stockholm just för tillfället, snö och iskallt… brrr).

Med våren kommer också ett späckat konferensschema. Här är de konferenser som jag själv kommer medverka på:

Category: Konferenser

Jfokus och ett tips om OWASP

Igår hade jag förmånen att kunna delta i Sveriges största Java-konferens – Jfokus, en konferens som stadigt växt sedan starten 2007 och som i år för andra året i rad hölls på Stockholm Waterfront-centret.
Men Robert – du är ju en .NET-kille – vad gör du på en Java-konferens??? Jag gick första gången på Jfokus 2009, då genom min gamla arbetsgivere Microsoft då vi hade en monter på plats och även höll sessioner om interoperabilitet, säkerhet och RIA. Det som slog mig då och som fortfarande gäller är hur mycket av sessionerna som är extremt relevanta och intressanta även för mig – även om jag råkar utveckla primärt på Microsoft-plattform.

Många sessioner på Jfokus handlar om designprinciper, mönster och arkitektur – och är precis lika relevanta för mig som bygger .NET-baserade lösningar som för någon som arbetar med Java. Även om implementationsdetaljerna skiljer sig åt så skiljer sig t.ex. CQRS i tänk inte det minsta åt mellan de båda världarna. Inte heller möjligheterna (och hoten) som kommer med den enormt snabba utvecklingen inom JavaScript och REST-baserade klienter.

Det var faktiskt en av de absolut bästa sessionerna som jag såg: Application Security for Rich Internet Applications – som John Wilander som till vardags arbetar på Handelsbanken höll. John körde en demospäckad session där han extremt pedagogiskt (läs – tom jag förstod hur attackerna funkade 😉 visade hur en attackerare med extremt enkla medel kan injecera och exekvera script på din maskin via en betrodd sajt eller använda din session för att attackera en sajt du har besökt. Scary stuff!

John är drivande i OWASP (The Open Web Application Security Project) – en öppen, icke-kommersiell community som arbetar för att höja säkersmedvetandet bland webbutvecklare och som erbjuder verktyg och utbildning för att förbättra säkerheten i webblösningar. Ett bra tips om du arbetar med webbutveckling i någon form, eller bara vill hålla dig ajour om IT-säkerhet generellt, är att kolla in svenska OWASP-sidan och anmäla dig till deras nyhetsbrev: http://owaspsweden.blogspot.com/

Category: Jfokus, OWASP, Säkerhet

Repris på populärt lunchseminarie den 8/2: Systemutveckling i molnet

Seminariet om systemutveckling i molnet som jag och Chris Klug höll i november var så lyckat att vi bestämde oss köra en repris på det onsdagen den 8:e februari.

Om du missade det första seminariet så kom förbi och ta del av våra praktiska erfarenheter från att ha medverkat i ett antal Windows Azure-projekt. Förhoppningsvis kan vi bjuda på lite intressanta diskussioner efteråt kring ämnet – men naturligtvis bjuder vi även på lunch 🙂

Läs mer och anmäl dig här.

Category: azure, seminarie

Single Sign On and Federated Security in the Cloud

Some time ago I wrote a couple of blog posts on Claims based SSO in Azure for the Windows Azure Architect training – but they seem to have gone AWOL so I’m re-posting as a series of posts here:

Single Sign On and Federated Security in the Cloud – part 1 – The SSO-challenge when moving your application to the cloud

Single Sign On and Federated Security in the Cloud – part 2 – Claims Based Identity

Single Sign On and Federated Security in the Cloud – part 3 – Windows Identity Foundation and AD FS 2.0

Single Sign On and Federated Security in the Cloud – part 4 – Identity Federation

Single Sign On and Federated Security in the Cloud – part 5 -Windows Azure AppFabric Access Control

Single Sign On and Federated Security in the Cloud – part 6 – some recommended resources

Category: sso, azure, english

Single Sign on and Federated Security in the cloud – part 6

Recommended resources

The great sample application FabrikamShipping is developed by the Windows Azure Platform Evangelism Team. This project contains both a working demo and the complete source code showing you have to create an end to end SAAS solution running in Windows Azure using federated security both against public identity providers and private Security Token Services.

My colleague Chris Klug has written an excellent blog post on implementing Federated Security with Access Control Service.

Here are some other good resources if you want to get more information on Claims based SSO, WIF and Access Control Serivce:

Category: sso, azure, english

Single Sign On and Federated Security in the cloud – part 5

Federation with Azure Access Control Service

Windows Azure AppFabric Access Control

Access Control is part of the AppFabric set of middleware services in Windows Azure. It provides a central point for handling federated security and access control to your services and applications, running in the cloud or on premise. AppFabric Access Control has built in support for federating against AD FS 2.0 – or any custom identity provider that supports the WS-Federation protocol.

In addition to supporting web based and SOAP based federation scenarios, Access Control also support federation using the OAuth protocol and REST based services. It has a web based management portal as well as OData based management services for configuring and managing the service.

The Access Control service has a rule engine that can be used to transform the incoming claims, thus being able to translate from a certain set of claims to another set of claims. It can also translate token formats to/from SAML 1.0, SAML 2.0 and Simple Web Token (SWT) formats.

Using the Access Control service you set up trust between the service and every STS that you want to federate with, including your own AD FS 2.0 STS:

Federated Identity through Windows Azure AppFabric Access Control

In this case your application running in Windows Azure still only has one point to point trust – to the Access Control service – and all the dependencies to the business partners are managed by this service.

Below is a sequence diagram showing the generic flow for single sign on using the Access Control service. The terms used in the diagram maps to our example as:

Client – the client in our domain or our business partner’s domain.

Identity Provider – our Active Directory + AD FS2 or our business partner’s STS.

Relying party – our application running in Windows Azure

Sequence diagram login ACS

The above diagram shows the flow when the application is a web application and the client is a web browser client (also known as a ‘passive client’). If the application would expose web services that a locally installed smart client (an ‘active client’) would consume, for example WCF services consumed by a WPF client – the first step in the sequence would be to directly login to the identity provider – instead of being redirected to a login page.

Federation with public Identity Providers

Windows Azure Access Control also let you use some of the largest public Internet services as Identity Providers. Out of the box there is built in support for using Windows Live ID, Facebook, Yahoo and Google as identity providers. The Access Control service handles all protocol transitions between the different providers, including Open ID 2.0 for Google and Yahoo, Facebook Graph for Facebook, and WS-Federation for Windows Live ID. The service then delivers a single SAML 1.1, SAML 2.0, or SWT token to your web application using the WS-Federation protocol once a user is signed in.

This is of course a really interesting feature when you are building public facing consumer oriented services, but could also be really useful in business to business scenarios. If for example you are building a SAAS solution, using the public identity providers like Facebook and Windows Live ID could be the option for smaller businesses while your enterprise customers could use their own STS for federation.

Here are some recommended resources if you want to dig deeper into the subject.

Category: sso, azure, english

Single Sign On and Federated Security in the cloud – part 4

WIF and ADFS for Azure based solution

In the last blog post we looked at how we could accomplish Single Sign On with WIF and AD FS 2.0 when moving on premise solutions to Windows Azure:

Claims Based Identity with WIF and AD FS for an application running in the cloud

This approach is all well as long as the users can be authenticated against the Domain Controller.

But what happens when a business partner need to access the same application running in Windows Azure?

One solution would be to set up new accounts for the partner in Active Directory and install a AD FS 2.0 Proxy in the DMZ. The business partner would then access the Proxy, authenticate to the Proxy with their credentials and that way get a valid SAML token that would grant them access to the application.

There are however a couple of serious disadvantages to that approach:

  • You now have to administrate users that don’t belong to your domain which leads to increased costs and challenges keeping the accounts up to date. This could possibly have security implications as well (how do you get alerted when a certain user is no longer employed by the business partner for example).
  • There is no single sign on for the business partner as they have to sign in through the AD FS proxy. That means that they have to handle a separate username and password to be able to connect to your application, which of course has security implications as well (i.e. keeping the username and password on little yellow stickers on the screen)

A much nicer scenario would be to set up Identity Federation between your organization and the business partner. One way to do that could be to let the application running in Windows Azure trust a Security Token Service located at the business partner. This however is not a good option when you have several applications that you want to federate. You would then have to create many point to point trusts (between each application and each business partner) which would become a real challenge to manage over time.

A better option would be to set up the federation between your STS and the partners STS. Your partners would be redirected to their own STS what would provide a SAML token that your STS would exchange for a token valid for the application running in Windows Azure:
Federation in Azure with multiple business partners
Federated Identity with many business partners

In this case your application running in the cloud still only has one point of trust – to your own STS in the form of AD FS 2.0.

Your business partners now have single sign on from their domain to your application and you do not have to administrate their users. However – your AD FS 2.0 proxy now becomes a business critical single point of failure in your architecture. If there would be a failure in the proxy server, or firewall or the network that connects it to the domain, no business partners would be able to log in to the application. You could of course set up redundancy with duplicated hardware and servers. But what if there would be a way to get rid of the need for a proxy altogether? What if you could utilize an existing cloud solution that provides a scalable and redundant service for handling federated security?

In the next blog post we will look at Windows Azure AppFabric Access Control – a service that provides exactly that functionality.

Category: sso, azure, english

Presentation från SWAG: federerad säkerhet med Azure Access Control Service

Igår medverkade jag på Swedish Windows Azure Usergroup och SWENUGs julavslutning. Sergio Molero och Marcus Söderberg körde en intressant (och läskig!) presentation om säkerhet på Internet. Jag höll en dragning om federad säkerhet mha Windows Azure Service Bus.

Stor eloge till Alan Smith och ConcreteIT för ett mycket bra arrangemang och en trivsam kväll!

Mina bilder från presentationen om federad säkerhet i Azure.

Category: azure, sso, swag

Single Sign On and Federated Security in the cloud – part 3

The WIF object model

Windows Identity Foundation and AD FS 2.0

Some time ago the Identity Division at Microsoft started working on a project code named ‘Geneva’ with the goal to make it significantly easier to implement claims based identity in Windows based solutions. In 2008 the first preview of the resulting products where released and in November 2009 Windows Identity Foundation (WIF) and Active Directory Federation Services version 2 (AD FS 2.0) hit RTM.
Below is an overview of WIF and ADFS 2.0 taken from the whitepaper “Single Sign-On from Active Directory to a Windows Azure Application”:

AD FS 2.0
AD FS 2.0 is a key component in Windows based federated security. In its role as a security token service (STS), it authenticates users and generates authorization information. It does this by implementing web-compatible protocols, including WS-Federation, WS-Trust adn SAML 2.0. AD FS 2.0 is an infrastructure component. This means it is typically managed by IT staff and not by developers. Developers should understand enough about AD FS 2.0 so that they can communicate requirements for claims required by the applications they are developing.

WIF
WIF is a developer framework that enhances the .NET Framework capabilities. WIF integrates seamlessly with the existing mechanisms in the .NET Framework for working with identity, namely the interfaces IPrincipal and IIdentity. WIF extends those interfaces with IClaimsPrincipal and IClaimsIdentity. The beuty of IClaimsPrincipal and IClaimsIdentity is that they still can take advantage of existing access control mechanisms, such as IsInRole() and the element. They also contain additional members that carry the claim collections that are extracted from the incoming authentication token that AD FS 2.0 generates.

The WIF claims object model

As you can see WIF allows us to keep our existing authorization checks intact by using the familiar IPrincipal interface. WIF achieves this by mapping incoming Name- and Group-claims to the corresponding properties of IClaimsIdentity and IClaimsPrincipal instances.

AD FS 2.0, which is part of Active Directory but (right now) ships as a separate install, will act as the STS, authenticating users against the Domain Controller and then constructing the SAML Token containing the claims that the application, the Relying Party, requires:
Claims Based Identity with WIF and ADFS 2
Claims Based Identity with WIF and AD FS 2.0 for an application running in the cloud

A nice effect of this separation of concerns is that the token can be easily extended to contain other claims than user name and Windows groups. The email address of the user could for example be fetched directly from Active Directory while constructing the token.
Another interesting scenario shown in the above diagram is when clients outside the domain need to access the application. By putting an AD FS proxy server in the DMZ the clients can still be authenticated against the Domain Controller and provided with a valid SAML token that can be sent to the application.

In the next parts we will look at how we can extend this solution so that business partners can achieve SSO with the help of Windows Azure AppFabric Access Control Service.

Category: sso, azure, english