ADFS Authentication Methods and Flow Explained
ADFS Authentication Methods and Flow Explained. Handling your enterprise’s user credentials is daunting, especially if your company has an ample number of workstations and employees. Nevertheless, companies cannot afford to act laid back when it comes to cyber security. Each workstation and/or profile must be demarcated and assigned accurately. Handling this using your company’s resources is far from ideal.
Hence, the existence of ADFS. However, are you curious as to what types of ADFS authentication methods and flows exist and which one is suitable for your company’s workloads? You are in the right place. The following guide will give you simple explanation’s and examples of these concepts.
So let us start with ADFS Authentication Methods and Flow Explained.
Primarily, ADFS is a federated identity management solution developed by Microsoft for Windows Server. It facilitates single sign on (SSO) for web applications. For instance, once a user logs into their workstation, under ADFS, they are authorized to use the third party web applications and network resources assigned to that workstation. Then, ADFS essentially sends a claim to the web applications in behalf of active directory – as opposed to your actual credentials.
Gartner projects end user spending on public cloud services to reach $482 billion by the end of 2022, a 21.1% increase from the previous year. More companies are embracing cloud computing, particularly SaaS. Hence, tools and services such as ADFS are important. Largely because ADFS enables companies to support web service interoperability between various vendors on the market. These third party web application vendors may be responsible for providing your company with its email system (gmail), productivity and reporting tools (Office), or your payroll system.
Why Do You Need ADFS Authentication?
VPN tunnels are one of the most popular alternatives to using ADFS. Your cloud provider then asks you to create a trust relationship between your active directory domain and their service domain. This is what is known as the VPN and Trust Model. However, this isn’t an ideal option. It requires a tremendous amount of setup and it isn’t very secure.
Creating a document exchange service between your service provider and your company is another potential option. In this scenario, your company exports CSV or XML documents to the cloud service provider. While this may sound like a good alternative, it presents a few problems. If any information changes on your user domain, it may cause conflicts on the cloud domain. For instance, one of your users may legally change their name because they got married or transitioned. People leaving your company and being removed from your Active Directory list is one of the most common causes of these types of conflicts. As such, you may find that this path isn’t suitable for your company.
Well, complete isolation is another possible alternative. In fact, most non business users apply this method. This is where your user domain is completely separated from your web service/application domain. Thus, you have separate user credentials for both of these domains. However, this isn’t ideal for enterprises. Every time your company onboards a new employee, you need to set new credentials for your cloud software stack and the employee workstation. This adds an unnecessary workload to your company. Your employees are then in charge of handling all their credentials, which is quite difficult and unsafe. Especially if you consider that most passwords expire too. Hence, ADFS is a necessity. It’s the best option among the above stated alternatives.
Image Source: www.freepik.com
ADFS Authentication Flows: How Does ADFS Work?
There are two domains in a standard ADFS model; your company’s user domain and the cloud resource domain. Your user domain will contain the active directory, an ADFS server, and your user workstations. When a user logs into their workstation and tries to access a cloud resource, they make an initial request for a login. The cloud resource redirects the user’s request to ADFS. After that, the ADFS server then authenticates the user by checking their active directory. Once ADFS validates the user successfully, it sends a claim back to the user in the form of a cookie or token. It also sends a redirection link to the cloud resource.
Following, the cloud resource then accepts the claim and logs the user in. Much of this process is automatic. Nevertheless, you should note that username and password aren’t being passed to the cloud service or resource. In most cases, your company and the cloud resource provider must first ascertain what information must be included in the claim. This could be the user’s first name, last name, company ID number, email address, etc. It may be one attribute or a mixture of them. Incidentally, your company has what is known as a federated trust agreement with the vendor hosting the cloud services.
Nonetheless, this is only a single simple example of ADFS implementation. Although, it is considered the most common implementation of ADFS and uses SAML 2.0-type authentication. Because your company passes a cookie/token that contains the claim to the cloud resources provider. As you can see, it’s a secure and more efficient alternative to the options listed in the previous section.
ADFS Authentication Methods
Microsoft developed ADFS not just for cloud resource access but as a general SSO tool for cross boundary access to applications and resources. Sometimes these are internal boundaries created to segment a company’s network infrastructure for Zero-Trust purposes. Ultimately, you can use ADFS to provide authentication for internal applications and resources.
There are two main types of ADFS authentication methods:
- Passive/Implicit ADFS Authentication
- Active/Explicit ADFS Authentication
Both of these are used for Windows Server integrated authentication. Their authentication flows are quite similar as they both use ADFS servers as the identity providers. However, they also have distinct features. Let’s take a closer look at these authentications methods and their flows.
What is The Passive Authentication Method and Flow?
The passive ADFS authentication method typically requires the user to provide credentials through a web browser or login screen of some sort.
Historically, this was facilitated through a web service federation (WS-Federation) protocol. The authentication occurs through a collection of redirects – essentially a flow. A good example of this is Office 365’s ADFS authentication flow. Let’s look at a detailed example of how this authentication methods flow.
In this scenario, an ADFS server acts as an identity provider (IdP). Microsoft’s EvoSTS acts as the security token (for claims) provider.
ADFS Passive Authentication Flow
- The user attempts to access Office 365 from their web browser.
- Next, the user is redirected to Microsoft live authentication service, which then directs the user to EvoSTS.
- The user is then presented with a sign in page that requires the user’s principal username.
- EvoSTS then verifies, if the domain the user belongs to is federated or not.
- If the domain is federated, the EvoSTS returns the ADFS server endpoint URL to the user as a token. This will ultimately reroute the user to the ADFS server.
- The ADFS server presents a Forms Based Authentication (FBA) prompt which requires the user’s password.
- Once ADFS verifies the user’s credentials (successfully), it issues a SAML token to the user’s machine (the client).
- The user’s machine/client forwards the token to EvoSTS.
- EvoSTS issues authentication cookies/tokens to the user’s machine which grants them access to Office 365.
The passive authentication model basically follows the same principle and flow of the Saml2 Browser SSO approach:
Image Source: Wikimedia Commons
Also Read
What is The Active Authentication Method and its Flow?
The Active ADFS authentication method slightly contrasts the passive method in that it uses a web service instead of relying on redirects. Traditionally, it has been implemented through the WS-Trust protocol. Usually, the user is not required to provide any credentials as the web service may already have them. This makes the authentication feel almost “headless”. The Outlook client is a good example of a service that uses active authentication.
In the case of Outlook, the WS-MetaDataExchange (WS-MEX) protocol processes the authentication. It is an endpoint responsible for metadata exchange. In the following example, a federated domain user attempts to create a new Outlook profile or access an existing one. The previous example used EvoSTS. This example will use OrgID to handle requests in EvoSTS place.
ADFS Active Authentication Flow
- The user attempts to create a new Outlook profile or access a pre-existing one.
- Outlook requests the user’s credentials which will be sent to the EXO service.
- EXO passes the User Principal Name (UPN) to the OrgID for realm discovery.
- OrgID checks the domain name of the UPN and returns the ADFS server STS endpoint to the EXO service.
- EXO then passes the user credentials to the ADFS server on behalf of the user.
- The ADFS server then issues a SAML token to the EXO service.
- EXO submits that token to OrgID.
- In return, OrgID issues an authentication token to the EXO service.
- EXO then sends access cookies to the user’s machine.
- The client machine requests the access token from the EXO service.
- EXO issues the access token to the client allowing the user to configure the Outlook profile.
Companies typically implement the active ADFS method in correspondence with their internet service and security provider(s). In some cases, they provide the necessary web service(s) to make this approach accessible. Essentially, the active ADFS authentication method and flow follows and improves upon the established designs of Passwordless web Authentication.
Image source: Wikimedia Commons
Thank you for reading this article blog ADFS Authentication Methods and Flow Explained. We shall now conclude.
ADFS Authentication Methods and Flow Explained Conclusion
To conclude, ADFS Authentication Methods and the Microsoft Windows Server ‘s ADFS is not inflexible. Quite contrary, it does allow you to configure additional authentication methods for ADFS. For instance, if your company hopes to implement multi-factor authentication (MFA) with ADFS, they must add additional authentication paths.
This will only subtly change your original authentication flow.
Typically, Windows Server’s ADFS allows you to select Certificate Authentication as an additional form of authentication. This is essentially smart-card based authentication. Nevertheless, Microsoft also offers support for third-party authentication methods. Additionally organizations can build custom authentication methods in latest versions of Windows Server.
Microsoft endeavors to release the most secure server operating system with each iteration of Windows Server. Windows 2022 uses the same version of ADFS (more or less) as Windows Server 2019. After all, if it’s not broken don’t fix it, right?
Nevertheless, ADFS continues to be a major part of the Windows Server security toolset as long as Active Directory continues to exist. Organizations and professionals must have a clear understanding of the various ADFS authentication methods and flows to ensure that they select ones that complement their IT and network infrastructure. Knowing remains half the battle.
