ADFS claims based architecture

In this blog we will learn what is ADFS claims based architecture, we will dive deep into ADFS security token, we will learn what is claim in ADFS, what are types of claims in ADFS, we will talk about claims-based applications, and we will take a look at ADFS airport example.

Watch video

Join us on our YouTube channel and watch this video on ADFS claims based architecture and more concepts of ADFS.

Airport example and ADFS

There is a very famous example of the authentication protocol that you follow each time when you visit an airport.

If you want to board a plane you can’t simply walk up to the boarding gate and you just can’t show them your driver license or the passport and get to the plane.

Instead of this, you first show your driver license or any ID proof to the security agent on the main gate of the airport. Then you go to the ticket counter. From ticket counter you collect your boarding pass. Once you have the boarding pass, you go to the boarding gate, you show your boarding pass to the boarding gate agent. After verifying your boarding pass, boarding gate agent lets you board the flight.

airport example and adfs 1

ADFS security token explained

If you take a look at the boarding pass, It includes lots of information like, airline name that issued this boarding pass, it has your name, it has the name of flight you are going to board at this particular time and this will be your seat number.

boarding pass

There are multiple ways to get a boarding pass. You can either collect it from the ticket counter or you can book your flight online and you can print your boarding pass at home. The boarding gate agent doesn’t care how the boarding pass was created or which issuer you used. As long as your boarding pass is trusted by the airline, it is valid. They only care that it has authentic set of information that give you permission to get on the plane.

Now if we compare this example with ADFS, the bundle of information or the boarding pass is called security token in ADFS.

adfs security token

Each security token is signed by the issuer who created it. Any claims-based application will consider a user to be authenticated if he presents a valid and a signed token that is issued by a trusted issuer. In above example, the boarding pass was issued by the airlines. That means airlines is the issuer. And you can compare airlines with ADFS because ADFS issues the security tokens to the applications.

In above example, plane is the application. Plane doesn’t care what sort of ID proof you are showing to the boarding gate agent. Whether you have shown your driving license or your passport. But as long as you have a valid boarding pass, you can board the plane.

In the same way, when an application connects to the ADFS server, the application doesn’t care if the user was authenticated using NTLM or he was authenticated using Kerberos. Application doesn’t care what sort of credentials that user presented for authentication, what sort of authentication method was used (forms-based authentication / SSL / Integrated Windows Authentication). As soon as a valid security token that is signed by a trusted issuer is issued to the application, user can get access.

ADFS token types

There are multiple types of tokens those can be issued by the ADFS server and can be consumed by the application.

adfs token types

If an application is using WS-FED protocol, ADFS will send SAML 1 token to the application, and the format of the token will be XML.

If an application supports SAML protocol, then SAML 2 token will be sent to the application, and the format of the token will be XML.

If application supports OAuth protocol, then ADFS will send JWT token to the application, and the format of the token will be JSON.

And if application supports OpenID Connect protocol, then JWT token will be sent to the application and the format of the token will be JSON.

So depending on the protocols that application supports, ADFS will construct the token, and will send to the application.

Information in ADFS token

Now let me show you what sort of information ADFS security token contains. The below example is taken from a security token that was issued when a user tried to login to portal.office.com.

In below security token you can see the date and time when this token was created and what date and time this token is going to expire.

security token 1

You can see Issuer is http://adfs.office365concepts.com/adfs/services/trust which is our ADFS server, you can see this token is issued to MIcrosoftOnline aplication, you can see the username of the account that tried to access the application and the claim that was added in this token (UPN).

In below image you you can see the token-signing certificate.

security token 2

What is claim in ADFS

A boarding pass contains some information like, your name, flight name, your seat number, and name of the airlines who has issued this boarding pass.

A security token also contains similar information. It has the name of the issuer (federation identifier name of your ADFS server). It contains the name of the application to whom this token is issued, it has the details of the claims, it has the time stamp when this token was issued and till what time this token is valid. And it includes token-signing certificate that was used by the ADFS server to sign this token.

Similarly a user account also has few attributes like, EmailAddress, DisplayName, PhoneNumber, DepartmentName and so on. These attributes of a user account are called claims in ADFS.

ADFS claims based architecture

ADFS provides the logic to authenticate the users in several ways. ADFS can customize every security token as per the application requirement. ADFS server can accept the tokens those are issued from another ADFS server from another realm. This is called identity federation.

Important: A realm is basically a security domain or security boundary for your applications.

When an application contacts ADFS server, ADFS reaches Active Directory to get the user authenticated. Once user is authenticated, Active Directory returns certain claims to the ADFS server. Then ADFS constructs a token, it includes the claims within the token and sends it to the application. Application doesn’t directly authenticate the user. It completely relies on the security token that is issued by the ADFS server.

A claims-based application should know how to validate the incoming security token and how to read the claims that are inside the token. Each application is different and not all applications need the same set of claims.

claims based architecture

One application might need the email address of the user, and other application might need department attribute. And ADFS has the ability to customize the security token as per the application requirement. If application1 needs emailaddress attribute, ADFS will construct a token, it will include emailaddress attribute within the token and will issue that token to the application. In the same way, it will construct another token, it will add department attribute within the token and will send this token to the application. ADFS can customize the tokens as per the applications requirement.

Why claims-based identity

Now let’s understand why you should choose claims-based identity.

  1. If we talk about Kerberos, Kerberos can’t authenticate the users who are in different realm. Because the domain controller is guarded by the firewall. And if you are working externally, you’re expected to use a VPN to access the corporate network. But claims were designed to provide the flexibility that other protocols may not provide. The standard protocols that exchange claims are specifically designed to cross boundaries. For example, security realms and firewalls.
  2. With claims, it’s no longer the application’s responsibility to authenticate the users. All your application needs is a security token from the issuer. And even if you are upgrading the security of your infrastructure, this will not break your application or there is no need to re-configure the application.
  3. Claims are issued by a claims provider they are packaged into a security token and this security token is issued to the application. Here claims provider is Active Directory and the service that issues the token is Security Token Service (STS).
  4. There are many reasons why you might need something other than Windows authentication. You might have a web application that is used by the people who don’t have accounts in your Windows domain. Or your company has merged with another company and you’re having trouble authenticating across two different Active Directory forests that don’t have a trust relationship.

These are the couple of scenarios where claims-based Identity is the right option for you.

Conclusion

In this blog we learnt what is ADFS claims based architecture, we discussed ADFS security token, we learnt what information ADFS security token contains, we learnt claims-based identity and discussed airport example and ADFS.

Found this blog helpful and informative? Please share it within your community, join our YouTube channel for video on Cloud technology, and join our Newsletter for early access of blogs and updates.

We welcome you to browse our other articles on ADFS (Active Directory Federation Services):
What is ADFS
What is federation trust in ADFS
ADFS deployment types
How to install ADFS on Windows Server 2016

Happy Learning!!