# WEKA OpenSharing UI on Databricks **Type:** Demo **Watch:** https://fast.wistia.net/embed/iframe/xfqh8p6at1 ## Speakers - **Carmel Schwartz** — WEKA ## Transcript ### [00:00] WEKA OpenSharing Architecture Overview Hello, I'm Carmel from WEKA. In this demonstration, we're going to walk through how to use the WEKA OpenSharing UI to create shares that scope Databricks users to tables stored on WEKA. Architecturally, we have three key components: our underlying WEKA storage cluster, a separate instance running the WEKA OpenSharing package and UI, and our Databricks environment. To set up our environment, over here on the right, you can see I've already logged into my WEKA cluster, where I have an S3 user configured. ### [00:37] Creating Shares and Access Tokens Now, back on the web portal, I'm going to use the S3 user's credentials, specifically the access key and secret key, to log into the WEKA OpenSharing UI. These credentials authenticate against the WEKA S3 endpoint specified during the OpenSharing package deployment. Once logged in, I'll create a new share, for example, called John. When I press continue, the UI displays live table metadata directly from that endpoint. And more importantly, the UI enforces strict role-based permissions, so this dropdown will only display the Delta tables that this specific S3 user has permission to view. From this filtered list, I can choose exactly which datasets to make available. For this share, I'll select vaccine ingredients. Once the share is created, the next step is to generate an access token for it. Here, on the token page, I'll configure John's token and set an expiration date for security. As soon as I click create token, the UI generates a complete share profile. This displays our endpoint URL, the bearer token, and its expiration date, formatted exactly how Databricks expects to ingest it. I'll click to download this shared configuration file locally. We'll use this file in a later step to authenticate and complete the connection inside Databricks. But before we switch over to Databricks, let's navigate back to the main share page to see how this scales across multiple users and token policies. ### [02:18] Managing Multiple User Share Profiles I'll create a second share, this time named Jimmy. Just like before, I'll select the specific Delta tables that Jimmy will have access to. Now, when generating a token in Jimmy's share profile, notice we have two options. We can either map John's existing token to this share, or issue a brand new token entirely. For this scenario, I'll create a new token. Once generated, we get Jimmy's distinct share profile, ready to be downloaded and connected straight to Databricks. ### [02:53] Reviewing Underlying YAML Configuration For the more technical viewers, clicking into the advanced tab shows the underlying YAML configuration that powers these policies. Notice there are two core components. The share section determines which tables are shared, while the authorization section defines who gets access to that share. Right here in the YAML, you can see that John's token is mapped directly to the John share, exposing only the vaccine ingredients table. ### [03:25] Verifying Live Server Configuration To verify everything under the hood, over in the terminal session connected to the WEKA OpenSharing server, we can inspect the active configuration. As you can see, every change made through the web UI is updated live on the server in real time, ensuring immediate enforcement without needing manual service restarts. Now, let's switch over to Databricks to actually consume our share. ### [03:51] Connecting WEKA Shares to Databricks Under open sharing, we'll create a new provider and upload the credential file we downloaded for John. What's key to note here: even though our WEKA server configuration tracks multiple users like John and Jimmy, authenticating with John's specific credential file ensures Databricks strictly inherits only John's permissions. ### [04:14] Mounting Providers into Unity Catalog Now, we'll mount this new provider directly into Unity Catalog as a new catalog named John's Catalog. When we expand this catalog, notice that even though our WEKA cluster holds both the ingredients and patients table, John only sees the vaccine ingredients dataset. ### [04:34] Querying Shared Datasets in SQL Heading into our Databricks workspace, we can query this data live. Running SQL commands, we can see our provider, just John, list the schema and tables, and run a standard select query directly against the tables on WEKA. To prove our permission scope is working, let's try querying the vaccine patients table. As expected, Databricks returns an error. Even though the table exists on WEKA, John hasn't been granted access. When we update our SQL query to target vaccine ingredients, the command succeeds because John is explicitly mapped to it. Now, let's look at access control, and more specifically, removing access. ### [05:19] Revoking Access and Token Management Back in the WEKA OpenSharing UI, we can manage active tokens. For any existing token, we can rotate it, extend its expiration, map it to a different share like Jimmy's, or revoke it entirely. I'll go ahead and revoke John's access. If we check the advanced YAML view, the policy updates instantly. Where we previously saw tokens for both Jimmy and John, John's access profile has been removed. ### [05:48] Real Time Permission Enforcement Switching back to Databricks, when we refresh the schema under John's catalog, the table disappears. Because access was revoked on the WEKA OpenSharing side, Databricks instantly loses visibility into the dataset, providing complete, real-time control over external data sharing. With WEKA OpenSharing, you give streamlined data access to Databricks users without ever sacrificing storage-level security or governance. Thanks for watching.