User impersonation#

Trino has to be authenticated when accessing an external service through the connector. Typically it requires passing authentication credentials, which contain information on behalf of what user Trino connects. Such credentials are stored in connector properties file.

Any Trino user accesses the external service as the user configured in the connector properties. This approach has the following downsides:

  • No authorization policies, built-in into this external service, are able to recognize the actual Trino user. As a result any user, who authenticates to Trino and access the data with Trino, has the same permissions and is tracked as the same service user.

  • It is difficult to perform an audit of access of the external service, since every Trino user is seen as the same local user in the external service.

One way of solving this is to impersonate the Trino user as the local user in the external service. With this approach Trino authenticates in the external service using credentials stored in the connector properties file. Once it connects, it informs the external service that any further action in a given session should be performed on behalf of current Trino user. That way a Trino user alice becomes a local user alice in the external service. This requires the user that connects to the external service, which is configured in connector properties file, to be trusted in this system and to be allowed to impersonate other users.

When impersonating Trino users in the external service, Trino itself also requires authentication and proper access control configuration to ensure that users with valid credentials can be authenticated in the external service.

Note that the external service is required to support the impersonation mechanism, and actual details are different depending on the service.

The connectors that support user impersonation as the Trino user are shown in the Starburst connectors overview.

The Hive connector also supports user impersonation when connecting to Hive Metastore or HDFS. However, the Hive connector doesn’t support Trino user to local user translation.

Trino user to local user translation#

The same actual user could be represented differently among services. For example, a Trino user alice_in_presto can be represented in the external service as alice_in_external_service. This requires a translation that details the mapping to use. You can specify the path to the translations file with auth-to-local.config-file in the connector properties file:

auth-to-local.config-file=etc/auth-to-local-rules.json

The config file is specified in JSON format, and contains the rules defining how Trino users are represented in the external service.

Refresh#

By default, when a change is made to the auth-to-local.config-file, Trino must be restarted to load the changes. There is an optional property to refresh the properties without requiring a Trino restart. The refresh period is specified in the connector properties file:

auth-to-local.refresh-period=10m

User translation rules#

These rules control the Trino user name translation to the external service local user name. The local user is calculated by the first matching rule read from top to bottom. If no rule matches, an error is raised. Each rule is composed of the following fields:

  • match (optional): determines if local user should be calculated from Trino user name (USER) or principal (PRINCIPAL). Defaults to USER.

  • pattern (required): regex to match against the value pointed with match.

  • substitution (optional): local user replacement for Trino user.

  • case (optional): determines if result local user should be lowercased (LOWER), upper cassed (UPPER) or case should remain (KEEP). Defaults to KEEP.

For example, if you want to impersonate Trino user alice to access the external system as user alice_in_the_external_system and bob as charlie, you can use the following rules:

{
  "rules": [
    {
      "match": "USER",
      "pattern": "alice",
      "substitution": "alice_in_the_external_system"
    },
    {
      "match": "USER",
      "pattern": "bob",
      "substitution": "charlie"
    }
  ]
}

If you want to impersonate Trino users with principals alice/hr@company.com and charlie/eng@company.com to access the external system as users HR_ALICE and ENG_CHARLIE accordingly, but Trino principals bob/marketing@company.com and danny/marketing@company.com to use marketing_acount, you can use the following rules:

{
  "rules": [
    {
      "match": "PRINCIPAL",
      "pattern": "[^/]+/marketing@company.com",
      "substitution": "marketing_acount"
    },
    {
      "match": "PRINCIPAL",
      "pattern": "([^/]+)/(.+)@company.com",
      "case": "UPPER",
      "substitution": "$2_1"
    }
  ]
}

Username case sensitivity#

User impersonation is case-sensitive by default. As a result, when the Trino user name and identity provider token subjects are in different letter cases, user impersonation may fail or trigger an unwanted mapping rule.

Set the http-server.impersonation.case-sensitive property in config.properties to false, to disable usuername case sensitivity:

http-server.impersonation.case-sensitive=false