Bulk invite people to an Azure static web app - azure

I've spend quite a lot of time trying to find the best way to add authentication to our Azure static web app. Eventually we settled for the easiest solution. restricting all routes for the app and doing our authentication using role management in Azure.
So far we've invited a few users, but we want to invite multiple users to our web app at once. Possibly add each user to some sort of group and inviting the whole group at once? I couldn't find anything on the 'Role management' page. We have limited knowledge of Azure so far.
I was hoping, could anyone give me a lead on how these things usually work in Azure? I'm struggling at the moment to find the right documentation.

Please check the references below:
You can only add 25 invitees/users(individual) to have custom roles via invitation but unlimited users can be assigned roles with a serverless function. This allows you flexibility in how you want to manage roles and you're not restricted in the number of users who can have custom roles.
Bulk invitation is not yet possible for role management in azure static web app and is in recent feature request .You can check here
References:
Assign Azure Static Web Apps roles with Microsoft Graph | Microsoft
Docs
Authentication and authorization for Azure Static Web Apps |
Microsoft Docs
Note:Bulk invitation is possible in azure active directory where we
can fill in csv template and submit: Azure AD | Microsoft Docs
You can raise a support request for the same from overview page> under Support + troubleshooting>new support request

Related

Restricting access to Microsoft Graph based on IP address, using application level auth and multi-tenanted app

I'm using Microsoft Graph API to access data from a variety of tenants' ADs. This is with a multitenanted Azure app hosted in my Azure tenancy. Authentication is handled using application level tokens and the client credentials flow; customer admins authorize the collection of data for their tenancy using OAuth. A customer is asking whether it's possible for me to restrict access to my Azure app based on location, so that our app dispenses tokens only to clients who are inside our data center.
It seems to me that this is not going to work. Microsoft recently added the possibility of conditional access based on workload identities; but are pretty clear that this only works for single-tenant apps, where the same tenancy hosts both the enterprise application and the app registration:
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
Note
Policy can be applied to single tenant service principals that have
been registered in your tenant. Third party SaaS and multi-tenanted
apps are out of scope. Managed identities are not covered by policy.
But, I am not an expert and may be working on incorrect assumptions. Can anyone confirm or disconfirm what I have posted here? Is there some way I can provide what the customer is asking for?
As mentioned in the document that it is applicable only to the single tenants, If you want this feature to be available for the mutlti tenants as well you can raise a feature request for same here: https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/idb-p/Microsoft365DeveloperPlatform

How do I use the Azure Billing APIs from a web app?

How do I create a service account, grant the necessary permissions, and use the Azure billing APIs (usage and rate card) from the server-side of a website?
I'm looking to show expected bill on 6/7/2018 is $123.45 on an internal dashboard, mirroring the data in the billing usage graph on the Azure portal.
https://github.com/Azure-Samples/billing-dotnet-usage-api and https://github.com/Azure-Samples/billing-dotnet-ratecard-api are the samples all posts reference. The setup for each references the legacy Azure portal, and the setup instructions make assumptions I don't understand. I've not found any more recent setup instructions for using the billing APIs. In all my experiments, I've received an OAuth token, but I receive 401 Unauthorized responses when calling the actual API. (Obviously I shouldn't include my guids in this question.)
The samples identify that when creating the app, I must choose a "native application", but Scott Allen notes that "native application" requires a live OAuthed user, but my users don't have permission to the Azure portal, so I must pre-authenticate with configured settings. He recommends "Web apps / API".
The samples are vague in the permissions required. They note I should "make sure the sample app will have permissions to access the Windows Azure Service Management APIs", but from the new portal, I don't find Windows Azure Service Management APIs nor any other permissions that sound like Billing management.
When crafting the AAD App in the portal, and when starting https://github.com/Azure-Samples/billing-dotnet-usage-api/blob/master/ConsoleApp-Billing-Usage/ConsoleProj/Program.cs, each references settings such as "Client ID" and "DirectoryId" that are named differently in different places. Though I feel confident in my mapping guesses, the sample doesn't work for me, so I'm confident I've done it wrong.
I've even tried making requests directly to the REST endpoint at https://management.azure.com/subscriptions/{subscription-Id}/providers/Microsoft.Commerce/UsageAggregates?api-version={api-version}&reportedStartTime={dateTimeOffset-value}&reportedEndTime={dateTimeOffset-value}&aggregationGranularity={granularity-value}&showDetails={showdetail-boolean-Value}&continuationToken={token-value} passing in the OAuth token without success.
What did I do wrong here? How do I configure an AAD app to use the Billing APIs using pre-configured auth and subscription settings to show Azure usage details on a web page?
According to the error log, it seems you don't give your app correct subscription role. You could check this link:Assign application to role.
Note: You could give your app Owner role.
You also check this link:Authentication flow for native application to API.
Also, you also could create a web app. But you need use different way to get the token, see different check this link.

web application to multi tenant application one drive business api

my question is similar to question Multi-Tenant app - OneDrive Business API
but i want my application to access the one drive from tenants of other different azure subscription, is it possible? i understood that if i register my application and mark it as multi-tenant, it will allow me access the tenant in my azure subscription, but if i want to access the tenant using the same application but in different azure subscription whats the way.
What’s kind of authentication flow are you using? Normally, we use the Authorization Code Grant Flow that the user delegates access to a web application. In this scenario, to enables the users on other tenants to login the website and access their Office 365 resource, we only need to enable the multiple-tenant app on the Azure portal.
but if i want to access the tenant using the same application but in different azure subscription whats the way.
It depends on which REST you were using. It is same as we are call the REST API for the single tenant app if we are using the Microsoft Graph to query the OneDrive for business. The endpoint of the list children of a driveItem is still like below no matter which tenant the user login:
GET https://graph.microsoft.com/v1.0/me/drive/root/children
GET https://graph.microsoft.com/v1.0/me/drive/items/{item-id}/children
GET https://graph.microsoft.com/v1.0/me/drive/root:/{item-path}:/children
If you were using the Office 365 REST API, we need to discover the service endpoint. You can refer to here for more detail about Office 365 Discovery Service REST API.
Depending on the permissions that you need normally the tenant admin of the other tenant has to add the application to their own Azure AD. With the newer app model v2 this is quite a lot easier as the admin can simply give consent once in the normal consent screen for the entire tenant. See here for a mor elaborate explanation of how this would work.

Office365 API Authentication - Azure vs Application Registration Portal

I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.

Role Claims when Federating Azure AD

We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.

Resources