Security for Silverlight – Part 1 of many - Introduction - Bruno Terkaly - Developer Evangelist - bterkaly@microsoft.com - Site Home

Federated Scenarios - Windows Phone 7, WCF, and Azure

This is a big deal

Why wouldn't you want to control access?
The challenge with security is that it is cross-cutting – it spans multiple disciplines, even at Microsoft. This is serious and difficult stuff. I want to try to demystify it. Some of you want to see me continue developing the series "Leverage Cloud Computing with Windows Azure and Windows Phone 7 – Step 1 to Infinity." But first I want to get some security issues ironed out.

Confusing Territory

Security is a dark art
I'm throwing myself into this confusing area because as developers we all should know it. I always come up short when I think about it and now it is time to dive in.

Hide the complexity of using various identity providers

You have two main approaches you can take

Approach #1 - Using the Web Browser Control within Silverlight
You can add a WebBrowser control to the SL app on the phone, and us it negotiate the security token to access the Azure hosted service. This is a good approach if you want ACS to hide the complexity of using various identity providers ( like, LiveID, Facebook, Gmail, Yahoo, AD FS) from your app.

Approach #2 - Leveraging WS-Trust
The other approach is to use a web service based protocol for getting the user identity ( like WS-Trust ). This gives a bit more control to the app for managing the interaction with the identity provider and this will still work with ACS, but only when the identity provider also supports WS-Trust, which more common in enterprises scenario.

Windows Identity Foundation Developer Training

Download here

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c3e315fa-94e2-4028-99cb-904369f177c0

Much of the content I am illustrating is derived from the training kit. The Identity Developer Training Kit contains a set of hands-on labs, documents and references that will help you to learn how to take advantage of Microsoft's latest identity and access control developer's products and services. Much thanks to my peeps who have developed this resource.

My Goal

Explain as much detail, show as many visual cues as possible
Even as I read introductory material on these topics I find myself lacking a sound footing. As I implement the code I will take many side trips that explain context. Without context I am a blind man fumbling in the dark.

I may need to backtrack things that I’ve stated here. That is because as I learn I will make mistakes and assumptions that are false. It is likely that these posts will get edited from time to time as I get clarifications.

Big Picture

Take the scenario below
The point here is that although I want to access “http://brunoterkaly.com” I first need to get a token.

Tokens are provided by an STS. Once I have that token, I can then access “http://brunoterkaly.com” using the token. With that token I have certain “claims” I can make, which is to say I can access only specific parts of “http://brunoterkaly.com”

I will explain access to the “AuthenticationServices.svc” and “BrunoServices.svc” later.

What is STS?

Security Token Service
A Security Token Service, or STS, acts as a security gateway to authenticate callers and issue security tokens carrying relevant claims that describe the caller.

We typically don’t recommend building your own STS service. Rather, we recommend leveraging AD FS2 if possible.

More information can be found here:

http://msdn.microsoft.com/en-us/magazine/dd347547.aspx

I’d like to discuss some key points to this article in MSDN magazine. Michele Leroux Bustamante is brilliant and this article is a great resource.

It is about a security gateway

But there are other benefits too

	Decoupling apps and services from the authentication mechanism Supporting multiple credential types without complicating the implementation of applications and services.
	Supporting federated scenarios where users are authenticated by their domain and granted access to resources in another domain—by establishing trust between each domain's STS.
	Facilitating identity delegation scenarios where the authenticated user is granted access to downstream services.
	Facilitating claims transformation so that relevant claims are available for authorization at applications and services.

The STS is built upon the WS-Trust Specification

What is the meaning of these WS-* Security Specifications?

	WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.
	The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.
	Using the extensions defined in WS-Trust, applications can engage in secure communication designed to work within the Web services framework.

The tokens previously discussed are SAML Tokens

What is SAML?
Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains.

SAML, Identity Providers, Service Providers, Principals

What do all these terms have to do with each other?

	Think of it this way - there is the "identity provider" who validates the identity of the user (often called a principal).
	Then there is the "service provider" who receives the principal (user) from the "identity provider." The "service provider" decides what the principal can do by making an "access control" decision. The services provider relies on the identity provider that the principal is correct.
	Access control simply means that you can access certain resources.
	The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem, a problem also addressed by the more widely-used OpenID standard.
	Single sign-on solutions are abundant at the intranet level (using cookies, for example) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies.

Is this post helping?

Let me know
Email me here at bterkaly@microsoft.com

To be continued…