The event was of a special importance to me, as it was my last contribution to p&p and to Microsoft. The time has come for me to do something different.

Microsoft in general, and p&p in particular have been the experience of my life and the best place I’ve ever worked for. I would undoubtedly do exactly the same if I went back 12 years and was presented with the opportunity to join Microsoft again. It has been very much like a home, and I will miss it a lot.

I’ve been privileged to meet and work with exceptional people. I’ve traveled the world. I’ve worked on really great projects. Working for Microsoft is demanding, but it’s a very generous company on many dimensions, and I’ve grown an all aspects. Thanks Microsoft and thanks to my many colleagues, mentors and friends!

In everything I’ve done, my personal guiding principle has always been to “leave behind something better than what I’ve received”. I have had many failures, but also many successes, and I hope I have lived up to that principle.

So what’s next?

I want to put all that experience and learning into action, by starting a new company. I’m joining QraftLabs with a pretty amazing group of friends. As many of you know, I’ve invested quite a bit of my time in the last few years into cloud computing and identity management. Our first product will be in the identity management space and it is called “Auth0” (AuthZero). Our goal is to dramatically simplify identity federation for cloud apps. Especially for those that are selling their services to enterprises with their own identity infrastructure (like AD) or using Office 365.

Identity Federation is still hard. We published two guides on it, but there are still quite a few moving parts and my experience is that there’s room for improvement. So that is what we will be focusing on first. (Remember my “IssueTracker” series 4 years ago? wow…4 years…)

And you might think: wait! Isn’t Windows Azure Active Directory supposed to address that? Sure, it is an important part of the equation (and we will fully support it), but there are other aspects and challenges we want to address also, that complement WAAD: other protocols, a wider variety of identity providers, tools for troubleshooting, etc.

Obviously, this blog will freeze with this last post. It might or might not stay, I don’t know. If you want to continue to follow me and the next chapter of my journey go to: https://blog.qraftlabs.com and/or https://blog.auth0.com

Thanks again!

Eugenio

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: https://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: https://entlib.codeplex.com
• Public backlog: https://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: https://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: https://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.

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.

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

1. 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.
2. 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”.
3. 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.
4. 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.

There’s nothing unexpected here really:

1. We call the Identity Provider using a RequestSecurityToken message (RST)
2. We send the SAML token to ACS and get a “Simple Web Token” (SWT)
3. 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.

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.

1. 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.)
2. 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!

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:

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

Register for the live session here: https://www3.gotomeeting.com/register/976980454

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