Security for Silverlight – Part 1 of many - Introduction

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 artI'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 SilverlightYou 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-TrustThe 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
hyperlink82

https://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 possibleEven 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.caveat[6]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 belowThe point here is that although I want to access “https://brunoterkaly.com” I first need to get a token.image Tokens are provided by an STS. Once I have that token, I can then access “https://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 “https://brunoterkaly.com”I will explain access to the “AuthenticationServices.svc” and “BrunoServices.svc” later.

snap0321

 

What is STS?

Security Token ServiceA Security Token Service, or STS, acts as a security gateway to authenticate callers and issue security tokens carrying relevant claims that describe the caller. caveat[8]We typically don’t recommend building your own STS service. Rather, we recommend leveraging AD FS2 if possible.More information can be found here:
hyperlink[10]

image

https://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

bullet

Decoupling apps and services from the authentication mechanism Supporting multiple credential types without complicating the implementation of applications and services.

bullet

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.

bullet

Facilitating identity delegation scenarios where the authenticated user is granted access to downstream services.

bullet

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?

bullet

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.

bullet

The WS-Trust specification was authored by representatives of a number of companies, and was approved by OASIS as a standard in March 2007.

bullet

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?

bullet

Think of it this way - there is the "identity provider" who validates the identity of the user (often called a principal).

bullet

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.

bullet

Access control simply means that you can access certain resources.

bullet

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.

bullet

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 knowEmail me here at bterkaly@microsoft.com

 

To be continued…