Using Identity Security With Unity Catalog for Faster, Safer Data Access

Summary

• Secure Authentication: This video covers best practices for managing authentication effectively, including token visibility, MFA/SSO and secure CI/CD token federation.
• Access Token Management: Learn strategies to minimize token risk through TTL limits, scoped tokens and network policies on the Databricks Data and AI platform.
• Maturity Framework: Discover an authentication maturity journey from basic security practices to advanced protections for enterprise-grade data access governance.

Using Identity Security With Unity Catalog for Faster, Safer Data Access

Talk by Kelly Albano, Senior Product Marketing Manager, Databricks ; Siddharth Bhai, Product Management, Databricks
Managing authentication effectively is key to securing your data platform. In this video, we’ll explore best practices from Databricks for overcoming authentication challenges, including token visibility, MFA/SSO, CI/CD token federation and risk containment. Discover how to map your authentication maturity journey while maximizing security ROI. We'll showcase new capabilities like access token reports for improved visibility, streamlined MFA implementation and secure SSO with token federation. Learn strategies to minimize token risk through TTL limits, scoped tokens and network policies. You'll walk away with actionable insights to enhance your authentication practices and strengthen platform security on Databricks.
Here’s more to explore:
Unified and open governance for data and AI: https://www.databricks.com/product/unity-catalog
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

What is the authentication maturity model?

It's a framework for advancing from basic authentication practices to mature security, including MFA, SSO and token federation.

How can I reduce token risk?

Use TTL (time-to-live) limits, scoped tokens that restrict permissions and network policies to minimize exposure of authentication credentials.

Who provides secure identity and access management in the era of AI?

In the era of AI, secure identity and access management has become critical to protecting data from unauthorized access and theft. This video discusses how identity security tools integrate with data platforms to enforce fine-grained access controls, detect anomalies, and respond to threats in real time. On the Databricks Data and AI platform, Unity Catalog combined with robust identity security creates a comprehensive defense against data breach threats while enabling safe data democratization.

How does an AI gateway integrate with identity and access management?

An AI gateway integrates with identity and access management by acting as a policy enforcement layer that intercepts data requests and validates permissions before granting access. This video demonstrates how this integration prevents unauthorized users from accessing sensitive data even when they attempt to exploit AI systems or application interfaces. By combining authentication, authorization, and threat detection at the gateway level, organizations can safely expose AI capabilities while maintaining strict data governance and compliance.

Full transcript

Remember one year ago today, it was June 10th, 2024, Google Mandant put out a blog detailing some threat intelligence about some customer database instances that were targeted towards data theft. This these were customers of another well-known data platform in the industry and it really set the precedence for our identity and security team's roadmap over this past year. They've been working super hard and we're really excited to talk about some of the things that the team's been up to and what's coming soon.
I'm on the product marketing team here at Data Bricks focused on all things security, compliance, identity, and unity catalog. I'm joined here by one of our identity leaders here at Data Brick. , you've spoken on this topic at Summit how many years now? Yeah, this is super exciting. It's my fourth data and AI summit and I see a few familiar faces in the audience. We'll have more new things to talk about. Yeah. Has anyone been to SID sessions the last couple years?
A couple people here and there. Awesome. Um, well, we are very excited to be here today. Before we jump in, you're going to see this slide a lot as you attend the sessions. Forward-looking statements, make decisions um on your usage of data bricks based on what's available, not future and forward-looking things we have going on. Okay. So, outline of today's session, we'll talk about things that have been on data bricks for a while when it comes to identity and access management.
Probably some features you've heard about, but we've been iterating on them in the past year. We'll talk about how some of the things we put into the platform, you know, over the past year that since, you know, the incident that happened a little a year ago today. And then we'll also talk about what's what's coming soon. And we'll orient this around what we're calling an authentication maturity model to get you all from very basic authentication principles and practices on data bricks to something very mature and secure that our most security conscious customers are pushing us to build into the platform that we did.
So identity sprawl is real. We're hearing from customers all the time. There's things like personal access token proliferation, scattered dashboards, multiple applications, still dealing with passwords. Identity is the weakest point in your security posture. And we want to make sure that you're not in the news. And we want to make sure that we're not in the news with you. And this isn't just marketing speak. There's because of all the news articles in the last year.
There's been a lot of research done by leading analyst firms and security companies. Um, identity is where data breaches begin. A lot of them are due to stolen identity and privilege access credentials. A lot of companies are facing two or more identity related breaches. Um, and so this is definitely a reality. You're going to hear a lot about Unity Catalog this week. You know, it's the data governance layer of data bricks.
It's our catalog solution, but really the underpinning part of UC is identity. I mean, is working with he's on the same team as all of our UC product management, UC engineering teams. It's all one big happy family here. And really, you know, at the end of the day, UC has awesome access management controls, data sharing, lineage, auditing, great reporting, and observability. And underpinning all of this is identity. So moving on to our authentication maturity model to kind of frame up what we'll outline in this session.
Where does your organization sit? We have three different um tiers that we've put customers into buckets. Basic, professional, and cutting edge. We've outlined it across a couple planes here when it comes to user login um access into the platform and also admin and monitoring tools. So at a high level basic not as secure not a great place to be probably using username and passwords having long-term access tokens that don't expire not a lot of visibility and controls.
Professional now you're probably moving into multiffactor authentication. You have temporary tokens that have shorter lived expiration dates and some level of access monitoring. We're seeing B+. We want to get you all here to cutting edge and we have the tools to do so now built into data bricks. Easy secure signin across all tools whether it be PowerBI, Tableau, what have you. access that is automatic and having the right monitoring tools in place so you're managing authentication having full visibility into who's doing what on the data bricks platform who here is thinks they're on basic raise hands okay good professional majority of the room anyone at cutting edge we know some of you are some of you've been working directly with SID and team no one by the end of the session with hopefully everyone All right.
Okay. Awesome. Now to roll this back, we'll now we'll now talk about this in the lens of data bricks and what we have available to you. First, starting with user login with passwords, which we do not allow anymore. So, back in July, we got rid of username and password login to authenticate into data bricks UI or the API. And you have a couple options. So, at default, if you didn't do anything, there's a one-time password that are now sent via email for Google and Microsoft login.
What we do recommend instead is that you configure signin options with your Google signin or your Microsoft Entra ID signin. There's also other options which we'll get into in just a moment. So just getting people to not use passwords and turning that off, you know, making sure that we're just creating that secure baseline so you're not um the villain to yourself. That's great. But now let's move into multiffactor authentication.
Just a couple weeks ago, we announced the general availability of what we're calling data bricks manage MFA. And what that is is this is for AWS accounts with no single sign on available. And it allows admins to either recommend or require multiffactor authentication to log into data bricks with all the typical ways that you can. So authenticator apps, pass keys, hardware keys like Ubi key that's managed from the account um admin center.
And what we do recommend is you set this to required and not recommended. Now we'll do just a very quick demo on what this looks like. It's super easy to enable. So this will be from the account admin perspective in the account console of data bricks. So you'll navigate over to settings and then into authentication. We have a new section here called multiffactor authentication via datab bricks. So data bricks manage MFA was recommended.
We're setting that now to required. And now you'll probably want to see which users actually have MFA enabled already. So we have a new user management dashboard. Of course, our identity expert here, has already enabled MFA. Um, awesome. I do not, and it was probably because maybe I lost my Ubi key or I kept hitting snooze when I was prompted for MFA. But now that it's required, the next time that I try log into datab bricks, I will be required to set up multiffactor authentication.
Super easy. Awesome. So, let's keep going. Cutting edge user logins. Let's bring the identity expert up here. Over to you. Thank you. So, a lot of you probably have your own identity providers. ID says use this for single sign on for everything. What's new? Few years ago, we used to have this model where you had single sign on configured from each workspace to your identity provider. The visual on your right, sorry, on your left is going to show you have single sign on configured at the account level now and it just automatically applies to all the workspaces.
Now, why is this a good idea? First, it's just simpler for the admins. I mean, who wants to have a round trip with the IT team? I get to work in my role. very fortunate that I get to work with dozens, hundreds of customers. One of the customers told me two years ago, it used to take them two and a half months to get a new workspace spun up and provisioned with IT and authorized. You've cut that time down. And if it's on unified login, all the new workspaces, they're just born secure.
They have single sign on protection from the get- go. Second, over the course of the week, you're going to be hearing a lot of amazing innovations by my colleagues in R&D and a lot of those newer features work simplest and best when you have a single accountwide configuration. Say you created a new AIB dashboard. We're going to be talking about apps on on data bricks. You can just go ahead and share these easily and seamlessly with users in your companies who maybe are not active workspace users if you're on unified login.
And at the end of the day, a lot of you are admins for your teams and data bricks. Let's face it, happier users, less troubleshooting. It simplifies your lives, too. Now, as I mentioned, over the last couple of years, I've had the pleasure of working with literally hundreds of folks, customers, and our field organizations supporting you all. And there are three questions that come up most often. So, I thought I'd give you the cheat sheet and just lay them out very quickly.
First, giving somebody access to the account level single sign on doesn't give them the ability to manage the account. I see a few heads nodding. Great. You all know that. Just wanted to be super clear. You go ahead and say you're an account admin, then you can get to the account console. You say you're a workspace admin, then you can get in and manage the workspace. But otherwise, you just authenticate to the account and you may get a list of workspaces and then you can just go to the ones you're authorized to use.
So, it's very secure. Second, it works with network security. Now, more and more of you are excited to use network security with data bricks. So, let's say you have users who have set up private link with their workspaces that works with unified login. Let's say you have users who are interested in more network security controls. We actually have a slide on this coming up in a few minutes where I'm excited to talk about what more we are doing there. the high level messages.
If you go ahead and configure network security with data bricks, unified login works for it very well. And finally, I'm looking for a couple of confessions here. How many workspace admins in the room have used the crutch where in the past you could sign into the workspace with a password even if you had SSO set up just because it was convenient more than a year ago? Okay, nobody's raising hands, but three of you were honest enough to nod your head.
So, like that used to happen. Good news. Over the last year, we actually have a much better solution for you. It's called SSO emergency access. And what that means is authorized individuals who you designate can bypass SSO if you need to login in a jify. And let's face it, I have seen support tickets and you have hated filing them when a sample certificate expires. Now these users can bypass SSO but only with MFA. So it's a mainstream feature.
All of this goodness is available to you on unified login with account level SSO. Now, how many people in the room have AWS accounts which were created before June 2023? Seeing maybe a third of the room raise their hands. Great. So, anybody who had an AWS account get established after that date, you're already on unified login, the model that I described. But the ones who were who had database usage before then, it requires some identity provider config changes.
So, we can't do those for you, but you can go ahead and tune them. Now, what do those changes look like? The next two slides are going to apply to that set of folks. Your identity provider configuration probably looks something like this. You have account each of the workspace tiles and your IDP. And in your IDP configuration, you say this set of users or groups are allowed to access this workspace, this other workspace, and so on.
What we'd love for you to do is to take all of those groups and users for each of the workspaces and just make them available to the account level configuration in your IDP. Like I said before, this doesn't mean they become account admins. They'll still log in the same way, but you're just routing them through this account level identity provider type. Now, what's in it for the users? Does the screen on the left look familiar to anyone?
I'm not exaggerating. This is a screenshot that I took from my own older experience with databicks workspaces where we had a tile for each of the workspaces. And if I'm provisioned in more than one workspace, I'm having to hunt around to click on the right tile and there's random apps. That is an actual screenshot of some app our IT team provision. I of course master name. So like users are confused. They're lost. Look at the right model.
So much more beautiful. You log into data bricks. One account tile. Users get straight into data bricks. They see a list of workspaces and they jump into the one of interest. It's a far nicer experience for them. So if you like what I'm telling you, how do you get there? Three steps. First, I explain what changes you need to make on the identity provider side. So you go ahead and do that rewiring on the IDP. Second, you want to make sure you have account level SSO configured.
These are just table stakes. Next, you go to a workspace. You select it. We have a UI. You can go ahead and select the workspace. Say apply unified login to that workspace. And this part is important. Now, make sure you test with one of the users who was in that workspace and had access from the older workspace SSO and make sure they can still access from the new migrated SSO just to confirm your IDP setting changes were enforced and applied correctly.
Just rinse and repeat for every workspace. And at the end of that process, go back to the IG team and change your identity provider configuration to delete those old workspace tiles because you no longer need them. And that's how the user experience becomes simplified. And just to make sure nobody in your companies are surprised, let them know that they can now go ahead and just use the databicks account tile to log in and you also unlock as an admin all kinds of new features you're going to be hearing about this week.
So this was all about AWS. How many of you in the room use on Azure? Okay, quite a few. So the next stuff is you guys know this Azure. We're already integrated with first party on Azure with Azure data bricks. So you have automatic single sign on and this year we also launched automatic identity management. Another session which we'll talk about at the end goes deeper into that. So if you're on Azure great you don't have to worry about this.
It just works. Super excited to announce today we're sharing that we're also bringing the single sign on experience to Google Cloud for two reasons. When we initially started out on our Google Cloud journey, a lot of the early experiences we had were with startups or midsize companies who were just excited to let people log in with their Gmail accounts. Now that could also let your consumer Gmail accounts login. As we have worked with all of you and we have seen the database on GCP usage grow and deepen, we're excited to take the SSO functionality that I described and just bring it as is to Google.
So let's say you started off with AWS, you're now about to add your GCP deployment. The exact same configuration can work on GCP and help our users be productive from the get- go. So this is all about user authentication. But a lot of you probably know ton of database usage happens with APIs. What might that look like? Okay, let's take a simple example. And everything I say from here on applies to all three clouds. So let's say you had a user token that was created a while ago to create an injection job.
Okay, ETL ingestion sounds basic enough. And like we're excited to see with many of you, the data bricks usage deepens. The first person to maybe try out data bricks in their team at some point ends up maybe becoming a workspace admin or a team admin. Now that token which is running that ETL job happens to belong to a workspace admin and it is very powerful. You didn't intend it the day that you set it up but that's what's happening.
And now imagine that this happens not once but dozens of times across various teams in our organization and you may not even know it's happening. So why does this happen? Let's take a step back first. I'm super excited that many of you find so much value in data bricks that you just want to access it from a ton of different places. DBS SQL or data warehousing offering that's been getting a lot of exciting market share and now there's more and more users accessing data bricks deeply from their preferred BI tools.
Notebooks whether data bricks own or third party a lot of you have workload automation that you configure with data bricks. So long-standing jobs or workflows that are running. Developers want to test out stuff so you have CLI or ad hoc usage. And we're excited to see a whole class of new use cases. You'll hear a ton about AI the next four days. I'm excited that customers who work with for us for long are now starting to deploy ML models in production with data bricks.
That puts even more pressure on authentication needs. So what happens in all of these cases? It appears that the natural choice would be personal access tokens, but that's wrong for four reasons. First, these tokens are long-standing. Second, these are better tokens. If they were to get compromised or stolen, like a couple of instances that spoke about from the industry, they can be misused. Third, they let you do full user impersonation.
And finally, if the user's role evolves, like in the example that I shared with you a minute ago, then the token is doing far more than you ever intended. So that's the reason why it's hard to know what's happening. And you're like, "Okay, we get the problem. Do you have a solution?" And here I'm excited to share, we actually do have a solution. And I'm even more excited to share this solution that has been crafted and has become GA level.
Thanks to one of the folks who is in the audience, a customer thought leader. You guys should chat with for both the good and the bad after the session because we work with his team and many other customers through the preview stage to make this be industry grade and giving you a ton of visibility investigating risks and strengthening security. Now, I could talk about it, but isn't it more fun to see it in action? So, let's go into a quick demo.
Okay, so one of the things I'm super excited about working at Data Bricks is we have an active dog fooding culture. And in this session, I'm giving you a little bit of behind-the-scenes look at our most actively used dog fooding account. So 10 of us are just in there creating workspaces, playing with tokens, etc. And we're in the account console and we are looking at the token report. Now, this is giving you visibility into all of your personal access tokens across all of your workspaces.
And there's a few cool ways to use it. So, let's go in and I'm going to type in name and see what comes up. Now, what's happening is it's going ahead and it's pulling in everything that has been doing across all the different workspaces in the account. And that'll let us know which type of tokens she's utilizing everywhere. Give me a second. Looks like the Wi-Fi is just taking a second to kick in. So when this comes up, what you'll see is these are all the tokens that created across the different workspaces.
And you can see it's giving you one workspace and also a second one. So that's a cool way to know for this user what are all their tokens across the entire account. The second thing you can do is you can go ahead and split it by principal type. So you can have SP paths or user paths. So now you're taking a look at user personal access tokens. And now you can start using the other filters. So for instance, one of our most actively used dog fooding workspaces is called E2 dog food.
So now I'm looking at all the user access tokens in E2 dog food. But the ones which are more interesting for our purposes are maybe the ones which were created a while ago. So I'm now looking at those which were created over six months ago which do not expire for another six months and let's say have not been used for the last month or so. Now this is a very interesting set of tokens for me to go investigate as an admin.
And at this point I could just go ahead and multi select and I can click export and that generates a CSV which I can now use to follow up with those individuals to understand what's going on and maybe start tightening my security and going up the maturity curve. The last thing I want to show you is you can come in and go ahead and look at workspaces. So for an easier example, I'm going to go in and show you a dog fooding workspace that I set up.
And I invited and some of the core members of the engineering team to come in and do some testing here. Now, in this case, you see this button, workspace admins. Boom. So from all the tokens in the workspace, I'm now looking at the admin tokens. And I can at this point go ahead and select them and just go ahead and click revoke. Boom. Those four tokens are gone. So this is how this lets you get actionability and insights into tokens usage across your organization.
Now this was cool for getting a sense of what is happening today. But how do you go ahead and use it? First thing I'd like you all to do is to go ahead and take this token for token report for a spin and just understand which are the workspace admin paths especially the workspace admin user paths and see if you need them or can you go ahead and revoke them if it's safe to do so. Then go ahead and scrutinize your prod workspaces.
So this would be like a basic level of thing everyone can do it. It's going to take literally five minutes. The next thing you can do is you can start focusing on who are the users who have a lot of access. Maybe it's the data team or an operations person who's provisioned in a ton of workspaces. Maybe it's an executive who has access to a lot of data. So look at the access token usage of those users. And finally, I'll go ahead and challenge you to think about do you need any workspace admin user paths at all.
One of the folks I was chatting with before the session started said they'd like more inputs to go and have a dialogue with security. This is the dialogue you all should try and have internally and see if you can move away from paths entirely and I'll talk about how in the next segment. Before I go there, super excited to announce that we are also going to start letting you know before a token expires. So, if you are using long-standing tokens, it's been valid for months, somebody's forgotten about it, we'll go ahead and send a notification 7 days before the tokens expire so you can go ahead and take corrective action.
All right. Everything I spoke about so far, we're still trying to contain the risk, but we're moving up this curve. We want to get to the next level. And so, what is the next level? Try and get to a state where these tokens cannot be easily stolen or misused. Now, how do you go ahead and do that? I have three ideas for you. First, go ahead and look at the databicks provided guardrails. So, we do a couple of things to try and just help your environments run more securely.
Any new token you create that's been created after December 2024, you can have at a maximum two-year lifetime validity period for that token. Second, we go ahead and automatically scan for tokens which haven't been used for over 90 days and go ahead and revoke them so that your risky tokens are not lying around unused. What you can do next, and I'm excited to announce a new feature here today, is that you can set an account level TTL.
So you could say for this account, for example, one of the other customers we work with, their IT policy is you cannot have any tokens that are valid or secrets for more than 180 days. So now you can just set that up at the account level and it'll apply to all of your workspaces. And then you can further override it and tighten it by maybe a tighter workspace level TTL. I have a visual coming up in a second. And finally, you can actually go ahead and disable personal access tokens in workspaces where you don't need them because we have other alternatives which I'll talk about in a second.
So this is how you try and move away from needing personal access tokens to not needing them or if you must use them, use them more securely just to make sure that there's a clear visual that lands the point. 730 days we enforce you can set an accountwide TTL and if you wanted to, you could have a workspace TTL. The workspace TTL can only further tighten the accountwide TTL and not relax it further. And you may want to use these for production or sensitive workspaces.
So this was all about lifetimes. But there's another thing I'm super excited to share with you today is that we are tightening up our network security protection. So just to quickly recap, we have some features in use today. Some of you use IP alackles private link to try and make sure you're reducing the surface the wire surface from where tokens could potentially be stolen. Now that was great but we started running into an interesting problem as data bricks usage deepened in your organizations and more and more users wanted to use it.
What happened? Well, somebody wants to go ahead and use this cloud analytic service. Somebody wants to use a different one and sometimes in their cloud-based or SASbased the IP ranges that they may have for you to allow list starts widening. So yes, it's IP alackles, but it's IP ales with a huge range. So to go ahead and give you more interesting controls, we have a few new features. You will be able to specify rules, networking rules based on users or service principles.
You could do those based on API scopes. So maybe you're okay letting a cloud-based analytic SAS product get in and use SQL endpoints and use SQL scope tokens, but perhaps not your ML tokens. And then this will be based on allow and deny logic with multiple layers of cascading. So it's going to be super powerful. It's in private preview now and we have a session coming up later in the week that goes deeper into how exactly all of this work.
The meta point is you start putting more restrictions on where can the tokens be played from. And the third thing is take a look at which use cases even need personal access tokens. What I'm showing you is a screenshot from the latest downloaded Tableau desktop version that I downloaded on my laptop a couple of days ago. And you can see that there is a databicks login recommended as the default option. If I was to go ahead and click sign in, it would bring up a web browser and I'd log into that web browser just like how I would authenticate to data bricks and behind the scenes a short-lived OOTH based token would be obtained for me instead of the longer live token which I would have to put in through the second option.
So encouraging your users to starting to use oath is a way to get them away from this basic way of authentication. It's not just Tableau, PowerBI, Thoughtspot, Click, DBT, Prophecy. I could go on and on. All of these customers we've worked with and partners over the last year to integrate with this new authentication flow. If you come across any partner tools that you use which do not work with data bricks in this recommended manner, let us know and let them know.
We have integration points with most of the major ones already. So the idea is think about how can you move away from using personal access tokens to these ways of logging in. All right. Now we're starting to get to the cutting edge. And to talk about this, I'm actually excited that I have another leading customer attendee in the room. Their company has helped us shape the usage of these data bricks managed token federation features.
Now what is that? So a lot of you are using data bricks through automated workloads. You may have a script that looks something like this on the left. It has a client ID. It has a client secret of some type. The whole idea is how do we get you from there to a version where you have no client secrets. Now who might be good contenders for this? You may have automated workloads. You're a security first organization. Or let's say you have thousands of Azure DevOps pipelines or GitHub actions.
Each of those, even if it's backed up with an SP, is then thousands of secrets. So it's just increasing your risk exposure. And the token federation, you have a far more elegant solution. And I could talk about it, but instead, why don't I show it in action with a demo? So I'm starting off our screen inside GitHub actions and you can see I successfully completed a run a couple of minutes ago which shows that I had used a secret.
The run completed successfully and we're taking a look at the code. I have three steps. The first one goes ahead and sets up the environment. The second one installs the database CLI and the third step invokes it. Now let's go ahead and make a change. So, I'm clicking edit and you see that line which says database client secret. Let's just go ahead and delete it. We got rid of it. But we also need to let GitHub know how we wanted to authenticate.
So, I'm changing the text to say it should use GitHubc for workload federation. And I'll now go ahead and commit changes to have this script move from secrets to workload identity federation. So now we have set up the GitHub side, but let's go to datab bricks. This is the service principle. So you can see previously it had a long-standing secret. We no longer need it. So I'm going to go ahead and click delete and I'll go ahead and click on create policy.
Now there's a custom option for generic use, but we have a simpler template for GitHub actions. So I go into it, and I'll just go ahead and type in the subject line. Now this line's important and this lets us know which GitHub action do you want us to trust with the GitHub issued tokens. So you go ahead and configure that and your datab bricks service principle configuration is complete. We come back to and remember we just updated our code to change it from oath M2M authentication to GitHub OIDC.
So now let's go ahead and trigger a new run. Now the way that GitHub actions work ordinarily it would automatically run on certain triggers but for the purposes of the demo I'm going to invoke one manually. Now token federation is an industry best practice that is highly recommended for workloads such as automated workloads, GitHub actions, Azure DevOps pipelines and many others because it eliminates the need for any long-standing secrets.
Instead, you're relying on the tokens that are issued and signed securely by this other entity. Just think of it like single sign on for tokens just like you use single sign on for users. So, as you can see, I've triggered that new run. It is in progress and it's getting deployed to production. Now, when I go ahead and click into it, it would have invoked databick CLI and one of the things we're trying to do is look through our audit logs to find users who may have tokens that don't expire.
And sure enough, we have one such user in this example. But you can use the same concept and paradigm for a variety of other things. So in this example, you saw how we migrated ourselves from a GitHub pipeline, a GitHub action that was using secrets to one that relies on workload OIDC identity federation. Let me get our slides back on. So, we're at the end of our journey and now with a quick show of hands, how many of you are excited to go from professional where most of you were to cutting edge.
All right, I'm excited to see the momentum. It was truly a pleasure meeting with many of you at the last data and AI summit and in conversations that we had in hallways and in small groups. mic. Can you guys hear me in the back? You want me to Can you guys hear me again? Okay, perfect. So many of you in conversations mentioned last year that you believe there was no password- based usage from your APIs. However, in nooks and crannies of workspaces and longforgotten jobs, we found those examples.
But what's amazing is through this partnership between R&D and our customers, we conquered that problem. There are no customers using any basic password-based authentication in API and data bricks today. Now my hope and challenge for all of us is by the time we meet at data and AI summit next year we would have gone ahead and eliminated the use of these long-standing personal access tokens and beyond these more secure versions where your user just log in and automation relies on tokens which are shortlived through these features.
On the R&D side, we're super excited and you should expect to see us do more in notifications, system tables integration, making it easier to use workload identity federation through SDK enhancements and better manageability tooling. With that, I want to invite back up to talk to us about the rest. One thing I want to tell you is, in addition to giving this talk, has amazing backstage access. I know she was chatting with the keynote leaders yesterday and she can tell you all about the rest of the session and some next steps.
Awesome. Thanks. All right, I guess some housekeeping and next steps for everyone um on how to get started with all of this. These are our top three next steps on, you know, getting up that maturity curve, SSO at the account level, requiring MFA, using OOTH for user login and token federation, and then monitoring risky tokens usage. So Sid did an amazing job demoing all these different capabilities that are available for you all.
QR codes here. We have identity best practice guides which are awesome on our docs pages to walk you through step by step how to enable all of this. And I think like two weeks ago we put out our release round blog. It basically summarizes this presentation. So it's a great reference. I see some people taking photos so I'll keep it up. Awesome. And then this is just a small number of sessions that we recommend. I've been at Summit for three years now.
We started with like one identity session and then one security session. We have like 20 sessions this year on this topic from our PM teams, um our field engineering teams, our customers. This top one that's later today, I know a lot of you use Azure. This is going to be pretty Azureheavy, so I definitely recommend it. It's going to talk about automatic identity management. It's going to talk about PIM. It's going to be really good.
Um the one we have tomorrow is with our security and compliance product management team. Um that'll talk about that ingress control, all of our network security um innovations. We actually had a blog go out this morning that's kind of highlights all that will be covered in that session. Give it a look. Um if you're interested, they'll deep dive on that tomorrow. And if you're starting to use AIBI, we've done a lot of innovation in the identity space for that as well.
Um so check that out on Thursday. If anyone's really interested in cyber security, we have a cyber security um symposium this afternoon that'll have an logic whiz um security leaders at data bricks. Highly recommend. Um it's a big space we're investing in as well. So lot more to come here. training. Some of you probably were here for training. We have a lot of training opportunities both at summit and afterwards. And surveys.
There will be a survey on the session. Please give us good remarks. Um please let us know any feedback um things you want to see. We can put out a lot more content for you all on our YouTube channel, blogs, etc. Our session for next year. Um thank you. I think we have a couple minutes for questions. Thank you. Oh, we have time for

Learn more about the Databricks Data and AI platform.