Azure API Management /Azure function authentication approach? - azure

Confused on which type of authentication method to use for Azure API Management/Azure Functions:
User name & password(saving keys in keyvault)
Token(non expiring/expiring)
Subscription key
IP Filter
Oauth2
If we go with option 5:
Does grant_type,client_id,client_secret and scope are the required keys in order to generate the token? And can we encrypt the values before giving it to vendor?
How can we change the token authorization url from login.microsoftonline.com/tenanted to our dns? Do we need to use azure front door or is there any other option?

There's no unique/right answer based on what you've described. I usually recommend choosing one Identity Provider (IDP) (e.g. Azure AD) + Product Subscription at API Management.
Identity Provider will take care to generate auth token, and your Azure Function or API Management can validate against IDP to guarantee the token is valid and issued by the IDP.
If you'll charge based on API calls, you use the API Management Subscription Key to filter/count and charge properly the consumers of your API. Also, only callers with a valid Subscription Key will be able to consume your API.
Now answering your other two questions:
1-) If you're using Azure AD as IDP, then yes
2-) you can't, unless you'll use your own IdP (e.g. Identity Server)

Related

2 different auth types on .Net API?

We have a .net 5 API that runs as the backbone of our service.
Currently we have b2c set up within the API and our angular app to auth users.
But now we have a secondary daemon that needs to authorise onto the api to be able to do its thing.
What would be best practise to achieve this? Since we need to use client credentials and not user interaction.
• You can use the Azure Maps resource in Azure to ensure that a daemon app securely authenticates the API and authorizes it to do the thing. Azure Maps supports two authentication methods, viz., Azure Active Directory Authentication and Shared Key authentication. AAD method maps the ‘Client ID’, i.e., the service principal or the account used for REST API request to the application/API through it and the other method, i.e., shared key authentication uses primary and secondary key as the subscription key for it as it relies on passing the key generated by the Azure Maps account to each request in Azure Maps.
• For more information, you can surely refer to the documentation below on the detailed steps to follow for the efficient and correct use of the above stated methods for a secondary daemon app to authorize onto an API.
https://learn.microsoft.com/en-us/azure/azure-maps/how-to-secure-daemon-app
In the above link, shared key authentication with Azure key vault and Azure AD role based access control are discussed.

Sign in to Azure B2C with a Google Service Account

I'd like to start with a Google Service Account credential (either opaque access token or ID JWT) and end with an Azure B2C credential. Is something like this possible with Azure? I'm not seeing any APIs for doing it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/openid-connect
Note: this is conceptually similar (but different in terms of target identity) from another question I asked earlier:
Impersonate Azure Service Principal from a Google Service Account
EDIT: Our use case for this is exchanging Google Service Account credentials that represent an untrusted client (e.g. a user in the system), for a user token in Azure B2C. Unfortunately, this eliminates the client credentials flow, as mentioned in the comments.
Azure AD B2C only supports interactive federation flows with other identity providers.
Google service accounts are non interactive authentications. The only way AAD B2C can pass these credentials to Google would be through its REST API interface.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile
The credentials would need to be hard coded into the policy or through AAD B2C “policy keys”.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/secure-rest-api?tabs=windows&pivots=b2c-custom-policy
From what I can see, AAD B2C REST API interface doesn’t support an authentication method that Google needs. So I would conclude it’s not possible.

Azure API Management + Azure Function and managed identity

I'm trying to call an Azure function from an API Management instance by using Managed Identity.
I have set a System Managed Identity to my APIM instance.
I have granted the Contributor role to this identity on the Azure Function App.
I have also change the App Service Authentication to AD.
Now I'm trying to call the function from an API.
I have two issues:
First One: when I use the authentication-managed-identity policy to get a token, I got an error when I use the audience https://myfunctionapp.azurewebsites.net. AD tells me that this app is not registered in the tenant
Second: If I retrieve a token for https://management.azure.com, I got a token but I received a 401 Unauthorized error from the Azure Function.
Maybe I'm just trying to get a token on the wrong audience, but unfortunately the audience of functions is not listed in the document (for service bus for example, there is a common URI to use, also for KeyVault, ...).
I think that I probably missed something in the picture...
Thanks.
You need to use the authentication-managed-identity policy to authenticate with a backend service using the managed identity of the API Management service.
https://learn.microsoft.com/en-us/azure/api-management/api-management-authentication-policies#ManagedIdentity
EDIT
1-In your APIM application on Azure AD,
grab the Application ID assigned for enterprise application.
2-Then go to Platform features in your Azure Function App, and click on Authentication / Authorization.
3-Select Azure Active Directory as the authentication provider, and the management mode "express".
4-Back to authentication-managed-identity policy, set the Application ID from step 1 as the resource.
you need to add the url in apim required resource. If you're planning to use delegated flow. To check if the issue is with the url registration you can use the AppId instead. This will at least tell you if the token can be retrieved.

Microsoft Azure OAUTH2.0 - How can Multiple Source Clients call Azure OAUTH2.0 authentication

I create an Azure APIM instance, register it as an app in AD and then create a OAUTH2.0 server under APIM which is setup using the clientid/secret key of above registered app. I make a dummy API under this APIM and then protect it with this OAUTH2.0 server. I also add a JWT policy on my api to look for a token and authenticate against the tenant-id.(No claims mentioned).
Now lets say, i have a Customer (ABC) and for that i register another app in AD and create its Clientid/secret. Customer generates its token with the help of token endpoint (this endpoint is given under Endpoints tab of AD app registration option). Customer calls the API with this token and it works.
Issue: I didn't give any permission for my APIM App in AD to the Client App in AD but it still works, which essentially means that any Clientid/secret from any app registered in AD will go through my JWT policy of the API. Because it is just validating against the tenantid. How can we stop this and make sure that it works only for a customer to which permissions is given.
This is one of the major things I mentioned in my recent article: https://joonasw.net/view/azure-ad-authentication-aspnet-core-api-part-1.
Any app of type Web App/API in Azure AD can get a valid access token for any API in that Azure AD tenant.
Even before any permissions are given to it.
This is kind of a "feature" I guess.
Quote from the article:
If you only require an authenticated user, any confidential client in your Azure AD can acquire an access token for your API and call it. So it is important that you implement the user_impersonation scope check at minimum.
Now since your caller will call your API as itself, you need to implement an App Permission.
You can see how those are defined here: https://joonasw.net/view/defining-permissions-and-roles-in-aad.
Then implement a check that ensures the roles claim contains the value of the app permission you defined.
The claim will be a string array, so some kind of contains check needs to be made.
This will then require that this app permission is granted the caller before they can make the call successfully.
If you also want to allow delegated calls (i.e. calls on behalf of a user),
then add an optional requirement for the user_impersonation scope.
Those are stored in a single string claim (scp), space-separated.
So for that one you'll need a contains check on the string.

Azure API Management Client Authentication

I have an API Management resource on Azure which uses an API running as a Kubernetes cluster.
I want to have OAuth2.0 authentication for clients/applications which connect to the API management URL. I do not want any user authentication, but only want clients which want to use the URL to send a client ID and client Secret.
How do I do this?
I could not find anything related to this in the documentation.
If you dont want user context to be involved, You must prepare client credential flow from Oauth2.0 which uses client id and client secret.
I am explaining using Azure AD.
1) Create Application in Azure AD and get client id and secret
(https://www.netiq.com/communities/cool-solutions/creating-application-client-id-client-secret-microsoft-azure-new-portal/)
2) Call token end point of Azure AD to get secured token
(https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service)
3) Pass this token to APIM using authorize or from any header
4) Validate JWT and check issuer,audience and application level scopes
(https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT)
No sure what exactly are you asking!
But here are two places where you will find a solution to your question:
How to secure your backend apis: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
API Management access restriction policies: https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies. More specific here check the Validate JWT (https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT)

Resources