Does user_identity in system.access.audit reflect the actual logged-in user for Service-Principal-mo

[tetsuro]

We're deploying a Databricks App using Service Principal (SP) mode (not using OBO's user_api_scopes).

The sample query "List app actions performed on behalf of users" in Logging and Monitoring for Databricks Apps shows system.access.audit.user_identity.email commented as "Logged-in user" (the actual person who logged in), with identity_metadata.acting_resource holding the app/SP-side identifier.

My questions:

1. Does this behavior only apply when On-Behalf-Of User Authorization (OBO) is enabled? Or does a pure SP-mode app (without user_api_scopes) also populate user_identity.email with the actual end user's email whenever they interact with the app?
2. The Audit log system table reference documents run_by / run_as fields under identity_metadata — do these also apply to the Databricks Apps SP-mode case specifically?

We need to confirm, for internal compliance purposes, whether individual end users can be identified at the audit-log level, and couldn't find an explicit statement in the official docs covering this exact combination. Any pointers to documentation or real-world behavior would be appreciated.

[binlogreader]

@tetsuro  With app authorization only, the end user does not appear in `system.access.audit` for the calls your app makes. The sample query you found is showing on-behalf-of behavior specifically, and the query itself says, the CTE is named `obo_events`, and it filters on `identity_metadata.acting_resource IS NOT NULL`, a field that only populates when the app acts with a user's forwarded token.

In pure SP mode, every call your app makes authenticates with the SP's client ID and secret, no user identity reaches Databricks, so the audit row shows the SP's application ID in `user_identity.email` and `acting_resource` stays null.

On question 2: `run_by` and `run_as` are documented for contexts where one identity triggers work that executes as another, such as jobs and dedicated group compute. Nothing in the audit log reference ties them to Databricks Apps.

Here are few things to try,

1. Have one user perform a known action in the app, then query `system.access.audit` for that window. Seeing the SP's application ID and a null `acting_resource` gives your compliance file evidence rather than a doc interpretation.

2. Every request forwarded to your app carries the logged-in user's identity in headers (`X-Forwarded-Email`, `X-Forwarded-Preferred-Username`, per the "Access HTTP headers passed to Databricks apps" docs page), so the app can record which user drove which action. 

3. If compliance requires the user in the platform-owned audit trail itself, OBO is the mechanism built for that. Those calls then audit as the user with your app in `acting_resource`, which is exactly the rows the sample query surfaces.

[tetsuro]

@binlogreader 

Thank you very much for the clear and detailed explanation.
This clarifies the distinction between pure SP mode and OBO.

My understanding is that, in pure SP mode without user_api_scopes, all Databricks actions initiated by the app are audited as the service principal. Therefore, the actual logged-in user cannot be identified from system.access.audit alone. In this case, acting_resource remains NULL, and run_by / run_as should not be treated as fields that provide the end-user identity for the Databricks Apps SP-mode scenario.

I also understand that the app can obtain the logged-in user identity from headers such as X-Forwarded-Email and record it in application-owned logs. However, if individual user attribution is required in the platform-owned audit trail, OBO is the appropriate mechanism.

We will perform a controlled test with a known user action and verify the actual records in system.access.audit. Thank you again for the practical guidance.

[emma_s]

Hi, Everything @binlogreader  has commented above is correct, the app service principal will be what appears in the system tables and if you'd like to get individual user authentication you'll need to use OBO authorisation, or pull somthing from the headers, but this would be seperate to the system tables. To give some additional pointers:

- The run as and run by are used for jobs and shared group compute where one identity triggers the work but it's run as another.

- You will be able to extract the user from the headers.  Docs are here: https://learn.microsoft.com/en-us/azure/databricks/dev-tools/databricks-apps/http-headers

There are some nice examples in the docs of the usable headers.

Thanks,

Emma