Active Directory Federation Service (ADFS) uses claims-based identity model to maintain application security and to implement federated identity.

ADFS is a concept of Windows Server operating system, that provides users with single sign-on access to the application, those are located across organizational boundaries.

For Example:

We have 2 organizations – Organization 1 and Organization 2. Organization 1 wants to access the app which is hosted in Organization 2. Now to achieve this, both the organizations have to achieve trust so that they can share their resources with each other, but this can lead to a security risk because both organizations will be able to share all of their resources. Moreover, in order to create a trust, both organizations have to open a certain port number, for ex- 443, 389,89 and 636. Now this is where ADFS comes into picture. In ADFS we create a federation trust with a particular application, and the users from one organization will be able to access only the application that they are authorized to, and this trust requires only port 443 to open.

WHY ADFS

When an Active Directory user account wants to access certain applications, AD will generate a Kerberos ticket once the user has been authenticated, and this Kerberos ticket will be sent to the applications that this user is trying to access. 

Now one thing to note here is kerberos tickets will always contain the same set of attributes. A kerberos ticket contains user account SID, group SID and the authentication timestamp. Now in this example, the user is trying to access 2 different applications. When this user gets authenticated, AD will generate two kerberos tickets, and send these ticket to both the applications, and both tickets will have the same set of attributes, so it doesn’t matter what sort of application the user is trying to access, the same set of tickets will be sent to the applications. But the outcome will change when an application requires a different set of attributes for authentication purposes. Suppose App1 needs department attribute and app 2 needs email address attribute for authentication, then this is where ADFS comes into picture.

Claim-Based Identity Model

Every user in the Active Directory has certain attributes, for eg- email address, department, user principal name or contact number. All these attributes are called claims in ADFS. In ADFS, when a certain user tries to access certain applications, those applications will contact the ADFS server, then the ADFS server will contact the AD server to get the user authenticated. Once the user is authenticated, ADFS will send the token to the applications. ADFS has the ability to customize the token as per the application’s requirement. If app1 needs a token on the basis of department attribute, DFS server will construct a token on the basis of department attribute and will send the token to the application. So this is one of the reasons why we need ADFS. ADFS has the ability to customize the response as per the application’s requirement. ADFS server will construct the token as per the app requirement, application provider will validate the token and provide access to the user, and this is called claims-based identity model, or claims based authorization model.

Federation Trust

An example- Let’s say a person is going to board a plane. When a man enters the airport, he has to show his ID proof, and ID proof can be DL, passport or Aadhar card. Once he shows his ID proof, he goes to the ticket counter from where he gets the boarding pass. Once he gets the boarding pass, he goes to the boarding gate and boards the flight. So the question that arises here is – Why will security trust the person on the basis of DL? This is possible because the DL is issued by the Department of Public Safety, and there is a trust between the department of public safety and the airport.

In ADFS, a user tries to access an application that is hosted in another organization, and is asked to prove. User will go to his identity provider, the identity provider will issue a token to the user, the user will provide the token to the resource provider, resource provider will issue another token to the user, then the user will provide the token to the application and the user will gain access to the application. But why should the resource provider trust this user?

Because there is a trust between two organisations. One important thing we need to notice is that the entire communication that’s happening between the user, identity provider and the resource provider is handled by the user itself. In ADFS, the entire communication is handled by the client machine. Identity providers do not contact the resource provider. The client machine will contact the identity provider for authentication. Client machine will forward the token to the resource provider, then the client machine will receive a token from the resource provider and will forward that token to the application. So here we are reducing load from the server, and the entire load is taken by the client machine.