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

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

Generic Claims Based Identity scenario

Claims Based Identity

“A claim is a statement about a subject made by an entity” as Vittorio Bertocci writes in his excellent book “Programming Windows Identity Foundation”. And he goes on to explain that the claim is always associated with the entity that issued it.
For example: a user is authenticated by an identity provider and a claim is being issued about the user’s identity.
By removing the need for developers to know exactly how that authentication technically was implemented, but still being able to prove it was made by a trusted entity – it provides a level of indirection and abstraction that helps address our challenges when moving applications to the cloud.

Claims Based Identity provides a standard way of flowing statements – Claims – about authenticated users from an Identity Provider via a Security Token Service to an application – a Relying Party. The Relying Party trusts the Issuer of the Token that contains the claims about the user. The Token can be in different formats but is usually an XML-based construct; SAML being one of the most widely used standards for Security Tokens in Claims Based Identity.
In addition to the claims about the user the Token also contains cryptographic proof from the Issuer of the claims. Using the Issuer’s public certificate thumbprint the Relying Party can make sure the corresponding private key was used by the Issuer to sign the Token.
A Single Sign On solution built on Claims Based Identity is interoperable by design and can without any problem traverse firewalls and proxy servers if the communication is being done through standard HTTP ports.

Generic Claims Based Identity scenario for an application running in the cloud

This time the ticket being issued is a Security Token in a standard format coming from a Security Token Service (STS) through web-compatible protocols (WS-Federation, SAML or WS-Trust depending on the type of client and service).
The arrows doesn’t show exactly how the protocols actually work and how the different requests for tokens are being made, but merely illustrates the flow of Security Tokens at a high level.

In the next blog post we will have a look at handling Claims Based Identity in a Microsoft environment with the help of Windows Identity Foundation and AD FS 2.0.

Category: sso, azure, english

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

Kerberos baserd SSO in the domain

I wrote some blog posts on SSO and federated security for the Windows Azure Architect site a while ago, but they seem to have gone missing – so I’m re-posting them as a series of posts here.

The SSO-challenge when moving your application to the cloud

Using Active Directory and integrated Windows Authentication works great as a Single Sign On solution for the intranet and as long as all your systems resides within the boundaries of the domain. The clients get authenticated against the domain controller and a Kerberos ticket is issued and used whenever the clients need to access a resource or service:

Single Sign On inside a domain

The application server trusts Kerberos tickets issued by the Active Directory in the domain and can grant or deny access to resources based on who the user is and what groups the user belongs to (this of course is a simplified description of how the Kerberos protocol actually works, but on a conceptual level holds true).

But what happens when you start moving some of your applications to a cloud environment like Windows Azure?

App moves to the cloud
The application is moved to the cloud

This scenario presents a couple of different challenges:

  • A Kerberos ticket can no longer be used without setting up some kind of VPN network connection since the client still resides in the domain but the application now runs in the security context of another network, across the Internet, possibly accessed through a proxy server and behind one or more firewalls.
  • Another challenge is the amount of information that you can provide in a Kerberos ticket. Such a ticket only provides the user name and what groups the user belongs to. Say for example you need to use the email adress to send automated email from the application to the user. In the intranet scenario you would query Active Directory or some other information store to get additional information. But how would you do that when the application no longer have access to the domain? It would be a lot more convenient if you could extend the ticket to contain arbitrary information. There is no way you can do that with a Kerberos ticket.
  • And what if the system your clients need to access is not a Windows based system at all – a system that doesn’t recognize Windows Authentication – for example a Java based application or some legacy system?
  • Another interesting scenario is if the client would need to access the service from outside of the domain, through public Internet.

In the next post we will look at how to solve these challenges using Claims Based Identity.

Category: sso, azure, english

Praktiska erfarenheter från systemutveckling i molnet – lunchseminarie 30/11

Vi har alla hört anledningarna till att lägga nästa projekt i en molnmiljö – obegränsad skalbarhet, kortare tid till marknad, billigare drift – men vilka är förändringarna rent praktiskt i ett utvecklingsprojekt?

Vilka fallgropar och risker bör du vara medveten om när du väljer molnet som miljö för din utveckling?

Hur skiljer sig de olika leverantörernas erbjudande av plattformstjänster från varandra?

Välkommen på ett lunchseminarie onsdagen den 30/11 hos Active Solution i Stockholm, där jag och Chris Klug går igenom dessa frågeställningar samt berättar om våra egna praktiska erfarenheter. Vi bjuder självklart på lunch efter seminariet 🙂

Jag kommer bl.a. dela mina erfarenheter av att ha arbetat med kunder som VolvoCars, Readsoft och Brevo under min tid på Microsoft. Chris kommer att berätta om sitt arbete med Ticket Direct som är den största online bokningstjänsten i Nya Zeeland och Australien.

Vi arbetar också för närvarande tillsammans i ett nyutvecklingsprojekt för en helt ny (än så länge hemlig) svensk tjänst. Ett spännande projekt som vi kommer kunna dela erfarenheter kring.

Anmäl dig till seminariet Systemutveckling i molnet här.

Category: azure, cloud