In Azure portal, i wanted to create multiple useraccounts and then track those useraccounts for the data usage in Azure API management service. I can able to create the useraccounts but inorder to know how much data is used by those users for particular API, how can i get that metrics?
API Management has 2 portals and 2 types of users. The Azure Portal is used for API Managers (think users who publish APIs, operations, manage policy, etc.). The Developer Portal is used by developers who are using (think customers) of your API. In order to use an API the user/customer has to register with the Developer Portal and get a Subscription to a given API and the associated key. So you have to authenticate them.
The Developer Portal supports different authentication mechanisms including Azure AD. So if you plan to use Azure AD for your authentication for both portals you will need to configure it accordingly. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad
fwiw - by default the Developer portal provides a form based authentication for developers
Metric wise once a developer is registered you will be able to report on their activity through API Management.
Related
This is more of an 'Is this possible' question. A developer on the team suggested using Azure AD for user management, but one of the requirements is that the app admin be able to add/manage user access through the application without having to go to the Azure Portal.
So the question is, is the Graph API (or some other mechanism) full featured enough to replace the portal (at least for basic user set up and management) and allow all actions to be done from the application UI?
Thanks.
Simple answer to your question is Yes. Graph API can be used to manage users and their access to applications instead of using Azure Portal. In fact, Azure Portal itself makes use of Graph API to perform these operations.
You may also need to use Azure REST API if you're planning on managing Azure resources as well through this custom application especially Authorization APIs if you want to manage access to Azure resources (Azure Role-based access control) through your application.
I have two separate web applications, one built with .NET Framework and the other built with .NET Core. Both web applications make up one solution which we ship to our customers. The solution itself is a SaaS subscription-based solution, where users would be able to sign-up with using either a Microsoft/Office 365, GSuite, or organizational account (basic username/password). We would like to restrict sign-up to organizational/business accounts only.
As I understood, Azure B2B is mainly useful when you have something internal and you would like to give external users some limited access to it. Given that I have a multi-tenant SaaS solution, I believe that Azure B2C makes more sense.
Furthermore, in our solution, we would also want the ability for external users to access Tabular Models in Azure Analysis Services and SSRS.
Is access to only organizational accounts, something that can be configured through Azure AD B2C?
Can access be granted to external users to Azure Analysis Services or other Azure tools when using Azure B2C?
You have two options
Option 1, Using Azure AD External identities solution - recommended
You can use newly released self service sign up solution in Azure AD external identities . You can very well restrict sign up to other Azure AD accounts only. However for sign up using other federation systems - you need to try on. I think as of today only Google and Facebook are supported apart from Azure AD.
Option 2, use Azure AD B2C and use app only authentication.
Azure AD B2C consumer accounts are by default not supported by Azure services or Office. But you can use app based authentication to provide these services. Your client app will call your backend api using Azure AD B2C token. Your backend app can perform all auth validations and then call the backend Azure or any other service using app only authentication mode.
is it possible to manage apps and services from Azure AD B2C via APIs (REST etc.) for individual users?
The authorised AD applications should be managed later in a self-developed dashboard via APIs.)
Best regards
Using the rest API, you can manage All the App services and also Azure resources.
for example updating the Api service
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/hostingEnvironments/{name}?api-version=2019-08-01
API for App service Please refer to this document it may help
I'm developing a tool, similar to Visual Studio's Cloud Explorer, that performs a limited set of management and deployment tasks inside a user's Azure subscription.
I'm thrown-off by a few things relating to authenticating against Azure and how the application represents itself to Azure.
Most of the documentation about authentication with Azure is concerned with web-applications that let users authenticate themselves against an Azure Active Directory. This is not my scenario. While me application necessarily authenticates users against Azure AD (as all Azure users are), my users are administrators, not "users".
I understand previously software that performed administration tasks would be assigned a Management Certificate which is separately-registered in the web-based Azure Management Portal. I understand this fine.
...however I also understand that Management Certificates are almost deprecated and are replaced with Service Principals, which itself makes more sense from a security perspective (as it enables more granular role-based security) - however the downside is that there are a lot of manual steps and hoops to jump through in order to enable the use of Service Principals with administration software - in particular you need to pre-register your application in Azure Portal.
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
So far I have actually got something that does this - I perform the following steps:
Use Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext to authenticate against https://login.microsoftonline.com/common (using AcquireTokenAsync which presents the webview to login). I use clientId: "1950a258-227b-4e31-a9cf-717495945fc2" which is the Azure PowerShell clientId.
Use the token from step 1 to enumerate Tenants and Subscriptions in the user's account.
The user is prompted to select a tenant and then a subscription from the list downloaded in step 2.
Send a new authentication request to https://login.microsoft.com/{tenantId} (where {tenantId} is retrieved from step 3), again using the same clientId.
However I don't like impersonating Azure PowerShell - Microsoft could revoke that clientId.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
Actually, the Visual Studio Cloud Explorer also register the app on the Azure AD and use the Service Management REST to manage the Azure subscription. And you can caputer the request using the Fiddler when you add account to the Cloud Explorer.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
We need to develope a multi-tenant application which enables the users from different tenant to use the application. After that we can use the Common endpoint instead of the specific tenant id you register the app. Then users login-in with their account which associate with Azure subscription and get the access token for the Service Management REST. At last the applicaiton can manage the Azure resource with the access token. For example, we can use the REST below to list the Azure Sbuscriptions:
Get:https://management.core.windows.net/subscriptions
Authorization: Bearer {token}
x-ms-version: 2013-08-01
And more detail about the authenticating Service Management requests, you can refer here.
I am trying to make my way through a lot of Azure documentation on multitenant identity management, for a bespoke ASP.NET MVC SaaS site. It is difficult as it seems that a lot of the online examples and articles are now outdated and not applicable to latest VS templates, and other vague aspects, such as determining what is Preview and what is not. Also, MS tend to use the word "multitenant" when specifically dealing with partner companies who have their own Azure AD, which is not our case.
Our proposed system will offer a web application to different customers. The backend will have a separate db per customer (tenant). The front end will select which db connection (and probably use impersonation) depending on the logged in user. The identity management would preferably be offloaded to Azure ACS, so that in future if we want to integrate with corporations with their own Federation identity provider we can, but for those smaller companies that don't have their own domain, we want to create accounts on their behalf.
I am thinking that a good way to do this is by using Azure ACS (for federating with corporate customers) and a general Azure AD directory (for everyone else), where in the second case I create a group per tenant (customer). Then, in Azure ACS, I translate all claims, either the group from my own AD, or the company name from the federated identity provider, and use that in the MVC app to establish the tenant.
Is this an OK way to do it? Am I overlooking some standard, simple way that Azure already offers? Is this future proof wrt to the Azure roadmap?
for the latest multi tenant samples please see https://github.com/Azure-samples?utf8=%E2%9C%93&query=multiten. We are about to release more documentation on how to handle multi tenancy in Azure AD. I would strongly advise against using ACS in any new project, given that we are no longer adding any features and we are actively working on migrating functionality from ACS to Azure AD. See http://blogs.technet.com/b/ad/archive/2015/02/12/the-future-of-azure-acs-is-azure-active-directory.aspx for more details.