The conclusion to my previous post was that I’ll be showing how to implement YubiKeys along with Active Directory Federation Services. So, where do we start on this topic?…

It’s sort of a logic that says that if you aren’t familiar with Active Directory Federation Services (from here on abbreviated as ADFS) a lot of this post will not make sense to you at first glance. So, if you are familiar with ADFS skip ahead – if not I’ll have a few paragraphs explaining why you might be interested in taking a look at ADFS.

Surely everyone has noticed that there are a lot of web sites where there’s two options for signing in; either using an account for that particular site or "use your Google/Facebook/Twitter account to sign-in". The basic concept is easy enough – you already have a user identity, so why would you need another one? Why can’t you re-use the existing one? If you have ever logged on to a domain-joined Windows computer you’ve experienced this already. There is a central user catalog called "Active Directory" that you sign in to, and after being verified there you can access your file shares, Exchange account, etc without needing to sign into each and every one of those services.

That is certainly a good reason for re-using the identity you already have, but there’s another one as well. A lot of programmers are doomed to repeat the failures of others due to their insistence of doing things from scratch. What are the odds that I will be able to code (on my first attempt) a secure login solution that is resistant against cross-site scripting, SQL injection, buffer overflows, and whatnot? (Hint: don’t go all in betting on my success.) For some reason Facebook doesn’t instill a lot of confidence in me when it comes to protecting their users, though they are probably still better at it than me, but at least Google and Windows Live give me the impression of having done a thing or two to proof their solutions.
(…)
I walk through the steps required to support YubiKeys in an ADFS setup.