Pretty much everyone in the digital age has access to multiple services requiring authentication. Most modern workplaces have some sort of centralized authentication source, so at least there’s only one set of credentials to remember. Still, typing in these credentials repeatedly is burdensome for the user. An answer to this problem is browser-based federation, leveraging bearer tokens (something a user has) in order to provide authentication to multiple systems without reentering credentials. Sort of like when you go to a club and they stamp your hand with ink, single sign-on (SSO) leverages digital signatures in order to achieve much the same thing. In addition, federation allows businesses to partner together without exposing anything more than an XML file over the internet. This mitigates a lot of risk inherent in alternatives such as site-to-site VPNs, sharing of password hashes, or custom business to business APIs. Active Directory Federated Services (ADFS) is Microsoft’s on-premise response to this need.
ADFS supports four of the most popular single sign-on protocols today: SAML, WSFED, WSTRUST and OAUTH. Something people often find confusing is that SAML is both an authentication protocol, and the name of a token-type specified in the protocol definition. In fact, SAML and WSFED both use SAML tokens for authentication. WSFED is Microsoft’s preferred and proprietary federation solution, and is the method by which Sharepoint can leverage SSO. OAUTH on the other hand is an open standard, and commonly supported in open-source products. OAUTH does a really good job of providing a granular framework for how tokens expire, and is a popular choice for using to authenticate with a web-based API. WSTRUST is similar to WSFED, but is geared towards desktop applications as opposed to web applications.
ADFS can be confusing at first, because it uses a lot of Microsoft specific terminology for things that already have names. In a SAML transaction (and therefore also a WSFED transaction), there are three separate parties responsible for authenticating the client. The Identity Provider (IDP) has an awareness of a system that can authenticate a user. Typically, this is an LDAP system such as Active Directory or OpenLDAP, but a database system can also be used to house user accounts. The Service Provider (SP) authenticates a user, not because they trust the user directly, but because the user has a bearer token containing “assertions” or “claims” about the user. These might include a user’s username, email address, group membership, or arbitrary data about that user being passed from one party to another ADFS refers to the IDP as a “Claims Provider” and the SP as a “Relying Party”.
There are two common “logon flows” possible with this kind of federation. In an IDP-initiated logon a user can hit a special “landing page” and select from a list one of any number of applications in the federation (and be prompted to sign-in only to the first one they visit, as long as they don’t close their browser), and then be taken to that application. In an SP-initiated logon flow, the user tries to hit the application they want to access directly, gets redirected via a temporary redirect to the IDP to sign in, the IDP issues them a signed token, and then redirects them back to the original application where they are now signed in.
The magic that makes this work, is, like in most security related protocols, digital certificates. ADFS uses three separate certificates in order to broker this connection. The “service communications” certificate is used as the X.509 certificate for the HTTPS endpoint systems communicate with. Other parties hit this endpoint to retrieve metadata, and users are directed to it to sign-in. This endpoint must almost always be secured by a publicly trusted SSL/TLS certificate. SSLTrust can provide certificates in a format that’s especially easy for importing into ADFS. The second certificate at play is the “token-signing” certificate. This is arguably the most important certificate of all. The private portion of this certificate is used to digitally sign the claims (as only the holder of the private key can create such a signature, which is verified by the public portion of the key transmitted in the metadata to the SP who is validating the claim). The third certificate is the “token-encrypting certificate”, which is rarely used. When using ADFS, claims are already encrypted in-flight by way of the HTTPS communication between parties. Encrypting claims themselves is useful only if you want to prevent the client from being able to read the plaintext of their own claims, or, if you want to prevent an attacker who has already compromised the user’s computer from reading those claims. This is useful if your claims contain sensitive information such as long-lived API keys. By default, ADFS generates self-signed token-signing and token-decrypting certificates. It also performs an auto-rollover of these certificates on an annual basis. In a perfect world, where every federation partner of your organization monitors your metadata automatically, this auto-rollover would be fantastic. Unfortunately, many federation providers do not support this auto-monitoring of metadata, and changes to your systems must be communicated out in advance. In these organizations, it can make sense to disable auto-rollover, and use publicly signed digital certificates. This allows for properly publishing a CRL without hosting additional infrastructure.
For more information on ADFS, or to begin implementing it, the following are some of Microsoft’s most useful resources on the subject.
For a detailed overview of the technology:
msdn.microsoft.com/en-us/library/bb897402.aspx
For creating a Relying Party Trust:
docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust
For setting up certificates:
docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/enroll-an-ssl-certificate-for-ad-fs
For planning a new Federation Topology:
docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/plan-your-ad-fs-deployment-topology
For automating interactions with ADFS:
docs.microsoft.com/en-us/powershell/module/adfs/?view=win10-ps
Getting started with ADFS is easy. If you have Windows Server installed, ADFS can be installed right from within Roles and Features. A Domain Administrator account is required during the installation so that the setup can create an SPN in Active Directory corresponding to your federation farm name. A service account that will run the farm will also need to be created within Active Directory prior to beginning the installation. After installation of the feature, reboot your server, and add the ADFS snapin from within MMC.exe to add your first relying party today.