2.10 - Authorization Objects - Teradata QueryGrid

Teradata® QueryGrid™ Installation and User Guide

prodname
Teradata QueryGrid
vrm_release
2.10
created_date
September 2019
category
Administration
Configuration
Installation
User Guide
featnum
B035-5991-099K

You can create an authorization object, which stores the credentials for a user in encrypted form for Teradata connectors. Authorization object stores the user's credentials and used in foreign servers to carry these credentials to the remote system for authentication.

If you need one-to-one mapping between a Teradata Database user and a remote user, then you must have corresponding accounts in Teradata Database and the security system.
  • When that user creates the authorization using AS INVOKER TRUSTED, the authorization is stored by default on the user database.
  • The credentials for the security system do not need to be revealed to another person and the authorization object is accessible only to users with privilege to that database.

You can use many-to-one mapping between multiple Teradata Database users and one user on the remote system to simplify administration. Only the creator of the authorization need know the credentials for the user on the remote security system. When the authorization is created using AS DEFINER TRUSTED, the authorization is stored by default in the TD_SERVER_DB database, which makes the authorization available globally.

For a Teradata-to-Presto connection, create an authorization object and use it in the USING clause of the foreign server. Teradata passes the credentials in an authorization object to the Presto connector, then the Presto connector authenticates the user before sending the query to the data source.

Where the Foreign Server Looks for the Authorization Object

When using INVOKER, the authorization is stored in user's database; each user can use their own credentials to log on to the remote system. When a foreign server is configured with the INVOKER keyword and no value is specified for the database name (dbname), Presto or Hive connectors automatically look for the authorization in the user database of the session user.

Using INVOKER

This example creates the remote_presto1 authorization object in the user database of the creator. If the creator is td_user then td_user.remote_presto1 is the fully qualified object name.

create authorization remote_presto1 as invoker trusted 
      user 'active_user' password 'active_pass';

This example creates a foreign server object that uses the remote_presto1 authorization object.

create foreign server Presto_1 
external security invoker trusted remote_presto1 
using
 link('td1_presto1')
 version('active')
DO IMPORT WITH TD_SYSFNLIB.QGInitiatorImport,
DO EXPORT WITH TD_SYSFNLIB.QGInitiatorExport;

The link value of td1_presto1 was created in the QueryGrid portlet. The link defines initiating and target networks, specifies a communications policy that defines rules for transferring data between connectors, and other properties.

When a foreign server is configured with the DEFINER keyword and no value is specified for the database name (dbname), the Teradata connector automatically looks for the authorization in the TD_SERVER_DB database.

Using DEFINER

This example creates the remote_presto1 authorization object.

create authorization td_server_db.remote_presto1 as definer trusted 
      user 'active_proxy_user' password 'active_proxy_pass';

This example creates a foreign server object that uses the remote_presto1 authorization object.

create foreign server Presto_1 
external security definer trusted remote_presto1 
using
 link('td1_presto1')
 version('active')
DO IMPORT WITH TD_SYSFNLIB.QGInitiatorImport,
DO EXPORT WITH TD_SYSFNLIB.QGInitiatorExport;

The link value of td1_presto1 was created in the QueryGrid portlet. The link defines initiating and target networks, specifies a communications policy that defines rules for transferring data between connectors, and other properties.