Static-web-apps: Bulk Add Users and Expand 25 User Limit?

[theonewolf]

Background: we use Azure Static Web Apps for internal intranet documentation sites right now.

Thus, we are heavy users of access control and actually have none of our sites public.

We hit two problems with user management:

1. The 25 person limit is very stifling and means this product isn't actually usable for what we want it for right now.

2. There is no bulk import, or domain add say via Azure AD (ideally, we could let in any user on our domain).

   • We also need a method of easily granting access on our domain without manually sharing a URL / link. If the product emailed the user that would be acceptable for now.

[miwebst]

Agreed the 25 person limit is too restrictive, this is something that we added for preview and will relax as we make our way towards GA.

Bulk import is an interesting idea, we will keep this in mind as we continue to iterate on this model!

[theonewolf]

We really want to just add our entire AD to the app, but something like CSV bulk import that could email users would be a start.

[theonewolf]

@miwebst any documentation or update on when GA might be (or the marching closer)?

[theonewolf]

Or expanding the limit?

[takekazuomi]

any update ?

[theonewolf]

We are migrating off the platform today, as we can no longer continue with a 25 person limit.

[takekazuomi]

me too

[anthonychu]

Sorry the feature is unable to support you right now. Can you please share what number would be suitable so we can work on something that works for your scenarios in the future?

@theonewolf For your intranet scenario, would you prefer a way to limit access to a VNET instead? Or would it be better to have the site public and providing a way to lock down the AAD integration to users your organization? Do you require additional customization (such as using roles from AAD or executing a function to perform a database look up on log in)?

[takekazuomi]

For us, 100 is enough. If you are asking a post-GA question. Unlimited is desirable. We think that the model that purchases the performance separately is easier to use than the limit on the number of authenticated users.

[takekazuomi]

@theonewolf
We use a script (example) like the link to generate an invitation URL and distribute it on Slack. The URL itself is meaningful only to the person you are invited to, so it doesn't matter if it's visible to others.
There is a limit of 25 people, so it's not very useful. It is unfortunate.
https://gist.github.com/takekazuomi/408c5198d6dbd0cddfe3f1864379d201

[theonewolf]

@takekazuomi thank you for the insights and the script. The script is very valuable.

@anthonychu we were operating with it as if it was another cloud resource like dev.azure.com. We weren't requiring VPN to access it, which is refreshing and easier on our staff especially when not able to VPN.

For our current use case, public + AAD SSO limited to our organization / domain would be ideal. We are OK granting access to everyone in our org. One day, I'm sure it would be nice to map them to groups, but we don't need that right now. No custom functions needed for us.

We would stay if that was possible. This is almost the perfect product for us!

Edit: also, we need about 300 users. We skimped along with 25 waiting for GA, but can't wait much longer.

[tcc-sejohnson]

I heartily second this! @anthonychu, 100 users would totally take care of us for now -- but later on, it would be great to have support for unlimited users. My use case is very similar to theonewolf's. We're using SWA to hold information on BI products, and the 25 user limit makes this product more of a toy than something that would ever be useful in an enterprise scenario. It's a shame, too; the tight integration between my frontend (in TypeScript) and my backend (in C#) has made development a dream.

Even better, it would be awesome to be able to give access through AAD groups. i.e. give [email protected] access to the site, and then anyone who logs into the site and is in that group receives the roles assigned to the group.

Thanks for all your work on this product, and I can't wait for GA!

[tcc-sejohnson]

@anthonychu

Quick update from our end: I had to transfer our site to Azure Web Apps/Azure Functions and manually integrate msal-js for authentication, mainly because of the 25-user limitation.

I could see SWA being the _primary_ provider for all of our in-house documentation/resources if the user limit was increased or removed, and especially if we could optionally restrict logins to a single tenant.

To give you an idea of how promising this platform is for us, it took me ~30 minutes to set up our site on it (with auth!). It took me almost a week of pursuing the minutae of the MSAL documentation to work out all of the bugs in moving it over to the other platform.

The following features would make this the viable platform we really wish it was:

1. No limit (or a much higher limit) to user role assignments
2. Bulk add/remove of users along with an automated link distribution system (such as an email)
3. (Optionally) Group integrations -- it would be nice to assign users to groups and then assign groups to roles

If you guys implemented these features, you'd have us captured for life -- and I imagine others would say the same.

Again, thanks for your work -- I'd love to be able to use this platform!

[anthonychu]

@tcc-sejohnson We're working on restricting login to a single AAD tenant. Also investigating more ways to customize auth.