Build a Custom ADFS Authenticator Microservice With Lambda And Serverless
Originally published on October 30, 2017 by Greg Campion
Last updated on November 06, 2017 • 5 minute read
ADFS is a great service offered by Microsoft that one can use to authenticate users for a variety of services like AWS, Office 365, Azure and so on. But what if you have your own application and want to use ADFS Authorization? What if you want that application to be serverless?
At Paessler we host our support files with AWS’s Simple Storage Service or S3 and wanted to make sure that only our support team can access them. Since this infrastructure is all serverless, this task presented us with the unique challenge of figuring out how to authenticate someone to allow them to download a file from S3 with Active Directory and ADFS.
iActive Directory (AD) is a directory service created by Microsoft for use in a Windows Server environment. It provides authentication and authorization functions, as well as providing a framework for other such services. The directory itself is an LDAP database that contains networked objects. Active Directory uses the Windows Server operating system. Read more ...
First, a little bit of background. It used to be that PRTG would upload its support bundles (log files and configuration files from PRTG) directly to an FTPS server that we hosted at our datacenter. This meant that the FTP server had to always be up, support had to log in with their VPN and RDP to a computer at the office since SMB isn’t allowed over our VPN and then had to find the support bundle that they were looking for on the server.
This was all quite a bit of work for support so instead, we wanted PRTG to upload a support bundle to S3 and then have a support ticket automatically created with a direct link to the support bundle so support could get the bundle with one click. The problem was figuring out how to authenticate the person downloading the file.
We solved this issue by building a system that does the following:
PRTG contacts an API endpoint to get a temporary URL that allows it to upload a support bundle to S3. Once the bundle is there, we trigger a function that creates a support ticket with a link for the support bundle. Instead of being a direct link, this link will authenticate the support person with Active Directory Federated Services and create another temporary URL that allows them to download the file to their computer.
Some of the issues that we have solved with this system are:
- PRTG now uploads customer data over HTTP with TLS instead of over FTPS which is more secure and less work.
- There are 2 authentication factors for allowing access to our support bundles since support people have a locally installed certificate that allows them to use the new service and they must login with their Active Directory credentials.
- Bundles can be accessed by our support people who are not at the office since S3 is available worldwide and our ADFS server is also internet facing.
- We don’t have to worry about the storage of support bundles since S3 is very durable and elastic.
- We no longer need to ensure that our FTPS server is always up and running.
- Support personnel have only 1 click to get what they need to do their job.
If you want a walkthrough and the code for how to build a similar authentication microservice, just follow the link.