by Jim Lindsay
Knowing about SAML, OpenID Connect, and Oauth Authentication Protocols
Discerning the nuances between the security protocols for authentication can be a challenge. This perspective is provided to show the differences between AD FS, SAML, OpenID Connect, and Oauth what they are and how they are used.
Active Directory Federation Services (AD FS) Authentication Protocol
Microsoft developed AD FS to extend enterprise identity beyond the firewall. It provides single sign-on access to servers that are off-premises. AD FS uses a claims-based access control authorization model. This process involves authenticating users via cookies and Security Assertion Markup Language (SAML).
That means AD FS is a type of Security Token Service, or STS. You can configure STS to have trust relationships that also accept OpenID accounts. This lets companies bypass setting up separate registration and user credentials when adding new users—they can just use the existing OpenID credentials.
AD FS is a valuable tool, but it does have a few drawbacks:
It’s cumbersome to use when integrating with cloud or non-Microsoft mobile applications
It requires IT resources to install, configure, and maintain
It’s difficult to scale and requires tedious application installations
Although it’s technically a free offering from Microsoft, using AD FS can incur hidden costs like the time and effort for IT to maintain it.
What is SAML Authentication Protocol
Security Assertion Markup Language or SAML is the oldest of the main federated identity protocols with its last major revision in 2005. There are three major players in SAML – the user, the Identity Provider (or IdP) that authenticates the user, and the Service Provider (or SP) such as an application.
SAML has three primary components which are the assertion, the protocol, and the binding. The SAML assertion is an XML-based package of information that contains specific information such as the user, group the user belongs to, or any other information that might be useful to an application. Assertions are for authentication (identifying a user), attributes (information about a user), or authorization (what a user can access and do).
The protocol defines how assertions are sent and received. Finally, the binding is a definition of how SAML message exchanges and Simple Object Access Protocol (SOAP) exchanges are mapped to each other.
Here's a simplified use case of SAML. The user needs to access many different applications. The user’s client tells an application - which is the Service Provider - that they want to access its services. The Service Provider then needs to check if the user is authenticated. If they are, then the user is free to proceed. If they aren’t, the client needs to go to the Identity Provider for authentication.
The Identity Provider will authenticate the user against some credential at this point. Once the Identity Provider has authenticated the user giving access to the application, it then creates the SAML assertion. The Identity Provider passes the SAML assertion to the client which then passes it to the Service Provider. The Identity Provider can also pass the assertion to different applications as needed saving the user from re-authenticating.
SAML 2.0 flow diagram
Microsoft & AD FS Terminology
Microsoft’s Active Directory Federation Services has its own terminology and approach to SAML, so it warrants a short explanation. Microsoft AD FS is an identity provider.
Relying Party is the term that Microsoft AD FS uses to mean Service Provider.
Claims Rules is another term that only Microsoft AD FS uses. Claims Rules are rules you can apply to alter how or when to invoke authentication. For example, an admin could set up a claims rule that only applies when a user comes to AD FS as they’re trying to get to Dropbox. Plus, it prevents them from using a mobile device allowing that user to log in with a laptop or desktop device, but not their Android or iPhone. Some IdPs other than AD FS can create similar rules, but AD FS allows for some of the most robust and complex rule creation.
ImmutableID is the Microsoft Azure AD equivalent of an ObjectGUID. It’s not specific to AD FS, but it’s worth a mention.
WS-Fed is similar to SAML and abides by many of the same rules. It’s a protocol specifically created by Microsoft and not widely supported by IdPs other than AD FS.
Benefits of Configuring 3rd Party Authentication Providers as Primary Authentication in AD FS
Organizations are experiencing attacks that attempt to brute force, compromise, or otherwise lock out user accounts by sending password-based authentication requests. To help protect organizations from compromise, AD FS has introduced capabilities such as extranet “smart” lockout and IP address-based blocking.
However, these mitigations are reactive. To provide a proactive way to reduce the severity of these attacks, AD FS has the ability to prompt for non-password factors prior to collecting the password. For example, AD FS 2016 introduced Azure MFA as primary authentication so that OTP codes from the Authenticator App could be used as the first factor. Building on this with AD FS 2019, you can configure external authentication providers as primary authentication factors. Following are two key scenarios this enables.
Scenario 1: Protect the Password
Microsoft developed AD FS to extend enterprise identity beyond the firewall.
It provides single sign-on access to servers that are off-premises. AD FS uses a claims-based access control authorization model. This process involves authenticating users via cookies and Security Assertion Markup Language (SAML).
Scenario 2: Passwordless
You can also eliminate passwords entirely by completing a strong, multi-factor authentication using entirely passwordless methods in AD FS.
Azure MFA with Authenticator app
Windows 10 Hello for Business
Certificate authentication
External authentication providers (this provides the best risk mitigation for impersonation attacks like phishing and MitM) which requires some sort of integration with Microsoft