I think I do not understand something obvious here.
If I configure an API App in API Management so that URL /B requires separate subscription/role other than basic one which enables /A URL, do I have to authorize in application itself by checking current user role?
I am confused because the API App has also its public URL and can be accessed directly. It will have also API Management URL. So even though I setup all the throttling and all policies, that can be ignored by accessing application directly.
Can't the API App be only internal, with configured identity and allow only connections from API Management? How to setup authentication so that users have to go via API Management?
Once you put your API behind API management, you should consider the backend API's URL as your own private URL that only you use if you need to.
Both you and the consumers of your API should only use the public API management URL so that you get the benefits of the API Management Gateway. Don't give external parties the public URL of your backend API.
You have various options to protect your backend API. These include using Azure AD, certificates, basic authentication and even only allowing the Azure API management IP address to connect to your backend API.
It depends on where your backend API is hosted, what tier of API Management you are using (some options are only available in Premium), and finally, what capabilities your backend API has.
See this post for more details on all of the above.
Hope this helps!
Related
I have created an HTTP Triggered Azure Function and exposed some endpoints. I am calling those endpoints from Salesforce Community.
https://<testing...>.azurewebsites.net/getData
https://<testing...>.azurewebsites.net/postData
https://<testing...>.azurewebsites.net/updateData
https://<testing...>.azurewebsites.net/deleteData
The Azure Functions Authorization Level is anonymous. I can access the responses from HTTP endpoints to the salesforce community site.
How can I set the authorization level so that, the endpoints can only be accessible from the Salesforce Community and the salesforce Users?
Thanks
There are quite a few options available like App Service Authentication or using API management for authorizing requests.
Have a look at Securing Azure Functions - Authentication/authorization.
While function keys can provide some mitigation for unwanted access, the only way to truly secure your function endpoints is by implementing positive authentication of clients accessing your functions. You can then make authorization decisions based on identity.
I realize that AZURE APIMS has a lot out of the box. Including subscription based server-side authentication.
However, I would like to know:
What options are available for client apps which are browsers?
For example,
Assume I have a single backend API with a single endpoint. I want to expose this endpoint to external business partners who use browser based applications which make requests to the backend from client side (browser)
How can I achieve this using AZURE API management service?
APIM supports protecting your API with OAuth 2.0 which you can setup on your APIM instance and leverage in your browser-based applications.
Your application would first have to get the JWT token from your identity provider and then provide the same in requests to the APIM endpoint which are pre-validated using a policy.
Here are samples of applications using AzureAD (and its MSAL library) for authentication/authorization.
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.
I am finding it hard to understand how I can differentiate multiple client applications using oAuth 2.0.
Using APIM I mapped my backend webservice to Azure API Gateway Service URL. I have configured Oauth 2.0 with grant type as client credentials because its a service to service integration.
In Oauth registration, I have mapped my client and backend app Id's with secret keys - (OauthSample1.0).
It doesnot have the provision to configure multiple clients for the same backend service.
And, in my API, i can add only one Oauth reference - (OauthSample1.0). Even if i would go ahead and create multiple Oauth 2.0 references for different clients, technically it cannot work with the API configuration.
This means I can have my API validate only one specified client using one oAuth 2.0 reference.
If I want my API to be accessed by different partners / Client applications, my understanding is that I would need to create different Clients in Azure AD. But unfortunately not able to design the solution here.
The official doc for protecting your API using OAuth 2.0 covers the steps required in detail.
To summarize, the steps are
Register an application to represent the API
This app is setup to expose an API
Register separate applications to represent each of your client applications
These apps would also have a secret generated for the client credential flow
These apps would have been granted access to the exposed API
Setup a Validate JWT policy to pre-authorize requests.
Your clients would have to get the token using the client credentials flow before making the requests.
Also, if your clients are services that directly access the APIs, then you could setup app roles that show up as Application Permissions instead of Delegated Persmissions.
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.