I have an existing API Management service that I have enabled REST APIs with. The API management services comes by default with a developer portal where people can register to use our APIs.It looks something like this.
As you can see, you can register here but also sign in. This API management service by default uses basic authentication to move you forward. After looking at the docs for API management service, I was not able to find anything that would help me replicate this so I can use APIs to make the same /register or /login calls.
My question is, how can I use my own Angular app to make API calls with a simple username/pw to allow user registration and login against API management service?
See here https://learn.microsoft.com/en-us/rest/api/apimanagement/2019-01-01/user/createorupdate for an API call to create a new User in API Management.
There are two ways to address APIM management API. The default and most commonly used way is through ARM (https://management.azure.com) this way you only will be able to use ARM auth and will go through usual RBAC checks before you're given access to any operation.
If you're aiming towards how dev portal itself uses APIM management API then you need to follow this guidance: https://learn.microsoft.com/en-us/rest/api/apimanagement/apimanagementrest/azure-api-management-rest-api-authentication. On one thing this allows you to create SAS token and call management API directly (notice that hostname in base URL is different), but more interestingly, once this API is enabled it becomes possible to call it anonymously as well. Of course only data you expose to anonymous users through dev portal is available this way.
More interestingly though is that it opens possibility to make Basic auth calls to such management API. Anonymous user could make call to any endpoint with Basic auth token based on user email and password and be authenticated this way.
Related
I want to develop a SaaS application on Azure and deploy to the Azure marketplace. This app will be able to obtain information about the user's network. (for instance VNET information). Ideally I would like to have a single-page application that would authenticate with the user who subscribed to the app, and then make calls on a backend API tier, which would make calls to Azure management API endpoints.
The Azure docs layout a number of scenarios of how apps could interface with AD. how-to guides
I believe what im trying to do most closely matches the "Build a web app that calls web APIs" flow, which is an example of OBO. My question is, is that really describing what im doing? Is "calls web APIs" really an example of invoking APIs on the microsoft azure platform?
So my understanding is that I would develop my own API app, that would accept requests from my client browser code, which would contain an oauth token, and then the API layer would derive another token to pass onto the Azure API layer?
Im trying to keep the architecture as simple as possible, but im afraid I may be misinterpreting the Azure docs.
OBO (On-Behalf-Of) allows you to exchange an access token that your API received for an access token to another API.
The important bit is that the access token must have been acquired in the context of the user and must contain user information.
The new access token will then also contain this user's info.
So it allows your back-end API to call Azure Management APIs on behalf of the current user.
This means your API can't do anything the current user can't do.
It is limited to the user's own access rights.
The other option for authentication is to use client credentials authentication,
where your back-end API uses only a client id + certificate/secret to authenticate.
In this case the token will not contain user information.
To enable this approach, the target organization's users would have to assign RBAC access rights to your app's service principal, so it can act by itself.
You could also build a flow in your app where you setup these RBAC accesses on behalf of the current user.
Personally, I would prefer to use delegated access (OBO) whenever possible, as it will block the user from doing things they cannot do.
Though on the other hand, service principal-based access allows the organization to control your app's access better.
I got a HTTP triggered azure function, which is using by one of my web applications. The user of this site would be anybody who signed up to the site. Now I want to implement authentication to the azure function in such a way that only signed up user would able access the azure function through my web site. I could see many built-in authentications like azure functions, OAuth using Azure AD and other identity providers etc. I am looking for to way to authenticate users signed-up through my website, not with identity providers.
One solution I can think of is while signing up a register that user to Azure AD. Then while calling the API pass user credentials to the API and validate against AD. Can somebody please advice this is a good solution? If not please advise the best solution for my use case.
I don't want to use any external auth provider
Just referring to the documentation:
Azure functions HTTP Trigger - Authorization keys
While keys may help obfuscate your HTTP endpoints during development, they are not intended as a way to secure an HTTP trigger in production. To learn more, see Secure an HTTP endpoint in production.
The second link Secure an HTTP endpoint in production gives more insights on how to secure HTTP triggered functions:
To fully secure your function endpoints in production, you should consider implementing one of the following function app-level security options:
Turn on App Service Authentication / Authorization for your function app. The App Service platform lets use Azure Active Directory (AAD) and several third-party identity providers to authenticate clients. You can use this to implement custom authorization rules for your functions, and you can work with user information from your function code. To learn more, see Authentication and authorization in Azure App Service and Working with client identities.
Use Azure API Management (APIM) to authenticate requests. APIM provides a variety of API security options for incoming requests. To learn more, see API Management authentication policies. With APIM in place, you can configure your function app to accept requests only from the IP address of your APIM instance. To learn more, see IP address restrictions.
Deploy your function app to an Azure App Service Environment (ASE). ASE provides a dedicated hosting environment in which to run your functions. ASE lets you configure a single front-end gateway that you can use to authenticate all incoming requests. For more information, see Configuring a Web Application Firewall (WAF) for App Service Environment.
In my opinion you can do this in following ways.
Using function level Authorization key (Not preferred but easy)
If your web app is the only one that will access the function app you may enable authorization directly on the function. Any one who wants to access the function has to pass the key else you get 401 . Since you want your function to be accessed directly by users then you have to create additonal end point in your web site that will call function app on users' behalf and pass the key. You can find more about here
Authorization Key
Using Azure B2C or AD
You are thinking on the right lines. If your website is external consumer accessed then you may consider Azure B2C. You get many out of box functionalities including sign up using social logins and you may not need to save the users separately. The flow remains the same , users get authenticated by Azure AD (or B2C) and token is issued. The token is then passed when calling azure functions.
I was wondering if it's possible to add more then one authentication provider to protect an API endpoint via Azure API gateway.
From the portal, it doesn't seem like it is possible since it only allows you to select one? Wonder if there is a workaround?
For example, I want a user to be able to sign in to google and as well as facebook via openIDConnect. Based on successful validate-jwt in the policy of the API be able to hit the actual endpoints.
Only one provider can be associated with an API at the moment. But this association does not affect runtime request processing in any way, it's purely for documentation and test console purposed. So if those are not important to you it should not be a big deal.
I want to use this method for deploying my ApiManagement Settings from a my Git repository.
https://learn.microsoft.com/en-us/rest/api/apimanagement/tenantconfiguration/deploy
But (of course) I am asked for a authorization token.
I cant figure out where to find/create this token?
There are two ways to call APIM management API. One is to go through ARM - calling URLs that start with management.azure.com. This way you're relying on Azure authentication, it's RBAC rules, and the regular wayt to authenticate to Azure apply here: https://learn.microsoft.com/en-us/rest/api/azure/#create-the-request. This is recommended way. This is the same API that is used by Azure PowerShell.
APIM does offer another way though called Direct API. This is optionally enabled in Management API page. There as well you can generate a SAS token that to can put into Authorization header while making a call. For this to work you need to call APIM API directly via .management.azure-api.net. Base URI for your service is displayed on the same page.
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.