You can create an authorization object, which stores the credentials for a user in encrypted form for Teradata connectors. Authorization objects store user credentials and are used in foreign servers to carry these credentials to the remote system for authentication.
- 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 privileges to that database.
You can use many-to-one mapping between multiple Teradata system users and one user on the remote system to simplify administration. Only the creator of the authorization needs 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 to use 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 the database of the user; 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 is 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 is 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.
For more information, see CREATE AUTHORIZATION and REPLACE AUTHORIZATION.