The course contains an introduction to Single Sign-On. An in depth explanation of the Windows Identity Foundation (WIF) and the ADFS version 2 server. In depth means: bits and bytes of the HTTP requests and responses, HttpModules, and customization. The analysis of the protocol is done with Fiddler2 and code analysis with Reflector. It also covers the Claims Language, Metadata and SAML2 partners. One module walks through some common scenarios and shows with code and configuration how to implement them.
Paul is an independent consultant and originally focused on technical software (robotics), then moved into (lower layers) network programming. Currently he sails the much murkier waters of Identity Management and Identity Federation, that way combining the interest in both programming and network infrastructure.
ASP.NET and SSO Welcome to Single Sign-On in ASP. NET. This is the introduction and appetizer for the rest of the modules. It's sort of the Zen of Federation. The module is dedicated to developers and architects who are not familiar with the concepts behind identity. We start with the list of familiar issues. If you suffer from one of these issues, then you will want to see the counter measures that the claims model proposes to achieve SSO, when you have multiple applications in your own organization. Once you or your service provider have taken that step, you can get the extra benefit of sign-on with a partner account. So far, that was plain technology talk, but there is a very nice analogy with passengers and airports. We'll take a look at that sequence, too. An objection to these protocols is that there are so many. We will discuss them a bit and show you how you can isolate yourself from the possible future problems. After this general introduction, which is valid for any implementation, we go to the specifics of the Microsoft implementation. All this sounds very nice, and it is really cool, but to new white papers, etc. Well, I hope you enjoyed it so far, and see you in the next modules.
WIF Passive Welcome to WIF Passive, a deep dive into WIF that means flow details, architectural details, HTTP pipeline events, etc. , etc. Let me explain what we will do in this module, and the order. I will start with a 101 on web traffic and tricks, not something for (inaudible) developers and architects, but probably a must for many administrators. Without this, they will not understand anything of the rest of the module. Then the basic of WS-Federation Passive, the web browser single sign-on. The messages that are sent between the web server with the application and the ADFS server, the programmer does the values, etc. I will demo the messages and record them with Fiddler, and use that later in the module. And the last somewhat intermediate part of this module, web. config of a web application. Developers need to know, administrators need to know, but then it is pedal to the medal. Here, we will be talking advanced ASP. NET, and when you are developing, you install the SDK to get (inaudible), but also the samples which you can copy and paste from.
ADFS2 Passive Welcome to the active directory version 2 passive part. Let me describe how the web single sign on works in ADFS server 2 and how you can customize and configure it. We'll start with an explanation of the architecture. First, we will look at the visible part in web. config. Then I will explain how it works internally. And we'll take a look at the messages and what will happen in the ADFS server when they arrive. Once you know how it works, there are some public classes that I used in the asp. net pages off the ADFS server. These pages show how to customize. As the last topic, the claims information. It is a huge topic and usually causes people to blink with in this course that actually goes deep into that topic.
ADFS2 and WIF 3.5 setup Welcome to setup ADFS2 and WIF application. This module describes This objective innovation we all know the challenges. Armed with knowledge and a little bit of extra training you can make a better specification of your requirements and then take your (inaudible) existing application and convert that to claims (inaudible) as a proof of concept. Being armed with that knowledge you can adapt your requirements and make a final design. Now this part is relatively well plannable; it's not too much. It depends very much, of course, on how big the application is, how large the team is, of course, but five to ten days for this and a working proof of concept is normal. The next step is, of course, very much dependent on the organization and there's no way of saying how much time it will take. You have to set up a development environment for people who are not used to validation. If you don't do that, they may lose too much time. Then you do the real production look at the internet, just search for your problem, and you'll probably find it on the claims based excess forum.
Unraveling the claims language Welcome to unraveling the claims language. This is a very interesting part of (inaudible) 2, pun In the 2009 beta timeframe when I first saw the UI it did shock me too. When I had to disassemble the parser to learn the language the shock was even bigger. But now I do appreciate it and I do hope that this module will avoid a lot of that pain for you and make you appreciate it as I do now. In this introduction I will show you where you where all this presents itself in the ADFS 2 server. Then a claims program overview followed by many examples. In the reference there's a point to my notes on the claims language. These are my personal notes which resulted from my work with Reflector back in the spring of 2010. It contains a sort of (inaudible) presentation of what was implemented by Microsoft using some (inaudible). It also contains some diagrams with differences between SAML 1. 1 and SAML 2 tokens. From an earlier module where we showed the sheer endless pipeline, we remember that each ADFS server has three types of claim (inaudible), one per claims provider and two per relying