We are using the built-in authentication in Static Web Apps (SWA) to authenticate users, using Entra ID in our organization. Now we want to enable a Database Connection, but we want to have some access control as to what the users can access in that database, depending on their group membership. Is it possible for the Database Connection to use the user identity of the logged-in user, or does the SWA always and only identify as the identity of the app? If it's not possible to use the user context through the Database Connection, can we access this user context in our own API (linked through the API settings of the SWA)?

Does the new Database Connection in Static Web Apps support User-based access?

Accepted answer

Pramod Valavala 20,641 Microsoft Employee

@AP Mossevig Based on the Authorization Official Doc, looks like Data API Builder, which powers Database Connection in Static Web Apps, supports Role Based Authentication.

With Entra ID, this translates to defining App Roles for your application and assigning users to these roles.

Note that for User Roles, there are two conditions that need to be met for Data API Builder to follow authorization rules

The role information should be populated in the token (take care of by defining App Roles in Entra)
The role should be specified in the X-MS-API-ROLE header as well

AP Mossevig 20 Reputation points

2023-11-01T10:12:56.3966667+00:00

(duplicate)
AP Mossevig 20 Reputation points

2023-11-01T10:18:18.4566667+00:00

Thank you! I understand the concept of Roles, at least superficially, i.e. User, Admin etc, that you can use to control the data accessible.

What we have though is a CosmosDB where different users have access to different part of the data through group memberships. How do we go about implementing that? Do we need to create specific roles for each group and then give those roles access to the specific partition keys?

Would it then rather make more sense to use the CosmosDB REST interface and pass the user context there, as I think that REST interface can use the user information to see and filter what data should be returned?
Pramod Valavala 20,641 Reputation points Microsoft Employee

2023-11-01T12:12:58.94+00:00

@AP Mossevig Yes. Creating App Roles would be necessary based on the current version of Data API Builder I believe.

If you don't require any extra features that Data API Builder provides, you could certainly use the CosmosDB REST interface directly. But this would mean exposing CosmosDB to your users.

Also, do create a feature request on the Data API Builder repo to add support for group membership claims for a more insightful discussion about it.
AP Mossevig 20 Reputation points

2023-11-02T08:17:20.01+00:00

Thanks!

We will continue our quest, but this helped a lot.

I've added the feature request here, feel free to add any additional comments if I didn't get all the details down: https://github.com/Azure/data-api-builder/discussions/1855
Pramod Valavala 20,641 Reputation points Microsoft Employee

2023-11-02T16:52:56.8666667+00:00

@AP Mossevig Glad to hear that! One (important) thing that I missed mentioning in my last comment is that you can assign groups to App Roles. So that should help but still does require you needing to maintain app roles in addition to your security groups now. 🙂
AP Mossevig 20 Reputation points

2023-11-03T08:56:46.43+00:00

Yes, but if I understand it correctly, the app/user would authenticate with the role which is what should be used to check for data access, so I would also have to add the app role as a member of the security group?

Pramod Valavala 20,641 Microsoft Employee

@AP Mossevig Not exactly. They would still authenticate as themselves and like the groups claim, they would have a roles claim in their token that your API would use.

The App Roles are like Security Groups in many ways except that they are defined at an Application level instead of at the Tenant level, and like security groups, you will need to add users/groups to these app roles (not the other way around).

The linked doc about App Roles has the following differences mentioned as well

Though you can use app roles or groups for authorization, key differences between them can influence which you decide to use for your scenario.

App roles	Groups
They're specific to an application and are defined in the app registration.	They aren't specific to an app, but to a customer tenant.
Can't be shared across applications.	Can be used in multiple applications.
App roles are removed when their app registration is removed.	Groups remain intact even if the app is removed.
Provided in the `roles` claim.	Provided in `groups` claim.

Share via

Does the new Database Connection in Static Web Apps support User-based access?

0 additional answers

Your answer