Applies to:
Denodo 8.0
Last modified on: 24 Mar 2021
Tags:
Kerberos
In this document we will provide an introduction to the Kerberos protocol and how the Denodo Platform supports this protocol.
Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos from Greek mythology, the ferocious three-headed guard dog of Hades. Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.
Each head of the three-head dog that guards the gates of the underworld is related to a crucial part of any network security scheme:
Before explaining how Kerberos works, it is necessary to define different concepts:
A Principal is every entity contained within a Kerberos installation: individual users, computers and services running on servers. Principals are globally unique names, so each Kerberos principal is a unique identity to which Kerberos can assign tickets.
Every Principal is divided into 3 parts:
The format of a typical Kerberos principal is <primary>/<instance>@<REALM>.
The Key Distribution Center(KDC) consists on 3 logical components:
Service keys could be stored in the server providing the service in a special file called the keytab. There should be one keytab file for each service offered. Each Kerberized service should run as a different and unique username, and the keytab file for that service should be readable only by that username.
KRB_AS_REQ |
Client Identity |
Client timestamp |
Ticket Granting Server (krbtgt) Principal Name |
Requested lifetime |
KRB_TGS_REQ |
||||
Service Principal |
||||
TGT |
||||
|
||||
Requested lifetime |
KRB_TGS_REP |
|||||||||
User’s copy of session key |
|||||||||
Service principal name |
|||||||||
Ticket lifetime |
|||||||||
|
Notice that KDC does not specify policy on what principals are authorized to access a given service. The KDC will ensure the validity of the TGT sent by the client and then will issue a ticket for any service that it knows about, but authorization decisions are made by the individual application servers. The possession of a valid service ticket for a given service does not imply that the user should be granted access to that service.
Kerberos authentication can be configured for different servers and tools in the Denodo Platform.
In this case, the Virtual DataPort Server and the Virtual DataPort Administration Tool have to be configured to use Kerberos. The Virtual DataPort Server is the Kerberized Service and the Virtual DataPort Administration Tool is the Client.
There would be a similar situation when configuring the Data Catalog or the Design Studio for using Kerberos Single Sign On. In this case, the client would be the web browser, and each one of the Web Administration Tools would be a Kerberized Service. Also, the Virtual DataPort Server will be the Kerberized service for the Data Catalog or the Design Studio.
In the case of Scheduler, the web browser would be the client for the Scheduler Web Administration Tool, and the Scheduler Web Administration Tool would be the client for the Scheduler Server.
Kerberizing Denodo for SSO - Step by step guide
Kerberos Authentication with the Active Directory
Kerberos configuration and troubleshooting