Eugenio Pace

p&p roadmap for the next few months

2011-11-01T18:33:00Z

Update: the same roadmap is now published on MSDN. I adjusted the slide below to make timelines clearer. No other changes.

We wanted to share with you all the projects we are either working on or we have identified as potential areas of investment in the current Fiscal Year (that started past July and ends next June 2012). The red dashed line is roughly the present. At this time, any project that has not been started (e.g. all the Windows 8 related projects and CQRS) is just a placeholder with just some rough ideas on their scope. We don’t know yet what that content will look like, how it will be packaged (a book? code? samples? all of the above?, etc.). But as usual, we’d very much welcome your input! All our projects end up on MSDN eventually, but have a corresponding community site on CodePlex where we post drafts and early versions.

Some extra information:

1. Developing Immersive Windows 8 Windows Applications

Focus: Provides guidance on building end-to-end immersive Win8 applications using the HTML5/ JavaScript,and XAML and C++/C# application stacks.
Candidate App Scenario: B2C/Connected-consumer. Windows 8 Metro-Style applications.
Candidate Sub-Scenarios: Application Design & Structure; UI – Controls, Form Factor Considerations, Interactivity, Touch & Gestures, Styling, Transitions, Animation, Media, Data Visualization, Rendering, Effects; Data Binding; UI Patterns (such as MVVM); Navigation; Sensor and local device access; Security – inside/outside the sandbox; Interacting with remote services; Accessing data; Local data storage and caching; Testing, debugging and performance tuning; Deployment, updates, and versioning; App Marketplace, leveraging legacy components.
Note: This project’s start and end will likely be impacted by Windows 8 ship dates.

2. Enterprise Library 6 Platform Re-alignment and Integration Pack for Windows8

Focus: EntLib provides guidance and re-usable code blocks for addressing cross-cutting-concerns such as caching, data access, cross-tier validation, etc. Over the years, many scenarios supported by EntLib are now better supported by the .NET platform. This project is focused on ensuring EntLib’s close alignment to the current platform (.NET 4.5) with a goal of reducing EntLib’s footprint by leveraging platform capabilities and improvements. EntLib will remain focused on filling gaps in order to support real-world end-to-end enterprise application development. In order to ensure this, the project will focus on desktop client applications as a core scenario and will deliver an Integration Pack for Windows 8. This will provide specific guidance on building enterprise LOB desktop applications for Windows 8. We may also update the EntLib Silverlight integration pack during this project to support Silverlight 5.0.
Candidate App Scenario: LOB/Enterprise Windows 8 desktop applications.
Candidate Sub-Scenarios: Configuration management; Logging, diagnostics and telemetry; Exception Handling; Data access and caching; Cross-tier data validation; Security & Cryptography;
Note: This project’s start and end will likely be impacted by Windows 8 ship dates.

3. Developing Modular MVVM Applications using WPF and Silverlight (Prism 4.1)

Focus: An update to our existing content that provides guidance on building end-to-end applications using the managed code WPF and Silverlight 5.0 application stacks. We will likely update Prism to 4.1 to cover the RTM release of Silverlight 5.0 and the beta release of WPF 4.5.
Candidate App Scenario: Modular LOB/Enterprise Windows desktop applications.
Candidate Sub-Scenarios: As outlined in the existing Prism documentation – UI design patterns (MVVM); UI composition; Modularity; Navigation; Dependency Injection, Loosely coupled inter-component communication; Deployment and updates, etc. An interesting component of this project will explore its relationship with Win8 and harvesting patterns demonstrated in Prism that apply to Win8 apps.
Note: This project’s start and end will likely be impacted by Windows 8 ship dates.

4. Developing Windows Phone 7 Applications using Silverlight – 2^nd Edition Update – Phase I & Phase II

Focus: Phase I is an update to our existing guidance on the development of Silverlight-based Windows Phone 7 applications. This update is to showcase the new capabilities in the WP7 Mango release and to address feedback on the first edition. The Prism MVVM library for the Phone will also be update for any platform updates. Phase II is focused on making WP7 more testable. We intend to produce some artifacts to help write simpler unit tests (e.g. adapters & mocks)
Project community site: http://wp7guide.codeplex.com
Candidate App Scenario: Cloud-connected consumer oriented mobile phone applications.
Candidate Sub-Scenarios: Application Design & Structure; UI Design – Form Factor Considerations, Interactivity, Touch & Gestures, Styling, Transitions, Animation, Media; Tomb-stoning and Navigation; Push notifications; Implementing MVVM; Sensor and local device access; Security; Interacting with cloud-based services; Accessing data; Local data storage, caching and synchronization; Testing; Debugging and performance tuning; Deployment, Updates, Versioning; Marketplace.

5. Test Guidance for Continuous Integration with VSTS

Focus: Provide guidance to Test Engineers on common testing scenarios using Visual Studio Team System and Team Foundation Server.
Candidate scenarios: Setting up continuous test integration infrastructure. Building test harnesses.

6. Developing Mobile Web Applications

Focus: Provides guidance on the development of interactive web applications that specifically target HTML5 capable mobile phone devices such as WP7 Mango with IE9.
Candidate App Scenario: Cloud-connected consumer oriented mobile phone web applications.
Candidate Sub-Scenarios: Application Design & Structure, using ASP.NET MVC/Razor; Client-side JavaScript and jQuery development; Leveraging HTML5/CSS3/SVG capabilities; Browser and device capability detection; Integration and re-use within ‘full’ web applications; UI Design – Form Factor Considerations, Interactivity, Touch & Gestures, Styling, Transitions, Animation, Media; Navigation; Sensor and local device access; Security; Interacting with remote services; Accessing data; Local data storage and caching; Debugging and performance tuning; Versioning.

7. Enterprise Library Integration Pack for Windows Azure

Focus: Provides guidance on auto-scaling and building resilient applications on Windows Azure.
Project community site: http://entlib.codeplex.com
Public backlog: http://entlib.uservoice.com
Candidate App Scenario: LOB/Enterprise/Consumer facing cloud applications.
Candidate Sub-Scenarios: Scaling Windows Azure roles based on predefined criteria (e.g. schedule, resource metrics and other KPIs). Increase tolerance to connection failures to different resources (e.g. databases, storage, external dependencies, etc.). Add automatic retries in case of failures.

8. CQRS Guide

Focus: Provides guidance on building application using the Command Query Response Segregation pattern. Many customers have expressed interest in this approach to building apps.
Candidate App Scenario: LOB/Enterprise/Consumer facing cloud applications.
Candidate Sub-Scenarios: Applications with high scalability and/or high performance requirements.

9. Migrating/Developing Applications to/for the Cloud – 2nd Edition Update

Focus: An update to our existing guidance on the migration and development of applications for Windows Azure – updated is to showcase the new capabilities of the Windows Azure platform and to address feedback on the first edition. This project has been already completed and content is in production now for MSDN release.
Project community site: http://wag.codeplex.com (will be on MSDN very soon)
Candidate App Scenario: Continued focus on LOB/Enterprise/Consumer focused cloud applications.
Candidate Sub-Scenarios: Using Web and Worker Roles; Using Queues & SQL Azure, Table, Drive/Page Blob Storage; Claims-based authentication and authorization; Migration of existing application assets to the cloud; Designing a new application for the cloud; Using upgrade and fault domains; Single and Multi-Tenant application design; Deployment, Update and Versioning; Testing, Debugging and Performance Tuning; Tools for cloud development.

10. Hybrid Cloud Application Guidance

Focus: Provides guidance on developing hybrid (applications that have on-premises and cloud components). This project demonstrates use of platform features such as Windows Azure Connect, Windows Azure VM Roles and Windows Azure Service Bus.
Project community site: http://wag.codeplex.com
Candidate App Scenario: Integration of on-premises and cloud based Enterprise/LOB applications.
Candidate Sub-Scenarios: Implementation patterns for data, workflow and identity integration; taking advantage of cloud specific capabilities such as geo-location, dynamic scalability, etc.

Claims Identity Guide–Hands On Labs

2011-06-13T16:53:36Z

Training content based on our guides has been as popular as the content itself. You can now download the “Release Candidate” for labs corresponding to the new guide.

The labs are more than just a mirror of the guide. We took the opportunity of adding a few things that complement and extend what is explained in the book. A notable addition is using ADFS v2.

The guide talks a lot about “using ADFS for a production environment”, but all samples shipped use a “simulated STS” (this is of course than for convenience and to minimize the dependencies on your dev environment). Well, now you will have a chance of using experimenting and learning about ADFS v2.

But there’s more of course.

Here’s the compete “Table of Contents”. Feedback always very welcome.

Lab 1

Exercise 1: Making Applications Claims-aware. In this exercise you will modify two Adatum web applications (a-Order and a-Expense) that currently use forms-based authentication to make them claims-aware, and to provide the user with a single sign-on (SSO) experience.

Exercise 2: Enabling Single Sign-Out. In this exercise you will add code to the applications so that users logging out of one are automatically logged out of the other.

Exercise 3: Using WIF Session Mode. In this exercise you will modify the applications to change the behavior of the WIF modules so that token information is stored in the session instead of the authentication cookie.

Lab 2

Exercise 1: Federating Adatum and Litware. In this exercise, you will modify the Adatum a-Order web application to trust the Adatum federation provider, and configure the Adatum federation provider to trust both the Adatum and Litware identity providers.

Exercise 2: Home Realm Discovery. In this exercise, you will modify the a-Order web application to send a whr parameter to the federation provider. You will then modify the Adatum federation provider to use the value of the whr parameter to determine the identity provider the user should authenticate with.

Exercise 3: Federation with ADFS. In this optional exercise, you will replace the custom Adatum federation provider with ADFS.

Lab 3

Exercise 1: Adding ACS as a Trusted Issuer. In this exercise you will start with a version of the a-Order application similar to that you used in previous labs, and modify it to use Windows Azure AppFabric Access Control Service (ACS) as the trusted issuer and identity provider in addition to the Adatum federation provider and simulated issuer.

Exercise 2: Adding the Facebook Identity Provider and Home Realm Discovery. In this exercise you will add Facebook as an identity provider to your ACS namespace. This illustrates how, by taking advantage of ACS, you can easily change the options a user has for authentication when using your applications; without requiring any modification of the application or of your own local token issuer or federation provider.

Exercise 3: Adding a Custom OpenID Identity Provider. In this exercise you will use the ACS Management API to programmatically add a relying party application that uses the OpenID identity provider.

Exercise 4: Replacing the Adatum Federation Provider with ADFS. In this optional additional exercise you will replace the existing Adatum federation provider with an ADFS instance, and configure this to use ACS as a token issuer and identity provider.

Lab 4

Exercise 1: Using Claims with SOAP Web Services. In this exercise, you will modify the SOAP-based Adatum a-Order web service to use claims. You will also modify the desktop client application to work with the new version of the service.

Exercise 2: Using Claims with REST Web Services. In this exercise, you will modify the REST-based Adatum a-Order web service to use claims. You will also modify the desktop client application to work with the new version of the service.

Exercise 3: Federation with ADFS. In this optional exercise, you will replace the custom Adatum federation provider with ADFS.

Intuit Data Services + Windows Azure + Identity

2011-04-08T05:15:22Z

This week, we completed a small PoC for brabant court, a customer that is building a Windows Azure application that integrates with Intuit’s Data Services (IDS).

A couple words on mabbled from brabant court.

Mabbled is a Windows Azure app (ASP.NET MVC 3, EF Code First, SQL Azure, AppFabric ACS|Caching, jQuery) that provides complementary services to users of Intuit QuickBooks desktop and QuickBooks Online application. Mabbled achieves this integration with the Windows Azure SDK for Intuit Partner Platform (IPP). An overriding design goal of mabbled is to leverage as much of Microsoft’s platform and services as possible in order to avoid infrastructure development and focus energy on developing compelling business logic. A stumbling block for mabbled’s developers has been identity management and interop between Intuit and the Windows Azure application.

In this PoC we demonstrate how to integrate WIF with an Intuit/Windows Azure ASP.NET app. Intuit uses SAML 2.0 tokens and SAMLP. SAML 2.0 tokens are supported out of the box in WIF, but not the protocol.

I used one of Intuit’s sample apps (OrderManagement) as the base which currently doesn’t use WIF at all.

The goal: to supply to the .NET Windows Azure app, identity information originated in Intuit’s Workplace, using the WIF programming model (e.g. ClaimsPrincipal) and to use and leverage as much standard infrastructure as possible (e.g. ASP.NET authorization, IPrincipal.IsInRole, etc.).

Why? The biggest advantage of this approach is the elimination of any dependency to custom code to deal with identity related concerns (e.g. querying for roles, user information, etc.).

How it works today?

If you’ve seen Intuit’s sample app, you know that they provide a handler for the app that parses a SAML 2.0 token posted back from their portal (http://workplace.intuit.com). This SAML token contains 3 claims: LoginTicket, TargetUrl and RealmId. Of these, LoginTicket is also encrypted.

The sample app includes a couple of helper classes that use the Intuit API to retrieve user information such as roles, profile info such as e-mail, last login date, etc. This API uses the LoginTicket as the handle to get this information (sort of an API key).

Some of this information is then persisted in cookies, or in session, etc. The problem with this approach is identity data is not based on .NET standard interfaces. So the app is :

where RoleHelper.UserisInRole is:

WIF provides a nice integration into standard .NET interfaces, so code like this in a web page, just works: this.User.IsInRole(role);

The app currently includes a ASP.NET Http handler (called "SamlHandler”) whose responsibility is to receive the SAML 2.0 token, parse it, validate it and decrypt the claim. Sounds familiar? if it does, it’s because WIF does the same

What changed?

I had trouble parsing the token with WIF’s FederationAuthenticationModule (probably because of the encrypted claim which I think it is not supported, but I need to double check).

Inside the original app handler, I’m taking the parsed SAML token (using the existing Intuit’s code) and extracting the claims supplied in it.

Then, I query Intuit Workplace for the user’s general data (e.g. e-mail, name, last name, etc.) and for the roles he is a member of (this requires 2 API calls using the LoginTicket). All this information also goes into the Claims collection in the ClaimsPrincipal.

After that I create a ClaimsPrincipal and I add all this information to the claim set:

The last step is to create a session for this user, and for that I’m (re)using WIF’s SessionAuthenticationModule.

This uses whatever mechanism you configured in WIF. Because this was a quick test, I left all defaults. But since this is a Windows Azure app, I suggest you should follow the specific recommendations for this.

The handler’s original structure is the same (and I think it would need some refactoring, especially with regards to error handling, but that was out of scope for this PoC )

Some highlights of this code:

Some API calls require a dbid parameter that is passed as a query string from Intuit to the app in a later call. I’m parsing the dbid from the TargetUrl claim to avoid a 2 pass claims generation process and solve everything here. This is not ideal, but not too bad. It would be simpler to get the dbid in the SAML token.
The sample app uses local mapping mechanism to translate “Workplace roles” into “Application Roles” (it uses a small XML document stored in config to do the mapping). I moved all this here so the ClaimsPrincipal contains everything the application needs right away. I didn’t attempt to optimize any of this code and I just moved the code pieces from the original location to here. This is the “RoleMappingHelper”.
I removed everything from the session. The “LoginTicket” for instance, was one of the pieces of information stored in session, but I found strange that it is sent as an encrypted claim in the SAML token, but then it is stored in a cookie. I removed all this.
The WIF SessionAuthenticationModule (SAM) is then used to serialize/encrypt/chunk ClaimsPrincipal. This is all standard WIF behavior as described before.

The web application:

In the web app, I first changed the config to add WIF module and config:

Notice that the usual FederationAutheticationModule is not there. That’s because its responsibilities are now replaced by the handler. The SAM however is there and therefore it will automatically reconstruct the ClaimsPrincipal if it finds the FedAuth cookies created inside the handler. The result is that the application now will receive the complete ClaimsPrincipal on each request.

This is the “CustomerList.aspx” page (post authentication):

The second big change was to refactor all RoleHelper methods to use the standard interfaces:

An interesting case is the IsGuest property that originally checked that the user was a member of any role (the roles a user was a member of were stored in session too, which I’m not a big fan of). This is now resolved with this single query to the Claims collection:

The structure of the app was left more or less intact, but I did delete a lot of code that was not needed anymore.

Again, a big advantage of this approach is that it allows you to plug any existing standard infrastructure into the app (like [Authorize] attribute in an MVC application) and it “just works”.

In this example, the “CustomerList.aspx” page for example has this code at the beginning of PageLoad event:

As mentioned above, the RoleHelper methods are now using the ClaimsPrincipal to resolve the “IsInRole” question (through HttpContext.User.IsInRole). But you could achieve something similar with pure ASP.NET infrastructure. Just as a quick test, I added this to the web.config:

And now when trying to browse “CustomerList.aspx” you get an “Access Denied” because the user is not supplying a claim of type role with value “SuperAdministrator”:

Final notes

A more elegant approach would probably be to use deeper WIF extensibility to implement the appropriate “protocol”, etc., but that seems to be justified only if you are really implementing a “complete” protocol/handler (SAMLP in this case). That’s much harder work.

This is a more pragmatic approach that works for this case. I think it fulfills the goal of isolating as much “plumbing” as possible from the application code. When WIF evolves to support SAMLP natively for example, you would simply replace infrastructure, leaving your app mostly unchanged.

Finally, one last observation: we are calling the Intuit API a couple times to retrieve user info. This could be completely avoided if the original SAML token sent by Intuit contained the information right away! There might be good reasons why they are not doing it today. Maybe it’s in their roadmap. Once again, with this design, changes in your app would be minimized if that happens.

This was my first experience with Intuit’s platform and I was surprised how easy it was to get going and for their excellent support.

I want to thank Daz Wilkin (brabant court Founder) for spending a whole day with us. Jarred Keneally from Intuit for all his assistance and Federico Boerr & Scott Densmore from my team for helping me polish the implementation.

Authentication in WP7 client with REST Services–Part II

2011-04-02T21:15:25Z

In the previous post I covered the “semi-passive” way for authentication between a Windows Phone 7 client and a REST service. This post completes the information with the “active” way.

There’s nothing unexpected here really:

We call the Identity Provider using a RequestSecurityToken message (RST)
We send the SAML token to ACS and get a “Simple Web Token” (SWT)
We call the service with the SWT as in the previous example using the Web browser

The only tricky thing is that there’s no library in the phone runtime for sending the RST message to the STS. In a desktop application you’d simply use WIF or plain WCF (with the right binding). But neither is available on WP7. So step 1 and 2 require some custom code.

For step 1 we are creating the RST manually:

All those interactions are fairly easy to compose with the Rx framework, so the call gets really compact and easy to read:

The AddAuthorizationHeader extension method now:

All this is “plumbing code” that is written once and used many hopefully.

One potential disadvantage of this approach compared to the previous one, is less flexibility in dealing with many identity providers. Remember that ACS can have many IdPs it could use and have the user potentially pick one from a list (a.k.a. Home Realm Discovery). None of that is built in this example (but you could of course). In a browser all of that is handled server side and just works.

The other disadvantage is that this only works with WS-Trust STSs. If we wanted to say, authenticate with other providers you will have to implement the protocol and then update the client code. When using the browser all of that is handled server side. You can add/remove/take advantage of any upgrades to ACS with no changes to be made on the phone app.

On the other hand, if you don’t need all that flexibility, it is a lighter weight and more direct solution: less round-trips, simpler code, etc. That could be case for a more enterprise oriented app, where the STS could be your corporate ADFS for example. That is unlikely to change frequently.

We are still adjusting some details on the full sample, but it is very likely it will be included in the next drop on CodePlex site.

Authentication in WP7 client with REST Services–Part I

2011-03-25T03:58:03Z

In the last drop, we included a sample that demonstrates how to secure a REST web service with ACS, and a client calling that service running in a different security realm:

In this case, ACS is the bridge between the WS-Trust/SAML world (Litware in the diagram) and the REST/SWT side (Adatum’s a-Order app)

This is just a technical variation of the original sample we had in the book, that was purely based on SOAP web services (WS-Trust/SAML only):

But we have another example in preparation which is a Windows Phone 7 Client. Interacting with REST based APIs is pretty popular with mobile devices. In fact is what we decided to use when building the sample for our Windows Phone 7 Developer Guide.

There’s no WIF for the phone yet, so implementing this in the WP7 takes a little bit of extra work. And, as usual, there’re many ways to solve it.

The “semi-active” way:

This is a very popular approach. In fact, it’s the way you’re likely to see this done with the phone in many samples. It essentially involves using an embedded browser (browser = IE) and delegate to it all token negotiation until it gets the token you want. This negotiation is nothing else than the classic “passive” token negotiation, based on HTTP redirects that we have discussed ad infinitum, ad nauseam.

The trick is in the “until you get the token you want”. Because the browser is embedded in the host application (a Silverlight app in the phone), you can handle and react to all kind of events raised by it. A particular useful event to handle is Navigating. This signals that the browser is trying to initiate an HTTP request to a server. We know that the last interaction in the token negotiation (passive) is actually posting the token back the the relying party. That’s the token we want!

So if we have a way of identifying the last POST attempt by the browser, then we have the token we need. There are many ways of doing this, but most look like this:

In this case we are using the “ReplyTo” address, that has been configured in ACS with a specific value “break_here” and then extract the token with the browser control SaveToString method. The Regex functions you see there, simply extract the token from the entire web page.

Once you’ve got the token, then you use it in the web service call and voila!

With this approach your phone code is completely agnostic of how you actually get the final token. This works with any identity provider, and any protocol supported by the browser.

Here’re some screenshots of our sample:

The first one is the home screen (SL). The second one shows the embedded browser with a login screen (adjusted for the size of the phone screen) and the last one the result of calling the service.

JavaScript in the browser control in the phone has to be explicitly enabled:

If you don’t do this, the automatic redirections will not happen and you will see this:

You will have to click on the (small) button for the process to continue. This is exactly the same behavior that happens with a browser on a desktop (only that in most cases scripting is enabled).

In next post I’ll go into more detail of the other option: the “active” client. By the way, this sample will be posted to our CodePlex site soon.

Drop #2 of Claims Identity Guide on CodePlex

2011-03-22T20:59:45Z

Second drop of samples and draft chapters is now available on CodePlex. Highlights:

All 3 samples for ACS v2: ("ACS as a Federation Provider", "ACS as a FP with Multiple Business Partners" and "ACS and REST endpoints"). These samples extend all the original "Federation samples" in the guide with new capabilities (e.g. protocol transition, REST services, etc.)
Two new ACS specific chapters and a new appendix on message sequences

Most samples will work without an ACS account, since we pre-provisioned one for you. The exception is the “ACS and Multiple Partners”, because this requires credentials to modify ACS configuration. You will need to subscribe to your own instance of ACS to fully exercise the code (especially the “sign-up” process).

The 2 additions to the appendix are:

Message exchanges between Client/RP/ACS/Issuer:

And the Single-Sign-Out process (step 10 below):

You will also find the Fiddler sessions with explained message contents.

Feedback always welcome!

SaaSGrid and Identity

2011-03-21T21:57:04Z

Apprenda’s SaaSGrid is now “claims enabled”! This is fantastic news. Any SG customer can now enjoy the benefits of claims based identity: simpler user management, easy federation with business partners, support for multiple identity providers, greater interoperability, etc.

SG support for claims based identity maps nicely with what’s described in the “Claims Identity Guide – Federation with Multiple Partners” chapter. And now with the new chapter published on CodePlex: “Federation with Multiple Partners and Windows Azure AppFabric Access Control Service”.

Join Matt Ammerman and me on March 30th for an identity-full webinar. The agenda for the session is:

Introduction to Claims based identity: principles and architecture.
Key problems solved by claims based identity, including an update on current standards, frameworks and tools on the Microsoft platform.
Drop-in Federated Identity and Claims Enablement for .NET applications via SaaSGrid (Live Demo)

Web Single Sign Out–Part II

2011-02-24T21:01:17Z

Following up on previous post, there were 2 questions:

Where do these green checks images come from? There are nowhere in a-Order or in a-Expense… you would spend hours looking for the PNG, or JPG or GIF and you will never find it, because it is very well concealed. Can you guess where it comes from?

I was referring to the green checks displayed here:

The src for these is a rather cryptic src=http://localhost/a-Order/?wa=signoutcleanup1.0

And the answer is: it’s coming from within WIF (the FAM more specifically). If you explore the FAM with Reflector you will see a byte array embedded in the code. That byte array is the GIF for the green check. Exercise to the reader: is this the only behaviour? Can the FAM do something else? under which circumstances?

The second question was:

Bonus question: how does the IdP know all the applications the user accessed to?

No WIF magic here. The issuer will have to keep a list of all the RP. In our sample (that we expect to release really soon) we use exactly the technique described in Vittorio’s book. We have a small helper class “SingleSignonManager” that keeps track of RPs in cookies:

Then, when the signout request is received, we simply iterate over the list and return the right markup:

The SingleSignoutManager class is mentioned in Vittorio’s book but not available there, so we included it in the sample.

Single Sign Out–WebSSO

2011-02-16T18:46:02Z

While reviewing all the existing samples we’ve noticed that our implementation of Single Sign Out was kind of….weak. It wasn’t really fully implemented and wasn’t very clear what was happening either (or what it should happen)

We’ve fixed all that now in scenario 1: WebSSO. Things get more complicated when more than 1 STS is in the picture, and even more so when the identity provider uses other protocols (for example, all our scenarios using ACS and Google or ACS and LiveID). But for WebSSO, things are more or less straight forward.

WebSSO scenario recap:

If you remember for previous posts or the book, in our first chapter we had Adatum with 2 applications: a-Order and a-Expense. We wanted that Adatum employees login to one or the other seamlessly:

John opens the browser on his desktop (that already has a been authenticated with AD)
Opens a-Order home page
Gets redirected to the IdP. He’s authenticated (e.g. Kerberos ticket)
A token is given to him. The token is posted back to a-Order. He’s in.

Sometime later, he browses a-Expense.

No session with a-Expense yet, he’s redirected to IdP
He’s already authenticated, gets a new token for a-Expense.
Voila

So far, so good. Nothing really new. What happens now if John wants to signoff. We don’t want our system to be a roach motel: once in, never out… what happens is actually pretty straight forward, but there are some subtle considerations. When John signs-off, he should sign off from all relying parties and the IdP.

This diagram illustrates the process:

John clicks on “Logout” (on any of the relying parties: a-Order in our example). This results on a wa=signout1.0 to be sent to the IdP. The Idp cleans up its own session with the user and then (here comes the tricky part)returns a page to the user with a list of image tags (HTML image tags). An image tag for each RP the IdP has issued a security token for John. The src url for these images will be actually something like:

src=http://localhost/a-Expense/?wa=signoutcleanup1.0

src=http://localhost/a-Order/?wa=signoutcleanup1.0

With these tags, the browser will attempt to get the image from these URL (which happens to be located in each RP: a-Order and a_expense), and in fact you will see something like this:

The HTML:

Where do these green checks images come from? There are nowhere in a-Order or in a-Expense… you would spend hours looking for the PNG, or JPG or GIF and you will never find it, because it is very well concealed. Can you guess where it comes from?

Hint: page 115 of Vittorio’s excellent book.

Bonus question: how does the IdP know all the applications the user accessed to?

By the way, all this is now working on the new updated samples which we will post to our CodePlex site very soon.

ACS as a Federation Provider – Claims transformation

2011-02-14T23:31:56Z

To work properly, a-Order needs a number of claims to be supplied:

User name
Organization
Role

The "Organization” claim is used to filter orders belonging to a specific customer of Adatum. For example, Litware users (like Rick) will eventually end up with a token containing a claim with “Organization=Litware”. All this is done in step 3 here in the diagram below:

Adatum’s FP takes whatever token it gets from the outside world and “normalizes” it to whatever the application needs. ADFS for example, ships with a powerful language to define these transformations. In our sample, we ship a simple “simulation” of a real STS, so our rules are all coded in C# and are obviously not “production”:

With ACS in the picture there are 2 places where transformation could happen though:

In ACS
In Adatum’s FP

In this scenario Adatum owns both (its own on-premises issuers and an instance in ACS), so it has full control of either components. Which one to use depends on many factors and there’s no “single right” way of doing it. Let’s consider one reason to keep mappings on Adatum’s side. for this we’ll pick one of the transformations required: the simple rule of associating “Mary@Gmail.com” with Organization=“Mary Inc”.

This rule would be fixed in ACS, there is no dynamic discovery or lookup code that ACS can execute at this time. It is likely that Adatum keeps a master record of all the companies it works with and the contact information associated with them. If that is the case, it’s probably better to have ADFS call a component or the master record database using the built-in SQL integration capabilities (if using ADFS). If Mary changes her e-mail, everything would just work. If the rule was in ACS, it would require Adatum to update the rule every time there’s an update.

Of course, ACS does provide an API for updating the configuration. So you could achieve something similar by just automating the update. Different companies will be more or less comfortable with one approach or the other.

The highest order bit in this situation is that the app remains completely isolated from these changes, as CodingOutLoud mentioned in his comment in a previous post.

ACS as a Federation Provider–Home Realm Discovery Part 2

2011-02-11T00:12:48Z

In my previous post, I had a question for all you:

What would happen if Adatum’s FP didn’t supply ACS with the whr parameter?

An the answer is: ….. ACS will simply ask the user!

ACS has no way (besides the whr parameter) of knowing where to go next (unless you configured your app with only 1 Identity provider I guess).

You might say that this page is ugly, and my look & feel is lost and you would be absolutely right. However, the good news is that this is just the default page. You can actually query ACS for all configured Identity Providers and build a page that will send the right whr.

Now, any ideas on question #2? (reminder: who is responsible for issuing the claims a-Order needs: role, organization, etc?)

ACS as a Federation Provider - A little bit deeper into the sample (Home Realm Discovery)

2011-02-09T20:40:34Z

Updates: fixed typos. Clarified how Home Realm Discovery works in this example.

In the previous post, I introduced the basic scenario of using ACS as a federation provider for Adatum (in addition to the one they already have). In this post, I’ll show you more details on how this works, based on the sample we are building that will ship with the guide.

Step 1 - Rick from Litware browses a-Order hosted by Adatum

The first time Rick browses a-Order he is “unauthenticated” therefore a-Order simply redirects Rick to the issuer it trusts for getting security tokens. That is Adatum’s own issuer. The issuer doesn’t know where Rick is coming from (it could use some heuristics, but in this simple example, it doesn’t), so it just asks the user “where are you coming from so I can redirect you to the a place I trust to get you authenticated?”.

This is the "Home Realm Screen” and it is meant to capture precisely the user (Rick’s) home realm (the place where he can get authenticated). Notice that we now have 3 options:

Adatum. This will redirect the user to Adatum’s Identity Provider. This is of course useless to Rick because he doesn’t
A list of organizations Adatum does business with (Litware)
An e-mail address fro which the a-Order can infer the security domain.

Step 2 – Rick selects “Litware” from the listbox

By doing this, Rick will continue his journey to get a token for a-Order. He’s redirected to Litware’s IP. Adatum’s FP knows about this because internally it will keep a list of the other issuers it trusts. “Litware” in the listbox maps to the actual URL of Litware issuer. This is the screen on the left below. After successful authentication, Rick is directed back to the FP with a freshly minted Litware token. The FP inspects the token, does some transformations (adds/removes claims) and issues a new (Adatum) token which is finally sent to a-Order.

a-Order opens the token (thanks to WIF) and runs its logic (display pending orders). That’s the screen on the right:

a-Order magnificent UI renders the name of the user and the name of the “original issuer” of the token on the top right corner of the screen.

ACS enters the scene

Now, what happens if the user fills in the last option of the Home Realm page? (the e-mail). In this case, our sample does exactly the same thing only with some extra logic.

Step 1- Mary browses a-Order and then completes the textbox with her Gmail mail address

In our current implementation Adatum’s FP Home Realm page will assume that if you complete the e-mail textbox, you want to authenticate with Google or LiveID and will simply redirect you to ACS. ACS is the other “Federation Provider” in the chain in between Adatum’s issuer and Google or LiveID. It actually does something else: it specifies the whr parameter. This is simply based on the e-mail domain. So, if I type “something@gmail.com” it assumes the issuer I’m interested in using for authentication is Google’s:

Step 2 – Mary authenticates in Google

Because ACS is getting this hint from the Adatum’s FP, it forwards the request with no further stops to Google (the screen above).

Question for the reader #1: what would happen if Adatum’s FP didn’t specify the whr parameter when it redirected Rick to ACS?

Notice how Google is informing us of the requestor of the token (our account in ACS), and provides the usual login screen. After successful login, it actually requests the user for an additional approval to disclose some information about him/her. (the e-mail in this case)

Step 3 – Going back to a-Order

What happens next is exactly what I described before. Unfortunately we don’t see all the magic that happens inside ACS. But essentially, it took care of bridging all the relationship with Google, it translated the token received from Google (not SAML) and then issued a (SAML) token that Adatum’s FP and a-Order could understand:

There are absolutely no changes in a-Order code to handle this. There’re no dependencies on Google’s API or anything special. All thanks to ACS and claims based identity. All we did was add ACS as a trusted issuer of Adatum’s FP, added a Home realm page to Adatum’s FP and then configured the token transformation rules.

In fact, from a programming perspective you simply get a ClaimsPrincipal with the usual properties, regardless of where the token is coming from:

It just works!

Question for the reader #2: Google didn’t provide the “Role” claim you see above. And most certainly didn’t provide the “Organization” claim either. Who did then? Where are they coming from?

Access Control Service as a Federation Provider

2011-02-08T20:11:49Z

The first scenario we are working is using ACS as a federation provider. This is an extension of the current chapter on Federation.

The basic scenario is the following:

Adatum has an Order processing app (a-Order) that is already claims enabled.
Adatum wants their partners to be able to access a-Order with their own identity infrastructure

In pictures:

Adatum Issuer (ADFS in the example) now trusts Litware issuer with whatever method Litware has implemented. If Litware uses AD, then a good candidate for their Identity Provider is ADFS of course.
Rick authenticates with their IP and gets a token for Adatum
Rick (or his browser really) sends the token to Adatum’s issuer where it gets transformed into an “Adatum Token”. This is an opportunity for Adatum to translate Litware concepts into Adautm ones: for example Rick might be in a “Sales” group in Litware, but a-Order has no notion of “Sales”. It might understand a role “Order Tracker” instead. The Adatum issuer will translate “Sales” into “Order Tracker”
If everything goes well, Rick (his browser) gets an Adatum token and finally sends it to the a-Order

Note: This flow is really the “unwinding” of the process that starts when Rick browses a-Order. Everything really starts there (look for WS-Federation “passive profile” for more info), but conceptually that’s what’s happening.

Let’s imagine now that Adatum does business with other partners (smaller companies than Litware maybe) that do not have any identity infrastructure of their own. Let’s imagine “Mary Inc” is a a very small busniess owned by Mary, and she essentially works from home. Mary is probably not going to have AD under her desk.

What are the options for Adatum if they wanted to open a-Order to customers like Mary?

Option 1 – Adatum creates an Identity Provider for customers with no Identity Provider of their own

This is essentially deploying an Identity Provider (with its corresponding user database) for partners. Mary would get an account with Adatum and she would sign on with the Adatum provider credentials.

They can implement it in various ways: use ADFS V2 with a separate AD, use ADFS v1.1 with ADAM, use a custom STS with ASP.NET Membership (e.g. the StarterSTS or similar), write their own (a fun project indeed).

However, there are quite some disadvantages in this approach:

It requires Adatum to develop/deploy additional infrastructure and maintain and support it. (Hints: what happens if Mary forgets her Adatum password? who is she calling? who pays for that support?)
Mary’s account is unlikely to reside in Adatum’s corporate AD (it will probably be a separate domain). Consequence: more servers, more licenses, more money, more power consumption, more greenhouse gases, less ice in the arctic, less polar bears…you get the picture.
Mary has acquired an additional username/password that will end up on sticky notes on her desktop monitor. Less security, worse user experience, less satisfaction with Adatum, more blame, less business, more complaints, increased need for selective serotonin reuptake inhibitors….not good.

Option 2 – Ask Mary to deploy ADFS

This would be just great, wouldn’t it? Riiiiight…. I’m just kidding, please don’t attempt this.

Option 3 – Leverage any of Marys’ existing identities

Mary is on Facebook (sometimes too much). Mary has a Hotmail account. Mary uses Google Docs. Wouldn’t it be great to simply use one of these? Yes, it would be great. How do we make that happen?

The answer is simple: make Adatum’s Federation Provider trust all those identity providers, just as they did with Litware:

Conceptually this is all fine, but it would be too easy,

The only issue is that often, all these providers implement different protocols and token formats: OpenID and OAuth and SWT, etc. So Adatum’s FP would have to understand all these protocols and formats and translate them into the ones a-Order understands (SAML & WS-Federation). If Adatum deployed ADFS as their FP this means that it can deal with WS-Federation, WS-Trust and SAMLP protocols and SAML tokens. Anything else requires extensions, development or additional infrastructure.

The good news is that all this supported out of the box by ACS! And the solution would look more or less like this:

Advantages:

Adatum reuses all the internal infrastructure that they’ve invested in already. The setup of all this would probably take hours (or minutes even) as opposed to weeks or months. Adatum can rely on an highly scalable, secure, proven, global service as opposed to rolling out their own.

Using a cloud service means less control though. Adatum will have to trust (beyond the identity meaning) Microsoft to run this for them. They will also have to rely on any of the 3rd party identity providers to authenticate the users. If Facebook is down for whatever reason, then Mary will not be able to access a-Order. But I guess that if Facebook is down, the world has bigger problems, right?

Our next project – Claims based Identity and Access Control

2011-02-05T06:40:46Z

Not surprisingly maybe, security in general, and authentication & authorization in particular, is a consistently highly rated concern for our customers. These concerns are especially elevated with those considering the cloud, because they don’t have as much control on the cloud as they would typically have in their own datacenters. Sometimes, one could argue, for their own benefit, but that is a different discussion.

The “Claims Identity Guide” published in December 2009, was a foundational component in our “Cloud series” that followed it: Moving Applications to the Cloud, Developing Application for the Cloud and the recently released Windows Phone 7 Developer Guide. The identity content in all of them, is essentially based on the core scenarios and design principles described in the claims guide.

With the Claims guide we also pioneered a new style and design in our books, and it was very well received! We’ve got some great feedback from you on the content and the approach. Exciting things are happening in the identity space and we want to continue to help you create great solutions using these new components.

Our next project then is an extension to this guide that will address two new areas:

1- Access Control Service (ACS) V2, in the Windows Azure Platform will be available in production soon. ACS opens the doors to advanced identity management scenarios including federation, interop with popular identity standards such as OpenId, OAuth, SWT and SAML, use of popular social identity providers such as Facebook, Windows Live ID and Google. All of this is available today in labs.

2- SharePoint 2010 is “claims enabled”, meaning that it natively supports advanced identity management based on WS-Federation.

Interestingly (or not maybe), the core scenarios remain the same but the implementation details change and new interesting things can now be done much more easily. More or less our scope now looks like this:

The “blue” line is the existing content, “green” and “black” are the new chapters. Notice that they almost mirror what’s covered today. News and updates (including drafts, early samples, etc) will be published on http://claimsid.codeplex.com

As usual, we welcome feedback very much!

MVC–Unity–challenge answer

2011-01-28T07:10:59Z

The answer (or better yet, my answer):

The proof:

This is leveraging the use of a name when registering a type and using the convention of using the same name for all types in the same context (“A” and “B” in my little sample). Thanks Chris for the suggestion to use this feature.

I’ve done this in code, but Unity works with config files too. I haven’t done i t though.

Happy injection!

Windows Azure Guides in Japanese

2011-01-27T19:52:34Z

I can’t read a single character (except maybe one), but it looks beautiful:

http://msdn.microsoft.com/ja-jp/library/ff898435.aspx

Unity and MVC–Resolving types challenge

2011-01-26T23:10:51Z

Imagine you have a situation like this:

2 MVC controllers (A and B) have a dependency on SvcA. SvcA has a dependency on SvcB and a component implementing IX.SvcB has a dependency on something implementing IY.

Every time the system resolves CtrlA we want to provide Y1 and every time it resolves CtrlB, we want to provide Y2.

Something like this:

and

How would you configure Unity to solve this?

No “if() else” allowed. System supplies its own MVC’s ControllerFactory. (via ControllerBuilder.Current.SetControllerFactory). Ideally, we want the ControllerFactory to have no knowledge of any of these specific components.

Some help: read Chris’s blog and Unity docs.

A year’s balance–next project

2011-01-26T18:02:30Z

A little bit late for a year balance since the year has already started, or so I’m told. Anyway, as we prepare for the next project, I reflected on my team’s work for the last 18 months. 18 months is more than a year, so you might wonder why am I doing a year balance on the work done on 18 months? Good question.

Does content that nobody sees and uses really exist? Like the tree falling where nobody can listen. Does it make a sound? I figured that what you cared the most is the stuff that was available to you, not what we actually do here in the remote American northwest and keep to ourselves.

Let’s say then, that the output of that last 18 months was available to you in the last 12 months. Makes sense?

And here it is:

A Guide to Claims based Identity

This guide published a year ago, laid the foundations for all subsequent books. We heavily reused the core designs explained in this little book. We also explored a new format for our books, and a new style. This book inaugurated the “tubemap”: the diagram we used from then on to explain in a single picture the entire scope of the content.

Credits to our brilliant partner, Matias Woloski. Little known secret: VS 2010 samples of the book are available on codeplex.

Moving Applications to the Cloud

Our first book specifically focused on Windows Azure. We explored the considerations of migrating (and optimizing) applications for the cloud. As a colorful anecdote, this book includes an Excel spreadsheet with dollar amounts! A technical book with economics! Some were very opposed to it, and $ is a big deal in PaaS (and SaaS, and IaaS, and XaaS)! Money is a big motivator and every month, you get direct feedback on how you are using the platform. Other nuggets worth mentioning: MSBuild tasks to automate deployment, setting up multiple environments (think “Dev”, “Test”, etc.). It’s quite a popular book: made it to the top 25 in O’Reilly this week.

Developing Applications for the Cloud

Our second book on Windows Azure Platform. This time with no legacy constraints. Ah! the joy of building something from scratch using the greatest and latest! Notice the “1” and “2” on the covers of this and the other book? Well, it turns out people had quite some difficulty differentiating one from the other. So we re-designed the cover with the numbers now. Yes, we learned quite a bit on book design too. In addition to the end to end case study,

In addition to the end-to-end scenario (the surveys application we use as the “case study”), a popular chapter has been: troubleshooting Windows Azure apps. My personal favorite content is the little framework we wrote for asynchronous processing with queues and workers. Seems like a common pattern and I’ve already used it in many places.

Windows Phone 7 Developer Guide

The ying-yang of the Microsoft platform in one single book: small, portable devices on one end and the massive, infinitely scalable datacenter in the backend: Windows Phone 7 and Windows Azure. The most controversial aspects of the book? Use of the MVVM pattern is the by far top of the list. Second in the rankings? Use of Rx (Reactive Extensions) for asynchronous communications. Rx is like Linq in its beginnings: mind twisting at first, confusing perhaps, too much “black magic”, but impossible to live without it afterwards. Glad to see the framework available broadly now: .NET, JavaScript, Silverlight, etc.

With regards to MVVM, well…Silverlight might not be fully optimized for this pattern, but we still believe it is worth considering and paying the extra cost if things like testability are important for you. testability is important to us, so we decided to implement it and show you how. We ported Prism to the phone and replaced Unity with Funq for increased efficiency. But of course you don’t have to use any of that. We do expect you to slice and dice the guide as you see fit. Go ahead rip it off.

So, what’s next? What’s next comes in detail in the next post. But here’s in short: what we’d like to do is to extend the identity guide to include some really compelling and demanded scenarios (federation with social identity providers, SharePoint, Access Control Service, etc.) What do you think? Are you passionate about tokens and STSs and claims and WS-Federation, etc.? Have strong opinions on all of these? I’d love to know.

Tailspin Surveys Mobile - An early screenshot

2010-08-05T18:19:36Z

Our dev team is fearlessly building the first versions Tailspin Surveys Mobile. Here’s an early example of their work:

Now we are talking, huh?

Tailspin Surveys–Windows Phone 7 edition–A guide to the Guide

2010-08-04T01:17:47Z

As adopted in all our recent guides, here’s a quick map for the entire “Windows Phone 7 Developer Guide” . No promises of course on the final scope. We might end up merging some chapters, deleting some other, etc. But this is our current intent.

Feedback very welcome!

Tailspin Surveys–Windows Phone 7– UI Mockups

2010-08-04T00:01:22Z

Here’re some initial sketches of how Tailspin would look like and the navigation patterns we want to implement:

Navigation:

Home will list all available surveys to this particular user.
Take Survey, allows to start one particular survey from the home page. Many can be taken at the same time.
Survey Details shows metadata about a survey: estimated length, number of questions, expiration.
Settings, allows user to change some preferences (e.g. notifications) and configuration (e.g. credentials)

Pressing “back” simply goes to home. Pressing “back” from Home exits the app.

The Home screen:

The “Take Survey” screen:

Users can take multiple surveys at the same time, but only one instance of each.

The “Response area” depends on the question type. We are currently planning to support:

Free text
Ranges (from 1 to 5)
Multiple choice
Voice clips
Pictures (taken with the camera)

Navigation between questions is done with a lateral gesture. Pressing “back” saves whatever answers the user entered and then goes back Home.

The “Survey Details” screen:

“Long tapping” on a specific survey shows a small context screen where the survey can be tagged as a “favorite” (for filtering) and basic info is displayed (e.g. estimated length, number of questions)

The “Settings” screen:

Not much on this one yet. We envision this screen to allow the user to enable or disable push notifications. This happens when the tailspin backend detects new surveys that match user criteria. It will also allow user to capture credential options and some other configuration. (Not sure about all this yet though)

We’ll start sharing implementations of these very soon. Let us know what you think!

Tailspin Surveys–Windows Phone 7 edition

2010-08-03T06:55:54Z

Here’s a high level overview of the major components we are planning for Talspin Surveys.

A few notes:

The backend is essentially an extension to Tailspin surveys as described an implemented in the Windows Azure Architecture Guide (Part 2).
There’s now a new services head (an OData/JSON API) that is used by the devices.
Tailspin also has a “mobile website” to enable phone users to subscribe and download the app from the marketplace.
There are new survey question types that are specific for the phone:

Photos.
Voice.
GPS location.

Users of the app can subscribe to surveys that match a specific criteria (e.g. “surveys that take less than 10 min” or “surveys from “Adatum”).
Tailspin backend will use push notifications to advertise new surveys that match the user selection criteria.
The application architecture is pretty straightforward:

It will operate always regardless of network status.
The app always goes against local storage (isolated storage files).
A separate task will send results back to the backend service and download new surveys available to the user.
This task is likely to be a background thread in the same app.
UI will follow all WP7 guidelines as documented here.

We are very close to have a first early release on Codeplex.

Claims Identity Guide samples updated

2010-08-03T06:26:43Z

I’ve just uploaded to CodePlex updated samples for the Claims based Identity Guide. This have all been adapted to work on Visual Studio 2010, .NET 4.0 and MVC 2.0. See here for downloading the bits.

From the release notes:

Required configuration changes for IIS, DevFabric and Windows Azure

Both solutions 1-SingleSignOn and 5-WindowsAzure involve the a-expense.ClaimsAware project.
This solution is configured by default to run hosted in IIS, but the solution 5-WindowsAzure will run in a different environment (DevFabric and Windows Azure).
Please find the notes about the required required in the microsoft.identityModel section of the web.config of the a-expense.ClaimsAware project.

Cookies encrypted using RSA
As mentioned in the guide, the federation cookies are now encrypted using an RSA algorithm as we recommend in the guide. This change enables the involved sites to support web farm scenarios. This involves the following changed lines from the previous release:

In global.asax.cs

protected void Application_Start()
{
	FederatedAuthentication.ServiceConfigurationCreated += this.OnServiceConfigurationCreated;            

	...
}

private void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
{
	List<CookieTransform> sessionTransforms =
	new List<CookieTransform>(
	new CookieTransform[] 
		{
		new DeflateCookieTransform(), 
		new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
		new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate) 
		});
	SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

	e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}

These are exactly the same settings we use in the Windows Azure Architecture Guide.

In web.config:

<configuration>
    ...
    <microsoft.identityModel>
        ...
        <service>
            ...
			<serviceCertificate>
                <certificateReference x509FindType="FindBySubjectDistinguishedName" findValue="CN=localhost"/>
			</serviceCertificate>
        </service>
    </microsoft.identityModel>
</configuration>

Request validation in ASP.NET 4
ASP.NET by default validates all the POSTs done to the web application. This validation checks that the input is not dangerous. By default, an XML document that is not encoded is considered dangerous by ASP.NET. A token is normally submitted to the site as an XML document that is not encoded. To avoid getting an exception when the token is posted, you will add a class that will check if the input is indeed a security token. If it is it will return true and will let the request continue. If not, it will throw the regular "A potentially dangerous Request.Form value was detected..." exception.

The class WsFederationRequestValidator has been added for this purpose and it is enabled through the following web.config line:

<system.web>
    <httpRuntime requestValidationType="WsFederationRequestValidator" />
</system.web>

What’s next? Tailspin goes mobile…

2010-07-16T00:50:17Z

Now that the Windows Azure Architecture Guide – Part 2 is “done” (Done = content is complete and production is taking place. Production = index, covers, PDF conversion, etc), our team is ready for the next adventure.

Our fictitious ISV, Tailspin, is very innovative and wants to stay on the latest and greatest. Now they want to extend their flagship application: Tailspin Surveys, to mobile users. The essential idea being to allow its customers (Adatum, Fabrikam, etc) to publish surveys to people with Windows Phone 7 devices, so they can capture information from the field.

This is a “mobile front-end” interacting with a “cloud backend” scenario.

Note: Tailspin backend is mostly covered in the Windows Azure Guide, but we will extend it to support new user stories that are specific to the mobile client. So expect a different version included in the new guide.

Detailed scenario (hidden agenda items in red)

TailSpin: the “SaaS” ISV (this is covered in WAAG Part 2)

Develops a multitenant “survey as a service” for a wide range of companies (with “Big IT” and with “Small IT”)
Hosts the application on Windows Azure (service endpoint for WP7 app to interact: REST? SOAP? Chunky? Chatty?)
Develops a WP7 application for ��surveyors” (people taking surveys) (packaging the app)
Publishes the WP7 application to the Application Marketplace (Publishing the app, certification process, versions, trials and betas)

Fabrikam & Adatum (companies subscribing to TailSpin’s service)

(Self) design and launch surveys using TailSpin’s app (surveys now will have a target geography, used for “get surveys near me”)
Waits for collected information
Browses and analyzes results (added data-points captured by the phone: geo-location, voice, pictures, barcodes)

People with WP7: “surveyors”

Own a WP7 device (browse the Tailspin mobile website, download the app from the Application Marketplace)
They “work from home”
They subscribe to surveys that are targeted to the place they are (location based search, like “Surveys 40 miles from Redmond”)
They are notified of new surveys available that match their subscription criteria (push notifications)
They complete the surveys (UI design, app state, connectivity management, sending results back to the service-> service design, authenticating, being a “good citizen app”, resource management like battery levels)

In this scenario, the “surveyors” could answer for themselves, but our current preference would be that they’ll interview others or would provide multiple answers (think someone surveying homes or traffic patterns in different places or someone going from home to home in a neighborhood collecting information).

You can imagine a mechanism were there’s compensation for surveyors from the companies that submit the survey: Adatum could pay for every “x submitted surveys” or there might even be a “coupon” system: “every 10 surveys you get a discount coupon for the supermarket”.

As usual, the surveys application is just an excuse to discuss the design patterns behind the solution (all the red things above). The entire app will be functionally incomplete, but technically sound.

The current (draft) structure for the guide is the following:

Feedback of course, is greatly welcome!

Technorati Tags: Windows Phone 7,Mobile,Windows Azure,Windows Azure Architecture Guide,Tailspin

Happy birthday USA!

2010-07-05T05:56:41Z