Who Goes There? Enterprise Auth and Identity Management on Databricks Apps

Summary

As Databricks Apps move from prototypes to production, they must implement sophisticated identity management patterns including OAuth-based authentication, On-Behalf-Of (OBO) tokens for user-scoped downstream access, and service principal delegation for backend calls.
This video introduces three authorization patterns—app authorization using a service principal, OBO for user-scoped access to data and Genie, and model-specific authorization—and a decision framework for choosing the right pattern for each downstream call.
Advanced security hardening features covered include managed credentials for eliminating long-lived passwords, short-lived credential rotation, private endpoint connectivity, and dedicated network namespaces for total environment isolation.

Who Goes There? Enterprise Auth and Identity Management on Databricks Apps

For an application to move from a prototype to a core business asset, it must meet the highest standards of enterprise security and compliance. this video explores the advanced security architecture of Databricks Apps, demonstrating how it inherits and extends the robust governance of the Data Intelligence Platform. We will move beyond basic access to explore sophisticated identity management patterns, including On-Behalf-Of (OBO) authentication for user-scoped actions and secure compute resource delegation. You will also learn how the platform is hardening the application lifecycle with features like automated secret rotation and dedicated network namespaces to ensure total isolation. Whether you are handling sensitive PII or building internal tools for thousands of users, this video provides the blueprint for building apps that are secure by design, fully audited, and ready for the most regulated environments.
Talk By: Wenxin Liu, Specialist Solutions Architect, Databricks ;

Chapters

FAQs

What is On-Behalf-Of (OBO) authentication in Databricks Apps?

On-Behalf-Of (OBO) authentication allows a Databricks App to make downstream API calls using the identity of the currently logged-in user rather than a shared service principal. This ensures that data access respects the individual user's Unity Catalog permissions, maintaining row-level security and audit trails even when the app mediates the request.

When should a Databricks App use app authorization versus OBO?

App authorization—where a service principal acts as the identity for all backend calls—is appropriate for operations that are not sensitive to which user is making the request, such as reading shared reference data. OBO is required when downstream data access must respect individual user permissions, such as querying personal data or resources with row-level security applied.

What are managed credentials and why do they matter for Databricks Apps security?

Managed credentials are a Databricks platform feature that eliminates long-lived passwords and static secrets by automatically rotating short-lived credentials for the app. This removes the security risk of hardcoded or long-lived secrets in application code, which is one of the most common sources of credential exposure in production applications.

How does the authentication architecture of Databricks Apps protect production workloads?

Databricks Apps use a proxy architecture with private endpoints and OAuth-based authentication to ensure all requests are authenticated before reaching the application runtime. Combined with dedicated network namespaces for isolation and a token claims system that surfaces user identity to the application code, the architecture provides a defense-in-depth approach to enterprise app security.

Full transcript

[00:08] Good afternoon everyone and welcome. Thanks for joining this session on Thursday afternoon with me. So my name is Winshin Leo. I'm a senior specialist solutions architect on our infrastructure and AI tooling team. So
[00:20] our session today is about the enterprise authentication and identity management for databicks apps. So let's start with a moment that almost every successful internal app eventually hit.
[00:34] So when we first start building an app, it usually starts small. Usually it's a prototype, maybe it's a quick demo, maybe it's something one team just want to build and move faster and then over
[00:48] time it becomes real, which means now real user depends on it. real data flew through it and the app now has to meet the same security compliance and audit
[01:01] expectation as many other um production system. So at that moment those question will become important who goes there who is making the request who is authorizing
[01:13] it and how can we prove it. So those are the question this session is built around and this is the path for this session because this is a intermediate level
[01:25] technical talk. So my goal is not turn this into a deep code review or a full system design tear down. My goal is to give you a clear mental model and enough details to choose the right pattern for
[01:39] your own data apps. So we will move into four parts. So first we'll frame the enterprise identity problem. Why the question changes when app moves from prototype to production. Second we will
[01:53] also cover the authentication the app's front door who gets into the app and how the request eventually hit your code. And third we will spend most of our time
[02:05] on authorization. This is also the core of this session uh the app authorization versus user authorization. And lastly, we'll make it concrete with a live demo and close with some supporting control
[02:17] around secret networking and audit. By the end of the session, I hope you will have a better clear understanding on what authorization lane is for, when to
[02:29] use it, and how to combine them into an enterprisegrade uh data bricks app. Okay. So, first I want to start with why this matter. So when you're building a
[02:41] prototype, the question is always very simple to your app is can it work? Can the app reach the data it needs to access? Can it call the API or can it produce the outputs that will make the
[02:55] business say okay this is helpful but in that phase the fastest path is often to wire everything through one powerful identity. So maybe that's the app service principle to all the downstream
[03:07] access because your team just need a download to work asap. So that may be acceptable u okay for pro uh for proving your idea in a lower environment but
[03:19] it's not enough once it become production. So once the app handles real user and real data the question changed from can it work to who acted who authorized it
[03:31] and how can we prove it. So imagine we got a healthy care tracking app a billing app or a customer support app that sit on top of your sensitive customer data or PII everything go
[03:44] through one share identity and then we will not be able to answer the following question. So for example like who read this data in last two week who triggered the reason data drift alert or did this
[03:57] user change anything before he moved or left the team. So the same service if if we just use one app's identity then it will be the same service principle read the data it
[04:11] will be show as the same identity make the call trigger alerts. So that does not only weaken our audit uh story, it just erase it. So the problem we are
[04:23] trying to solve is not only how do we manage authentication, the deeper question or the problem we're trying to solve is how we preserve a clear identity and clear authority all the way
[04:36] through the downstream call. So to answer those concern, let's start with authentication. The authentication is the front door. It answers the question who is allowed to use this app.
[04:49] So on this slide I want to talk about the two parts. One is identity and second is the network. So for the identanity um the user signs into the workspace and if your user use single sign on SSO the
[05:04] workspace login is protected by the identity provider that configured with the workspace or on account level. So that proves who the user is. Second is the network. So you can also decide how
[05:18] the user or the API reach to the workspace and app. So one option is the public route where the user reach to the workspace and app through a publicly
[05:30] reachable URL. If you use that route also remember you put the right IP access control list or some context based ingress rule to protect the only approved traffic can reach to your app.
[05:43] So the other option you guys may know is the private route using the front-end private link it also know like known or list as a private link on the cloud provider and our documents. So in that
[05:56] mode the user will reach the workspace and app through the private endpoint that provided by your cloud provider instead of using the public routing. So either way after that the user is
[06:10] authenticated and can reach to the workspace and app. So the datab will route request to the um app runtime after that. So next let's
[06:22] zoom in on what data app does before the request even head to your application code. So I want to go a little one layer deeper um by using this sl to show what
[06:36] happens during the signin authentication handshake. So the important thing to notice is that this happens before your application code runs. So when a user
[06:48] opens the app, the browser sends a request to the URL, the URL contains the app name, the workspace identifier and the cloud specific domain pattern where
[07:00] the app is running. So it may be slight different if you're using um as based or GCB based uh workspace. So if there's no valid session, the databicks reverse proxy in the control plan intercepts the
[07:14] request. So for a browser call it will redirect to the sign in flow with HTTP 302 and if it's a API call it will return with an 401 unauthorized
[07:27] response. So either way in that case your app code will not receive any unauthenticated request. So next if the user sign in through the workspace identity provider correctly such as
[07:40] Entra Octa or Google Workspace behind the scenes databicks use a standard OIDC flow with PKC as an extra protection. So
[07:52] that will happen during the signing exchange. So the point I'm not trying to focus on the protocol detail but it's just want to tell you databri validates results and turn this into a trust
[08:06] browser session. So the session is what the platform will validate on every request uh which we will also use in the next slide. So there are also two takeaways here. So one is
[08:20] the proxy is the trust boundary. Authentication is enforced before the traffic reached app runtime. Second, the browser is using a session cookie. So
[08:33] the app doesn't have to assume the user token is always present in every request. A user access token will be routed to the app only when the user
[08:45] authorization is enabled for that app and also for that selected scope. So by the end of the request reach to the app it also like already is already coming through the authenticated platform
[08:58] permission. Okay. So now we will look at what happens on every request after this session is established. So after login completes, the browser
[09:11] includes the data um the databicks session cookie on each request and the databicks app's front end reverse proxy will validate the session and it will check whether the signing user has can
[09:25] use or can manage UC permission on that and then route the traffic based on the app's host name. So before that request reach to the container of the app the
[09:38] platform will ingest trust identity provider uh uh sorry trust identity header um in the u uh session. So those header include like we mentioned here
[09:51] like such as the user's email, user ID, preferred username um and you can see that in the code by like grabbing them out from the runtime if you want. You can see those um through the header like
[10:05] X forwarded email, X forwarded user, X forwarded preferred username and if your app has the user authorization enabled,
[10:17] the control plan will forward user access token through the X forwarded access token header. One thing to note is that the control plan will strip the
[10:30] client supplied copies and injects the trust value itself. That's something I want to call out because think about if a user or a caller try to spoof a X forwarded email because like they try to
[10:44] pretend someone else that caller provided value will be removed before it reach to the app. So that's why your app can trust those headers and the value
[10:56] inside platform boundary because it's not trusting what the user is provided uh but it's trusting what the platform has validated and give it to you. So that completes the authentication
[11:09] baseline. So now think about our app has enough identity context to choose right authorization lane for each downstream call.
[11:21] So let me just quick pause here and summarize the first half right. So the authentication answers who sign in and authorization answers what request uh is allowed to do downstream actions and
[11:36] common model we may have is like the app choose one identity when it starts and everything run through that identity but that's not the model I want to introduce or mention here because with datrix apps
[11:49] the um authorization pattern can be choosed when the app may make each downstream call. So one call can run as the app itself and the other call can run as the signin user. Those call can
[12:03] come from the same app and even from the same continue workflow. So that's the key idea. So not one identity per app but the right identity per call. So we
[12:16] will use our rest of the session to unpack to show like when to use which authorization line and how to use them together. Okay. So datrix app now give us two
[12:29] complimentary identity model or identity like authorization lanes. So on the left is the app authorization. So the app has its own dedicated service principle when
[12:41] it was created and data bricks evaluates that service principle permission independently from any user using that app. So on the right hand side is the user authorization also called on behalf
[12:55] of or or we just simply called OBO. In that lane app use sign in users access token for downstream database call and database evaluate that call through the
[13:07] user's existing permission. So the important point is that those are not different maturity levels right so user authorization is not automatically more
[13:19] secure and apps authorization is just not simply a basic version of OBO. They answer different authority questions.
[13:31] The next two slide I want to go a little deeper uh into the contract of each lane. What it gives you, what does not give to you and what can go wrong if you pick the wrong one. And then we'll
[13:43] combine them into a decision rule. So let's start with the first app authorization. So this is where app act as itself. So databicks creates a dedicated service
[13:55] principle when the app is created and the identity is unique to each app instance and it is identity databicks use when the app access other resources and for some app user you may know like
[14:09] some case let's say oh I accidentally delete the service principle somehow like Batman admin then your app lost that service principle the cricket way is you just redeploy a new app which will come with a new service principle
[14:22] so we will use This line when the work belong to the application not the individual user. The common example we can think about are usually is a background task or some shared
[14:35] configuration usage logging operational rights or some cost to the external service through the proof endpoint because usually those are evaluated based on the apps its own permission.
[14:48] The key rule here I want to mention is explicitly grant only. So the app service principle does not get broad access just because it attached to that app. It needs to be grant to each
[15:02] downstream resource. For example, if it need to uh use a SQL warehouse, it need SQL warehouse permission. If you need to read a table, it need table permission. Ne genie, you need to grant genie permission as well. So at runtime the
[15:17] databicks will supplies the app's identity through the environment variable such as databris_client id data client um underscoreclient secret in the environment. So if you use
[15:29] driix SDK for instance your SDK can pick those value up through the uh unified au authentication and you don't have to hardcode any of those value in your source code and also we need to note if
[15:44] we use this authorization um pattern it will not give you user level access data control. So for the downstream call like user share the permission when they log
[15:56] into that app and that's exactly you want for some of your application operations. But if you want something like user A and user B see different
[16:08] rows on the same table or see different columns that's not right pattern that you want to pick. So the app service principle is not a shortcut around the governance. is just a separate explicit
[16:23] uh application identity. So let's use it when the work is app owned and do not use it to flatten your users's specific data access.
[16:36] So the second is the OBO user authorization. So on the contract we use this when the operation or downstream results should be depend on who click
[16:48] the button on the app. So a simple example right a governor data access two user user A user B they open the same app they run the same query but they should not see the same row or same set
[17:02] and column uh because they belongs to different region or belongs to different team. So with OBO because we fill the user's own access token so we will be
[17:14] able to evaluate users permission on the unity catalog um when they hit the table API calls. So that's something like the OBO can
[17:26] provide but also to keep in mind that like OBO is not a blend check. So there are three control you need to keep in mind right. So first when we use OBO or
[17:39] on behalf uh of users authorization pattern the user also need to have the permission on the target results the on behalf of or the OBO does not grant users um something that the user does
[17:53] not already have access. Second the app must select the right user authorization um scope. So for example if an app uh if an app need to query the SQL warehouse
[18:06] on behalf of the user it need a SQL scope when we configure the app. If you need a genie access it need to select the genie scope. So if those scope were not selected even the user is themsel
[18:20] has a permission they cannot run those action when they use those app. And the third one is the consent and or we call the workspace admin control because with
[18:32] a recent release we have a feature to control what type or which scope you can enable on your app. So you can make a a very broad selection or you can only give two or three option so that your
[18:47] app can only make those call through certain scope. I will show that in our demo later. Right. So at the end at the runtime when this enabled the user token will be available through the x
[19:00] forwarded access token and we want to treat that token as a sensitive data and we don't want to print it we don't want to just log it or write to some like random files uh or we don't want to put
[19:13] them in error message right so we can pass them directly through the like databri SDK or the connector that we support for the downstream
[19:26] So now let's combine them and combine those two line into a production decision rule. Right? So I want to make this as more straightforward as I can. So I want to say just choose by the access pattern.
[19:39] Right? There's no simple ranking. So for each downstream call I will ask the f those question to myself like first should the result vary by the user if
[19:52] yes I want to use OBO that's the right lane for the governant data read like that's also the right option if I want to do some user scoped user scoped genie
[20:05] uh workspace access or there's some user scoped SQL queries and those actions Um the unity catalog will check and evaluate based on what user who actually
[20:19] click those uh button on my app. Second uh is this something related to a share state or is related to the app's own uh metadata or own work? If yes, we will
[20:34] use apps service principle. Uh the third one is does this action need to run without user presenting or even user need to like be there to make this action. If yes, this is another signal
[20:47] for um app authorization, right? Because OBO depends on signing users contacts. So the background work and the schedule work should not depend on any user or
[21:00] browser session. Uh that's why we will choose OBO in that case. And the fourth question I will ask is what should the audit log or audit trial to prove later if I need to do some forance do some
[21:14] analy uh analytic um analyze or just trying to find out what happened. So if the question is like who or which user view the governed data we choose OBO and
[21:26] if the question is like did the application actually write or trigger um database workflow then I think the app authorization will be the better option for that call.
[21:38] So overall I think in the real production there's always something like you can use both. So for example in one continue action we can use read data as
[21:54] the signing user with user's authorization but then write the state or the app's configuration or information to a lake base as the app itself. So the is each downstream call
[22:08] like I choose different um authorization line in that case. So if we put this in a high level model in one picture right so a user enters
[22:20] the app through the workspace endpoint then the app has two access path available top is for work that should follow the signin user um the governant data access genie access or maybe
[22:33] calling the model serving endpoint anything where the answer should change based on who clicked the bottom path is for the work belongs to the app. So the app state
[22:46] configuration or job triggering or some resource explicitly grant to the app service principle itself. So when we review or design those apps, do not
[22:58] label that app, your own app as a simple OBO app or just um app authorization app like work through the workflow and label
[23:10] each downstream call um based on your judgment and your use case. So that's what we design per call not per admins. So in the later demo I will show the
[23:23] scenario I just mentioned. So I want to read the governant data through the user path and then write uh something into uh lakebased through the apps authorization.
[23:35] So yeah let's start um uh the demo. So before uh we switch the screen I just want to quickly um explain this uh demo
[23:48] code. It is a small webcoded app and it was intentionally to be simple. I just want to show the different authorization lane and uh we have um when we design
[24:00] this we have um two regional view for one table. So I want to show for example Alex is in north region and Bob is in source region. So when those two user
[24:12] trying to read a table um they should see different results because uh we have the um row level filtering based on the region and also like we have some uh
[24:26] column mask that will show how we can implement those authorization and the validation in the code. So let me switch to the demo. Right. So,
[24:40] so first we can see um this is my app the risk explorer and once we open this um app we see this uh simple app
[24:53] with three main section so one uh the first one is we want to verify the read data through different identity so because I signing as myself um I don't want to use another like non-exist user
[25:06] so I pretend this app as another user and you can see those two part from on the left hand side. Myself as a signing user can
[25:18] only see the region uh I only see the results from the north region and the app can only see the results from the source region. And
[25:30] the context behind this is I have this demo synthetic data uh created and stored in this table. And we if we take a quick look you can see there is a
[25:42] column mask on SSN to showcase for some sensitive data we want to mask some users uh sensitive information. So in this demo, we will hide part of the um
[25:57] SSN from the results, right? So nobody can see the full SSN in this demo. And this is the um simple SSM mask that we created for this demo. And back to
[26:11] the um table itself, we scroll down a little bit. We can also see uh say there see there is a row filter and there's a function that will handle um the filtering based on a simple function is
[26:26] let's don't just dive the code too deep but in a summary it will check okay a user can only see the data that has the same region information with that user
[26:41] right so if I'm in the west region I can't see anything outside west region. So that's why if we click sample data I should only see like like the
[26:54] the right course that's belongs to the same region that I belongs to. If I just compare this is the region map winshin belongs to north. So I can only see the data in north and I can't see the data
[27:07] in the source uh source. So that's how we want to showcase the authorization lane here. And there's another like test is I run a query
[27:20] behind the scene. So if I want to use apps service principle and permission to access data that does not belongs to this identity. So I try to access data
[27:32] in the north. I got error message directly from UC because UC directly evaluate the data access and return sorry you can't access. So with this design you don't have to write extra
[27:46] code to manage your data access because you just get identity and let the database Unity catalog to manage and verify the access for you. So that's
[27:58] another um thing I want to mention in this demo. And the second part is the hybrid action which is we read the data as a user
[28:10] which is myself and then we want to write something into a database which will be a lake based um and just to showcase we read as a user and we write
[28:22] as a app. So if I click and uh let's quickly show what we have in this lakebased database. So
[28:45] We have one schema designed for this and right now we have six records and this is done previously for testing and demo and the most recent one was yesterday and if I try to escalate I will just
[28:59] simulate escalation u record write to the database and it will write by the app's role. So, we see a successful ride on the app. And if we refresh the
[29:11] database, I'm hoping to see a new record, the seventh one. Yes. So, this is the latest one we just made. And it is written by the uh app service principle. We can
[29:25] quickly verify this string by checking the same um apps configuration from here. So from environment we can see this is the same
[29:38] client ID of this app. So that's the second part I want to demo and the last part is the uh modeling part right. So with all
[29:50] those two lane identity um setup authorization um pattern we we have chosen the the goal we or the problem we'll solve is maybe later something happened
[30:03] or I just want to do a like basic observerility or just what understand what happened. So we want to understand who made reason call like is it made by a user or is made by um the app itself.
[30:18] So we can query the data uh databicks audit log to see what happened. So we can use this app to trigger a SQL warehouse and this warehouse going to
[30:30] use the following query to select the most recent action happened to that table um that belongs to either myself or the app. So this may take a while but
[30:44] um eventually we're going to see some um records coming back something like this. So we can see the get table call that we can see who made this call is myself
[30:57] when it happened is the uh UTC time and what is the target. So I just also um access the claim north table and um for
[31:09] the apps there's a generate temporary temporary table credential. So this is also an action you can use to identify uh if application try to retrieve a temporary token and then use for read
[31:23] purpose. So okay the finish is the this recall and this is just an example I uh get from the audio log results and of course
[31:35] you can get even more detail if you just pull and display all the results you you query from the audio log. So that's the small demo application I want to show and before and u
[31:49] before we jump to the slide I want to also want to show you some configuration that for this app. So if we check the configuration we can see in order to let the app to
[32:04] use some downstream resource as the app itself which is the app authorization we have to explicitly grant those resource from the resource tab here right so we
[32:18] already have the SQL configured here which means this app can use this SQL warehouse to do some query and we also have the database access permission to allow us to connect and read and write
[32:32] data back. So think about if you need some um action to your genie space, you also need to add genie space here. Without this setup, your app will not have permission to make any call to your
[32:46] genie space. So with this permission box, you can select more granular um options. You can choose the one you need. This is for the apps authorization which
[33:00] will grant the app also is a service principle access to the downstream resource. And I also want to show the user authorization like I mentioned here. Right? So right now because for
[33:12] this demo we just need to uh showcase the SQL uh query. So we only have a SQL scope and again if we want to access Genie I want to add some new features
[33:24] then we need to add the Genie scope or Postgress database um scope we don't have the you may think like why we don't have the um the Postgress um right now
[33:37] because the right operation I just showed is made through the app itself. So we are not using any user authorization to make that request uh to the uh lakebase. So that's why
[33:49] everything happens smoothly without any error. Right? And one more thing I want to show here right you right now you can see three um scope options and that's the workspace
[34:03] admin consent I mentioned earlier because as a workspace admin you can control what scopes are available to all the app in the workspace that's something you want to remember if you
[34:16] own this environment or you want to provision or you want to provide this workspace to your other team. So if we go to the settings as an admin you can see the development tab and from here
[34:30] there is a app section. So from here you can see this option restrict all scope for the apps to select values. So that's why we only see a narrow option that I
[34:42] just show there because I on purposely only select three to showcase this. But if this is a lower environment or there's even a like environment you want your team can do all the API on their
[34:56] app you can select all and we can go back and see what happened after that. So after we change it we go back to the
[35:15] app configuration and let's pull this option again. Oops. Let me refresh. Now you can see all the other actions and scopes you can choose for your app.
[35:27] So as again like as an admin you can restrict the maximum scope an app builder or app team can build in this workspace. This can be helpful if you want to restrict certain action for this
[35:40] OBO.
[35:54] uh presentation. Okay. So we spent most of the the time right and to talk about identity and authority. So I also want to cover quickly some controls wrapped around on top of it. So the first is the
[36:08] secret right. So the design principle is simple. keep the secret value out of your code. So do not put in a plan configuration or some thing like people can quickly like your team can actually
[36:21] extend uh so expose it by mistake right and also for the app's own identity databris manage the service principle and supply them into the runtime so you
[36:33] don't need to print out this secret or the client ID in your code you can just directly load them from the app environment and feed them authenticated through the SDK. So for other secret
[36:48] outside data apps or data service principle, we also have data secret resource and you can ref reference
[37:01] remember we have in the apps configuration. You can also select the secret you want to use and grant your app permission to access the certain value in that secret. That means you can
[37:13] use value from instead of pasting literally a plan text or token in your code. And also when you integrate uh some application or tools that support
[37:25] shortlive credential definitely prefer that over the long lived static password. I think lakebase in this examp is a good example um here because we are using the ooth which is
[37:38] the shortlive credential uh rather than we just storing a static long living password in our app or in our secret. So the result is less secret material to
[37:52] handle and less rotate inside application code. So we will have fewer place um to leak any sensitive data.
[38:05] And the second supporting control is the networking. So there are two sides think about networking ingress and egress. So for ingress decide how user read app. So this can be done through a public app uh
[38:17] URL. Um but you want to put like IP access list on top of it or you want to hide them behind your VPN or CP network through a p private endpoint connectivity. And for the egress
[38:31] you can choose and control where the app is allowed to connect. So we do have network policy and network configuration uh network connectivity configuration
[38:43] which let you to control outbound traffic to some trusted public IP or we also provide private link for egress to allow your app directly connect from
[38:56] datrix runtime to your like on-prem through the um um cloud provider uh private link um solution.
[39:11] So the third one I want to mention is the um life cycle handling right so you want to use reviewable deployment path for example you can use our newly released git based deployment if it's
[39:23] possible and keep your CI/CD control in the loop so you can involve code review dependency scanning or static analytics and uh release approval in the entire
[39:35] life's uh cycle to keep your app in a secure state. So the identity is the central of this talk but we all know the production
[39:47] u production posture is a bigger picture than just identity. The bigger picture here will be identity with security um secrets networking and life cycle
[40:00] control working together. So I hope this is the pattern like take back to your own app. So you want to use OBO for governant user action where the
[40:13] result should depend on who clicked and in that lane the Unity catalog will continue to enforce the user permission such as user table access uh or even the more specific row filters or the column
[40:27] mask I just showed. And you want to use app service principle for the app's own work such as like share stays trigger schedule job. So the work belongs to the
[40:39] application itself instead of any individual user. And in your real app you may also expect to use them both together. So it's a choice to made per
[40:51] call but not per app or per section. Right? So finally remember to use the audit log that we provide in the UC as the evidence. So it should show who act
[41:04] which app was involved and which resource was accessed and which authority was used. So that's the security by design in practice. So we want a clear identity, explicit
[41:18] authority and the evidence you can stand behind. So that bring us to the end. So thank you for your time spending uh this afternoon with me. And the QR code here
[41:32] will point to that sample code I just used for this demo. So feel free to poke around and you can try that in your own testing environment and we can
[41:45] uh use the rest of time for um questions but I think we ran out of time but I will be here so feel free to come here and uh ask any questions if you have again thank you and I hope you enjoy the rest of the day.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.