We want to switch our ASP.NET MVC application from Azure Cloud Service to Azure App Service (web app). The application is currently using WIF as its identity framework, and as it is running in a farm configuration, we configured a custom SessionSecurityTokenHandler which encrypts the session cookie using a certificate (thus the cookie can be decrypted by all instances of the web farm).
We could provision this certificate in the Cloud Service scenario using the csdef/cscfg files and the built-in Azure certificate store associated with the Cloud Service, but there is no such thing with Azure App Services (unless I missed something).
Is there any way to configure a certificate in the App Service? Should we fall back to another mechanism to encrypt the session cookie, such as a shared machine key? The machine key is not an ideal solution as it forces us to leave some configuration out of source control to avoid leaking the key.
Using the Azure portal (https://portal.azure.com), open the web app blade for your web app and click on the Settings button in the toolbar.
In the Settings blade, click on Custom domains and SSL. In the Custom domains and SSL blade click on the Upload Certificate button in the toolbar. This will open a blade where you can upload the certificate.
In the web app settings blade, you will need to add an app settings using the key WEBSITE_LOAD_CERTIFICATES. You can set the value to * to load all certificates or if you want to specify a specific certificate you could do that.
From there, you can use the certificate like you would in your cloud service version of the application. Some additional information on this and how to use the certificate in code is available here if you need it.
Finally, to Michael B's point in the comments, using Azure Key Vault would be another approach you could take and would provide some additional security.
Related
I recently installed the Azure AD Application Proxy connector on my company's internal server using Microsoft's tutorial. I have a Blazor application configured to use Azure AD authentication setup on this server, using all the default Microsoft Identity authentication code when initially creating the Blazor app, all I did was fill out the app settings for my tenant/client IDs. I have configured the Enterprise Application within Azure for this app to use the newly created application proxy with the pre-authentication set to passthrough. For simplicity's sake, let's say my internal URL for my web app is "myapp.domain.local" and my external URL (which is the default msappproxy URL) is "myapp-company.msappproxy.net". I have also configured the authentication section of the App Registration to use the following redirect URIs (my app's callback path is /signin-oidc):
https://myapp.domain.local/signin-oidc
https://myapp-company.msappproxy.net/signin-oidc
The problem I am encountering is when I try to access my app from the browser using the app proxy URL (myapp-company.msappproxy.net), the authentication configured on the app (not the pre-authentication for the app proxy) seems to be redirecting back to the internal URL (myapp.domain.local), rather than using the proxy URL that I had originally used to access the web app. Obviously this will not work when connected to a device off of our internal network. I do not want to disable authentication within my app and enable Azure AD authentication for the pre-authentication of the application proxy. I simply want the app's authentication to redirect to the app proxy's URL instead. Is there any way to achieve this?
To enable Application Proxy on your app service, you should be Global Administrator.
Open Azure Portal > Click on Azure Active Directory > Select Application Policy - click on Yes to enable.
Configure the application proxy connector by downloading and installing it. During the installation, it asks for Azure login details. Provide an account which have azure global admin privileges.
To publish the application: Go to Azure AD > Enterprise Applications > Click on New Application > All > On-premises application and provide configuration data for that application in that window like below:
After adding the information, click on Add and Publish.
Add users and assign the access to it.
After logging to it, the application shows like:
For more information, refer here and how to access the web apps via application proxy.
I have an application that runs in a Service Fabric(SF) cluster and I wan't to access Key Vault from it.
The cluster hosts a number of applications and I want to give access to a Key Vault for my application without giving access to the other applications. By default an application runs under the same user as the SF cluster, but each applicatiuon has it's own unique name, mine has the name fabric:/application1.
My question is, is it possible to create an Active Directory application account for fabric:/application1 and grant access to the key vault?
I know it is possible to use the RunAs options in the SF manifest, but that requires me storing an encrypted password in the manifest/source code and I want to try and avoid this if possible.
AFAIK,
The only way to have this flexibility is using ClientID & Secret or Service Principal certificates and each application manage their own credentials.
Service Principal Certificate is already integrated to AD, but does not require the application, the user or the Host to be part of the domain, the only requirement is setup an user on AD to grant the permissions on Keyvault.
There are other solutions using AD integration, like Managed identities for Azure resources(Former: Managed Service Identity) but I am not sure if you are able to restrict access per application like you described, because the MI add this as a service in the node, so technically other applicaitons would have access as well, worth a try to validate if you can restrict this.
If you want to try this approach, you can use with Microsoft.Azure.Services.AppAuthentication for implicit authentication of the services running in your cluster, where the nodes are setup with Managed Identities extension like described here.
Something link this:
When you use the Microsoft.Azure.Services.AppAuthentication, the Step 2 will be handled by the library and you won't have to add much changes to your key vault auth logic.
When you run your code on an Azure App Service or an Azure VM with a
managed identity enabled, the library automatically uses the managed
identity. No code changes are required.
The following docs describe other options you can use for KeyVault Authentication.
PS: I've done other KeyVault integrations using Client Secrets and Certificates and they are secure enough, With Certificates you can store it on the managed store or with the application, I would recommend MI only if is a requirement for your solution.
I am using .NET Core 2.0 and ASP.NET Core 2.0 for application development. The "test" application is a .NET Core Console application. The core code I am writing is a class library. Once proper testing. I choose to do this since I won't be putting this to use for awhile (it's replacing older ASPNET code).
Anyway, since I have to work with a LOT of API keys for various services I decided to use Microsoft Azure Key Vault for storing the keys. I have this all setup and understand how this works. The test application uses a test Azure account so it's not critical. And since this is replacing legacy code and it's in the infancy, I am the sole developer.
Basically, I'm running into this issue. There's not too much information on Azure Key Vault from what I can see. A lot of examples are storing the Client ID and Secret in a plain text json file (for example: https://www.humankode.com/asp-net-core/how-to-store-secrets-in-azure-key-vault-using-net-core). I really don't understand how this can be secure. If someone were to get those keys they could easily access stored information Azure, right?
The Microsoft MSDN has a powershell command that grants access (I lost the original link, this is closest I can find: https://www.red-gate.com/simple-talk/cloud/platform-as-a-service/setting-up-and-configuring-an-azure-key-vault/) My development operating system is Windows 10 and my primary server operating system is Debian.
How would I approach this?
Yes, you are right, the plain text config file could be used only during development, not for production purpose. And in general, available options depend on where and how you host an App.
If you have an Azure Web App, you have at least next built-in options (from the documentation):
add the ClientId and ClientSecret values for the AppSettings in the Azure portal. By doing this, the actual values will not be in the web.config but protected via the Portal where you have separate access control capabilities. These values will be substituted for the values that you entered in your web.config. Make sure that the names are the same.
authenticate an Azure AD application is by using a Client ID and a Certificate instead of a Client ID and Client Secret. Following are the steps to use a Certificate in an Azure Web App:
Get or Create a Certificate
Associate the Certificate with an Azure AD application
Add code to your Web App to use the Certificate
Add a Certificate to your Web App
You may also find an approach that uses env variables to store credentials. This may be OK only if you can guarantee that it's not possible to do a snapshot of env variable on prod machine. Look into Environment Variables Considered Harmful for Your Secrets for more details.
And the last one thing: there is also a technic that based on the idea, that you need to store/pass only a ClientSecret value while ClientId should be constructed based on machine/container details where the App is hosted (e.g. docker container id). I have found an example for Hashicorp Vault and an App hosted on AWS, but the general idea is the same: Secret management with Vault
In addition to the first answer, with the context of running applications on Azure VM, instead of using client_secret to authenticate, you can use client certificate authentication as explained in this documentation: Authenticate with a Certificate instead of a Client Secret.
In the picture above:
Application is authenticating to AAD by proving that it has the private key of the certificate (which is basically stored in CNG if you are using Windows).
Application get back the access_token and then use it to access the Key Vault.
The developer does not need to know the private key value of the certificate in order for their app to be successfully authenticated. Instead, they only need to know the location of the imported pfx (a container for private key and its certificate) in the Certificate Store.
At least on Windows, you as secret administrator can convert the private key and the certificate into pfx format which is password protected, and then deploy it into the Windows Certificate store. This way no one could know the private key unless they know the password of the pfx file.
The other approach specifics for Azure Compute, is to use Azure Managed Service Identity. Using Azure MSI, Azure will automatically assign your resources such as VM with an identity / Service Principal, and you can fire requests at a specific endpoint that are only accessible by your resource to get the access_token. But be wary that Azure MSI are still under public preview, so please review the known issues before using it.
The picture above explain how Azure Resource Manager assign a Service Principal identity to your VM.
When you enable MSI in a VM, Azure will create a service principal in your AAD.
Azure will then deploy a new MSI VM extension to your VM. This provides an endpoint at http://localhost:50432/oauth2/token to be used to get the access_token for the service principal.
You can then use the access_token to access the resources such as Key Vault which authorize the service principal access.
I have a ASP.Net WebAPI service that is used by my AngularJS front end and I am making use of Owin and bearer token.
Now there is a need that we need to install an agent on the few of the client machines (developed in .Net core mostly) that is able to connect to our application and make similar calls. I can create a separate controller for this need, but want to host it in the same website.
How can I create a secure connection between this agent and the ASP.Net server hosted on Azure?
Currently I am looking at generating a Token during the agent installation based on the client MAC address and giving it with each call, but I am checking if there are any better way to address this need.
Any help in this direction is welcome.
Regards
Kiran
It seems that you’d like to enable only valid “agents” that installed on the client machines to communicate with your server, if that is the case, Azure AD provides Native Application to Web API authentication scenario (a native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD), you could refer to it.
I deployed my MVC 4 application on Azure, installed own CA, create self-signed certificate and certificate for server (https working good). How can I activate require client certificates signed by my CA and working only with it?
The two viable options you have, you already described in your comments.
One is to use Azure VM and IIS (I don't like it) - there you know what to do.
The other one is to use a Web Role (Cloud Service) and do the things described in the link you refer to. I advise you to take the Web Role path.
Or third option, is to wait until (if ever) Windows Azure Web Sites to unlock the required property in application host config. Check this SO question and it's answer on what you need to do in your web.config in order to achieve your goal. The catch is that access section under system.webServer/security is locked at application host config level, and can only be unlocked when you have Azure Web Role.
Just fyi, here is a list of overridable sections in your web.config when you use Azure Web Sites.