Credentials for Data Product Queries

When an agent queries a data product with the SQL Execution or Get Data Schema tool, the query runs under some set of credentials on the underlying data source. How those credentials are chosen depends on how the tool is configured and whether your instance has the service account feature enabled.

How credentials are resolved

Here is the resolution order for credentials:

1. The user’s own credentials. If the person running the agent has active credentials for the data source, those are always used — regardless of any other setting. Users add their own credentials from the data product’s chat UI in the Data Marketplace.

2. A shared service account, when the service account feature is enabled, you have set the tool’s auth_mode to datasource_service_account, and ensure a service account is configured on the data source and bound to this specific data product. See steps below for adding a service account.

3. The data source’s default credentials, but only when you have explicitly set allow_fallback_auth to true on the tool.

4. Otherwise, the query fails with:

   No auth ID was provided or configured for data product. Please configure
   credentials for this data product in the Alation catalog or contact your
   administrator.

The right setup depends on whether your instance has the service account feature enabled. If you are not sure, ask your Alation administrator. The two sections below cover each case.

Note

The built-in Data Product Query agent (and agents cloned from it) uses only the user’s own credentials or a shared service account — it never falls back to the data source’s default credentials. Step 3 above applies only when you deliberately set allow_fallback_auth on a tool.

Note

User credentials always take priority. A user who has authenticated to the data source keeps querying as themselves even when a service account or fallback is configured. This is why authenticating individually unblocks a single user even when the shared setup is incomplete.

If the service account feature is enabled

Set up a shared service account so end users can query the data product without each authenticating to the underlying data source. This is a two-part process: configure the service account on the data source, then point the agent’s tools at it.

1. Add a service account to the data source

1. Navigate to the underlying data source for the data product, and open Settings in the right-hand options panel.

2. Go to General Settings > Additional Service Accounts and add a service account to use for querying data. This can be the same service account used for metadata extraction, as long as it carries query-execution permissions.

3. Set App Scope to Data Products. Optionally set Access Control to the specific users and groups who should be able to use the shared credentials.

4. Bind the service account to each data product it should serve. App Scope alone is not enough — the service account is only used for data products it is explicitly bound to. A Server, Source, or Data Product admin can add the binding.

5. Click Test Connection to confirm the credentials work.

Note

The service account resolves only for data products it is explicitly bound to. If a query still fails after enabling the feature and setting auth_mode, confirm the binding to that specific data product exists.

2. Point the agent at the service account

1. Edit the agent and open the Tools section.

2. On the SQL Execution tool (and Get Data Schema, if the agent uses it), open the auth_id options and set auth_mode to datasource_service_account. The tool then uses the service account configured on the data source whenever the user running the agent does not already have their own credentials.

Tip

Apply auth_mode to every data-querying tool the agent uses. If the agent has both SQL Execution and Get Data Schema, configure both — otherwise schema lookups and queries can resolve credentials differently.

If the service account feature is not enabled

Without the service account feature, a query can only run as the user’s own credentials or, when explicitly allowed, the data source’s default credentials. There are two options.

Option A — each user authenticates. The person running the agent adds their own credentials for the data source from the data product’s chat UI in the Data Marketplace. Once they have active credentials, their queries succeed. This is per user: each user must authenticate to each data source they query.

Option B — allow fallback auth. Set allow_fallback_auth to true on the SQL Execution and Get Data Schema tools. Queries then fall back to the data source’s default credentials when the user has none, so end users don’t have to authenticate individually.

1. Confirm the underlying data source has working query credentials configured on it.

2. On the SQL Execution and Get Data Schema tools, set allow_fallback_auth to true.

Troubleshooting

“No auth ID was provided or configured for data product.” The user running the agent has no active credentials, and neither a shared service account nor fallback auth is available to the query. Confirm one of the following is true:

• The user has active credentials for the data source (adding them from the data product’s chat UI gives them their own auth_id).
• The service account feature is enabled, the tool’s auth_mode is datasource_service_account, and the data source has an Additional Service Accounts entry with App Scope set to Data Products that the querying user is allowed to use (check Access Control and Test Connection) and that is bound to this data product.
• The tool has allow_fallback_auth set to true and the data source has working default credentials.

Also confirm the data product’s delivery system still points at a data source with working credentials — a changed connection URI can break the match.

Note

Because user credentials take priority, an agent can appear to work for one person and fail for another: whoever has authenticated resolves their own credentials, while a user who has not relies on the shared service account or fallback being configured.

See also

• SQL Execution Tool
• Get Data Schema Tool
• Configuring tool parameters
• Configuring data warehouse credentials
• Data Product Query agent