Partager via

How to create a Custom Authentication Provider for Active Directory Federation Services on Windows Server 2012 R2 - Part 1

  • Article

In this series of five blog posts I want to show you how you can create your own Authentication Provider in AD FS on Windows Server 2012 R2. This Authentication Provider can then be used in AD FS for multi-factor authentication (MFA). The solution will use the users mobile device as a second factor for authentication, by sending a One-Time Password (OTP) or PIN to the device.

For those of you interested only in the AD FS related components, part 2 will be most interesting. That's where we will be creating the Authentication Provider itself. But if you are looking for a complete, working, solution, you might want to go over the entire set. So you might be interested by now what's in the other parts... or at least I hope you are. So here's a quick agenda;

  1. Introduction
  2. Creating the Authentication Provider
  3. Setting up Azure Mobile Services
  4. Creating a Windows Phone Authenticator App
  5. Putting it all together

Now, before we get started I have to remind you that this blog post series is only to show you how you can create this Authentication Provider. By no means is the solution we are creating an enterprise ready MFA solution. If you are looking into such an enterprise ready solution, I would recommend you take a look at the Windows Azure Multi-Factor Authentication.

Now... Let's get going!

Part 1 - Introduction

One of the key elements of conditional access in AD FS in Windows Server 2012 R2 is multi-factor authentication. Multi-factor authentication requires a user to provide the system that is authentication the user not only with a set of credentials (which the user knows), but amends this set with something that user must physically own. This could be achieved by using certificates (typically stored on smartcards). AD FS in Windows Server 2012 R2 supports this certificate authentication as well. But deploying these certificates to users might prove challenging. Perhaps they now all need a USB smartcard reader, or you have to deploy your own PKI first. Of course, there are many other solutions one of which is the user of hardware tokens. These might prove expensive though.
Luckily, in AD FS for Windows Server 2012 R2 we can simply plugin new authentication providers in AD FS to ensure the same end-user experience all the time. Furthermore, since AD FS now has the possibility to differentiate between internal and external logons, we could also enable this multi-factor authentication only for external logons.

In Part 2 we will see how we can create the Authentication Provider for AD FS. This authentication provider, targeted at browser based (or 'passive') logons, require the end-user the enter a PIN code after the initial logon. This PIN will be a one-time password (OTP) that will initially be hardcoded. In Part 5 we will revise the Authentication Provider, and add a random generated PIN to the solution.

Here is a screenshot of how this would look in AD FS;

In Part 3 we will setup Windows Azure Mobile Services to act as a broker. The Windows Phone App that we will be creating in Part 4 will register the end-users device with Azure Mobile Services. Our Authentication Provider will contact Azure Mobile Services to send PINs to end-users. In order to complete this part you will need to have access to a Windows Azure subscription. If you currently do not have such a subscription, you can create a free 30-day trial.

In Part 4 we will create the Windows Phone App that connects to Windows Azure Mobile Services to receive PIN notifications. Developing this application will require you to have a Windows Phone that is 'unlocked' for development. More information on this topic will be that blog post.

A screenshot of our super-simple Windows Phone App;

In Part 5 we will revise the Authentication Provider we created in Part 2. We will change the hardcoded PIN to a (pseudo-) randomly generated PIN. (Well, we're simply using the C# built-in "Random" function. Remember; this is only Proof of Concept, so please read all about the randomness of "Random" before you would consider deploying this in production.) This PIN is sent to the users Mobile device. The link between the user and a physical device is done in Active Directory; this is where we store this relationship. So our Authentication Provider will look up the device the end-user uses for MFA in AD. In order to achieve this, our very simple Windows Phone 8 App will create a unique identifier for the device which has to be put into AD. If you don't have a Windows Phone, but perhaps an iPhone or Android device; rest assured. The code can be easily adopted to allow these platforms to receive these PIN notification as well. That is because we will be utilizing the Windows Azure Mobile Services. These Windows Azure Mobile Services, that can be available for free, support the use of all these great mobile platforms. Once the user receives his or her PIN on the mobile device, this PIN is entered in the AD FS logon page, and the user is authenticated.

Last, here's the PIN notification:

So this is, in a nutshell, what will happen;

  1. User browses to a claims-aware application.
  2. Since the user is not authenticated, the user is redirected to AD FS.
  3. AD FS authenticates the user with AD credentials, through any of the supported protocols like Windows Integrated Authentication (WIA), Forms-Based Authentication (FBA) or Basic Authentication.
  4. Since the claims-aware applications Relying Party Trust is configured to use our MFA, our Authentication Provider is now addressed.
  5. The Authentication Provider looks up the users mobile device in Active Directory, creates PIN (or OTP) and sends this to Windows Azure Mobile Services.
  6. Windows Azure Mobile Services sends a Toast notification to the users mobile device. This notification shows the user the PIN.
  7. The user enters the PIN and clicks "Continue".
  8. The Authentication Provider validates the PIN (by going back to Windows Azure Mobile Services) and issues a proper claim to AD FS indicating that MFA has finished successfully.
  9. The user receives his or her token and is redirected back to the claims-aware application.

Doesn't sound too hard, does it? And really.. it's not that hard at all. Follow me as we take on this journey to create a true MFA solution for AD FS on Windows Server 2012 R2...

Take me to Part 2 - Creating the Authentication Provider

Comments

  • Anonymous
    January 01, 2003
    Thanks for the information. This shows that you can add any type of MFA to ADFS 3.0. I like that flexibility.
  • Anonymous
    January 01, 2003
    How to create a Custom Authentication Provider for Active Directory Federation Services on Windows Server 2012 R2 - Part 1
    thank you
  • Anonymous
    February 01, 2014
    In this series of five blog posts I want to show you how you can create your own Authentication Provider
  • Anonymous
    February 01, 2014
    We've been looking for these docs! Thanks so much.
  • Anonymous
    March 25, 2014
    Update the adapter for successful authentication
    In Part 1 , we created a basic adapter implementation
  • Anonymous
    June 01, 2014
    NIce
  • Anonymous
    August 27, 2014
    We have a requirments to customize primary authentication in ADFS 3. Since the ls website is completely locked down, Will it be possible to customize primary authentication of ADFS 3 using AuthenticationAdapter?