Current implementation:
Single-instance WebApp with custom authentication (own DB) and custom server-based token management (matching session-token-user in an in-memory table).
Desired implementation:
Multiple WebApp instances behind Azure Application Gateway as a load balancer and URL router. Still with custom authentication. Token handling: ????? (preferably JWT)
As this will be a multi-tenant service, we don't want to use AD.
Questions:
What would be the best way to implement this scenario? Where we can keep track of users vs. tokens? This is, considering that now many servers need to verify the token. An in-memory table is not suitable anymore, unless it can be done inside the Gateway instance.
Does this has to be done programmatically (like now), or there is a configurable mechanism in Gateway or some other Azure service?
Application Gateway does not support authentication with AD. It also definitely does not support custom authentication. Hence the authentication and authorization has to be done at the backend servers. The solution would require a distributed cache where tokens are kept, which is accessible to all backend servers. You could use Azure Redis Cache for this.
Related
My web application's endpoints are all secured and demand an OAuth access token.
To my understanding, Azure App Services Health Check is done through a HTTP call:
https://azure.github.io/AppService/2020/08/24/healthcheck-on-app-service.html
Exposing a path like /api/health can be used for attacks like DOS.
How exposing the path /api/health is justified from the security perspective?
What is a secured way of using App Services' Health Check ?
The Azure platform itself does have some mitigations to circumvent DDoS attacks. However, you can add additional layers of protection such as DDoS, App Gateway, and WAF.
Remember though, that if you're using App Service Authentication, the platform will utilize that to send authenticated requests to your configured health check API endpoint. But from a secured way to use health check, you would make sure that your endpoint only accepts authenticated requests.
I have been looking at various tutorials demoing how identity management works as well as API management in azure but I am not seeing an answer to my questions. I understand that managed identities can be used to authorize azure resource to resource communication but I am not seeing how this is done for a web application. Say for example I have an angular website being hosted on an nginx server in an AKS cluster. I understand that I could use Identity management to create Identity resources that make it so that the AKS and APIM are authorized to connect with one another but how would I do this for the angular running application? This application is running in the client's browser, so it seems like this identity management mechanism would not work. How does one secure an APIM so only a given web application can interact with it?
You could secure your API in APIM with the client certificate, then when the app access the API, validate the incoming certificate and check certificate properties against desired values using policy expressions.
For more details, see How to secure APIs using client certificate authentication in API Management.
I have a website on the namecheap server and an application on microsft azure deploy on Azure App Service I would like to send post requests from my namecheap server to azure which contains the application my questionis this possible and also isn't there a security risk?
thank you for your help
Web programs are accessed through HTTP Requests. The security risk you mentioned does not exist.
In webapp, the security of web application data is what we need to care about.
After passing the authentication, the data can be curd according to the authority to ensure the security of the program.
It is recommended that you deploy the azure webapp program to increase the authentication function, such as jwt token.
I'd like to connect to an On-Prem API from an external cloud service using the Azure AD Application Proxy. I can connect and use the API by logging in with my Azure AD User in a browser, but would like a code-based-like login to use from my external service.
I've been digging through various articles the last couple of days, and it seems not possible without an Azure AD User interactive login. I am able to create an AD user for this service only if needed, but handling the interactive login from code or even through Postman seems troublesome.
Can someone point me in the right direction to solve this cloud-service to on-prem app solution? (unfortunately, I can't move the on-prem app to Azure).
EDIT: I'll be looking at using the pass-through option in the App registration, which means i need to handle the authentication and security in my API.
Perhaps you could consider using an on-premises data gateway instead, but it depends on where your external cloud service is hosted.
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-install
Essentially, if your external cloud service is completely outside your environment and your control, the data gateway can still be used, then you can expose a Logic App as a facade that can integrate with the on-premises data gateway. The external cloud service can then call the logic app to trigger the request, which can be secured by other means e.g. SAS key.
I have multiple Web APIs deployed in Azure without applying authentication, so anyone has access to internet has the access to the Web APIs.
Now I would like to apply authentications to the Web APIs, instead of implementing the same authentication logic in different Web APIs, I found Azure API gateway (API management) is a potential solution.
With Azure API management documentation, I learned I can apply policies like validate-jwt to authenticate requests to back end Web APIs. However, endpoints of the back end Web APIs are still available to users.
So, how should I hide them? Must I define a sub network or does Azure API management have a feature for this?
Recently I also had this same problem. Finally I found the solution by using 'IP Restrictions' function. See the following steps:
1) Go to your API management Overview page in Azure portal, copy the VIP.
2) In your Web APP > Networking
3) Paste in your VIP
Microsoft's Solution: How to secure back-end services using client certificate authentication in Azure API Management
Using this approach, any attempt to access a back-end service without the required certificate will result in a 403 - Forbidden response.
You can use a self-signed certificate as opposed to using a trusted CA signed certificate ($$). I chose to implement an Azure Key Vault where I generated a new certificate, downloaded it as a *.PFX file, and uploaded it into my API Management instance as described in the article.
Here is an answer from #PramodValavala-MSFT
https://github.com/MicrosoftDocs/azure-docs/issues/26312#issuecomment-470105156
Here are options:
IP restrictions (as described by #redman)
Function keys
Authentication/Authorization for Functions
Managed Identity for APIM
p.s. in my case I want with IP restrictions since it allows to keep all of the auth on the API Management Gateway.
Or you could use:
Basic auth
Mutual certificate auth
VPN
to secure Azure API Management service communication with your backend service.
Look into setting up TLS on Azure API Management so that all connections to your backend API must come through the API proxy.
Azure API management cannot modify your backend service. It's role is limited to being a proxy.
You will have to apply authentications to each Web API or configure your firewall to accept requests only from Azure APIM.
Is your backend app an Azure Function app or an App Service app?
If so, Managed Identity may be the simplest way to restrict access. No need to store client secrets/certificates in the API Management + not as flaky as IP whitelisting method.
Create an Azure Active Directory Application for the Function App.
Enable Authentication/Authorization module on the Function App and reference the AAD app from step 1.
Enable a Managed Identity on the APIM instance.
Add a <authentication-managed-identity> policy to the APIM and reference the AAD app from step 1.
I've blogged about this approach in more detail in Restrict Azure Functions to API Management with Terraform
Reference:
Use managed identities in Azure API Management
Configure your App Service or Azure Functions app to use Azure AD login