Understanding the Connections
When configuring VectorH to work with Apache Knox, three connection points need to be considered: the JDBC Client, the Gateway machine, and the VectorH master node.
The JDBC Client connects to the Gateway machine and from there to the VectorH master node. The user is authenticated on the VectorH master node by using LDAP, like Knox does.
The following illustrates the work flow from the user perspective:
In more detail, the JDBC Client connects to the Data Access Server (GCD) of the Vector Client Runtime running on the Gateway machine.
The Data Access Server (GCD) asks the remote Name Server (GCN) to do the authentication, which means the connection will be forwarded through the local Communications Server (GCC) (also known as the Net Server) to the remote Communications Server (GCC) and from there to the local Name Server (GCN). The Name Server (GCN) calls ingvalidpam, which uses the configured PAM authentication using LDAP to check the credentials.
If the authentication is successful, the Data Access Server (GCD) connects again to the local Communications Server (GCC). The local Communications Server (GCC) connects to the remote Communications Server (GCC) on the VectorH master node. Finally, the Communications Server (GCC) on the VectorH master node connects locally to the DBMS Server.
So there are actually three connections:
1. From the JDBC Client to the Gateway
2. From the Gateway to the VectorH master node to do the (remote) LDAP authentication
3. From the Gateway to the VectorH master node if LDAP authentication was successful
An improved variant of this work flow could be the use of a Bridge Server.
The following illustrates the work flow from a low-level perspective:
