What you need to know about authentication/authorization protocols! | by umang goel | May 2022

Securing servers and data is one of the biggest challenges in the IT industry today. There are many open standard protocols that are used for user authentication in applications, but sometimes it becomes very difficult to know when to use what, understand and remember the basics of the different protocols. In this article, we will focus and gain a basic understanding of open standards security protocols.

  1. LDAP
  2. KerberosName
  3. SAML and SSO
  4. OAuth

LDAP (Lightweight Directory Access Protocol)

Vendor-independent access protocol for accessing Active Directory data over the network. Active Directory is used to store organizational data such as department information, user profiles, device data, security policy, etc. The LDAP directory is also used for authorization/authentication of users to access various resources in the organization.

LDAP server stores data in the form of a tree or we can say in a hierarchical data store. Example shown in the figure below. The tree sheet contains the actual objects such as users, files, devices, etc.

LDAP functionally binds the LDAP client to the LDAP server. The client sends the request to the LDAP server to access/search some resources or for authentication. Once the LDAP server receives the request, it processes it using its internal query languages, searches the active directory, and returns the result to the client. The customer after obtaining the data processes them according to his needs.

Example data for user authentication on the LDAP server:

dn: uid=joe,ou=otherpeople,dc=springframework,dc=org
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Joe Smith
sn: Smeth
uid: joe
userPassword: {SHA}

How LDAP supports authentication:

  1. A user needs to be added to the LDAP server, which can be done by the system administrator by adding the relevant details using the LDAP ADD operation. When the user is first created, the password is created with force password change set to true so that the user is forced to change the password on first login.
  2. When the user logs in for the first time, he changes the password which is updated in the active directory.
  3. Now, if the user wants to access a resource on the LDAP, he enters the username and password on the LDAP client which is then authenticated with the data stored on the server. If the user is authenticated, the requested resource is returned, otherwise the connection failed response is returned. The link established between the client and the server is broken once the resource is provided.

There can be different layers of security in LDAP:

  1. No authentication: No access is required
  2. Simple : Provide user name and password in plain text
  3. SASL (Simple authentication and security layer): Client and server user security mechanism to exchange username and passwords.

Another layer of security can also be added by using LDAP over SSL. Once the user has logged in, they can have read or read/write access to the resources for which they have been authorized.

KERBEROS

Kerberos is a client/server authentication protocol that uses secret key cryptography to transfer data over the insecure network. (RFC-1420)

Entities involved in the flow:

  1. Client: Someone who initiates communication to access a resource
  2. Server: Hosts the resource the client wants to access
  3. Key Distribution Server: This is the heart of kerberos composed of the following entities
    a. Ticket-Granting Server (TGS): Issues service tickets to access the service resource.
    b. Authentication Server (AS): used to validate the user’s identity and generate the TGT (ticket-granting ticket)

How Kerberos works:

Step 1: The user who wants to access the server initiates the authentication flow by sending the request in plain text. Sample request:

UserId
ServiceId
Time To live
User Ip address

2nd step: The authentication server checks in its database if the user is a valid user. If the user is valid, it finds the database secret key for that user and generates the Ticket Granting Ticket (TGT) with the authentication message. Example TGT message and authenticator:

Ticket Granting Ticket (Encrypted with TGS secret key)
UserId
ServiceId
Time To live
User Ip address
Timestamp
Ticket Granting session key
Authenticator (encrypted with users secret key)
UserId
ServiceId
Time To live
User Ip address
Ticket Granting session key

Step 3: The user receives the TGT and the authenticator. He uses his secret key to decrypt the authentication message to obtain the ticket-granting session key (TGSK). It then creates an authenticator and sends it to the TGS along with the TGT. Authenticator example:

Authenticator (encrypted with Ticket Granting session key)
UserId
ServiceId
Time To live
User Ip address
Ticket Granting session key

Step 4: The TGS then decrypts the authentication messages using the TGSK and the TGT using the ticket-granting secret key. It then uses data from both messages to validate if the messages have not been compromised. Once the validation has passed, TGS generates the service ticket (ST) and creates the authenticator.

Service Ticket(encrypted with the server secret key)
UserId
Timestamp
Timetolive
Server session key
Authenticator (encrypted with Ticket Granting session key)
UserId
ServiceId
Time To live
Server Session key

Step 5: The user receives the ST and authenticator. It uses the previously extracted TGSK to decrypt the authenticator and extract the service session key. The user then generates the user authenticator and sends this authenticator with the ST to the service.

Authenticator (encrypted with Server session key)
UserId
ServiceId
Time To live
Server Session key

Step 6: The service then decrypts the ST using its secret key and extracts the service session key which is then used to extract the data from the authenticator. Once the service authenticates that the user is valid, it generates the service authenticator and decrypts it using the service session key and sends it back to the user. Thus, the service and the user are mutually authenticated.

Features of Kerberos Authentication:

  1. The user does not send passwords over the network.
  2. Encryption keys are also not exchanged over the network.
  3. User and servers can authenticate each other.

SAML (Simple Assertion Markup Language) and SSO (Single Sign-On)

SAML is an open standard for the exchange of authentication data between the identity provider and the service provider in XML-based assertions that allow the service provider to make access control decisions

With the increase in digitization, the user may wish to access various websites on the internet. Now, creating an account on every website is a tedious process for the user. From the perspective of the application handling this authentication mechanism, this will also cause additional overhead. SAML allows the user to use a third-party authentication provider to access various applications without creating an account in individual applications.

Entities involved in SAML

  1. IDP (Identity Provider): Owner of all authentication data
  2. SP (Service Provider): This is the service we need to access.
  3. User Agent: Customer who wishes to access the service.

How SAML works:

  1. The user enters the server/resource URL to access it.
  2. The server checks if the user has a valid authentication token.
  3. If the user does not have the valid token, the server creates a SAML request and sends the request to the IDP.
  4. The user enters credentials and validates. The IDP authenticates the user and generates a SAML response that is digitally signed by the IDP.
  5. The user then attempts to access the resource again using this token. The SP trusts the token signed by the IDP and provides access to the resource to the user.

Thus, the user can access multiple applications/resources without creating a separate account in each of them.

OAUTH (open authorization)

OAuth is an open standard that allows the service to access resources/services hosted by other web applications on behalf of a user. It is an authorization protocol, not an authentication protocol. which focuses on access to resources. Thereby this is a service-to-service authorization standard.

OAuth uses access tokens for resource access control. These access tokens may or may not contain data such as user profile, user roles/permissions, expiration time, resource information, client information, etc. But that access token is the bearer’s token and doesn’t care who owns that token. The only thing that matters is whether the token is valid or not. If the token is valid, access to the resource is provided and otherwise not. This standard does not define any specific format in which the data would be exchanged. The commonly used format for data interchange is JWT.

How OAuth works:

An application says that app1 wants to access a file that belongs to the user and is located on app2.

  1. The user initiates the connection request on app2 via app1.
  2. If the IDP finds that the user is not authenticated, it redirects the user to the login page where the user authenticates and grants permission to access resources.
  3. Now App1 has been granted permission which is used to get the access token for a resource. Here, App1 must be able to prove its identity and has valid authorization to retrieve the access token.
  4. So this token provides access to app1 to access the resource on another service.

NOTNote: The choice of protocol to use may differ depending on the needs of the applications and the infrastructure used.

I hope you enjoyed the article and now have a basic understanding and clarity about the different authentication protocols.

Good reading!

References:

LDAP: https://ldap.com/basic-ldap-concepts

Authentication service with LDAP : https://spring.io/guides/gs/authenticating-ldap/

KerberosName: https://en.wikipedia.org/wiki/Kerberos_(protocol)

Oauth: https://en.wikipedia.org/wiki/OAuth


Source link