We are trying to deploy our legacy webforms app to azure.
Our application security model is based around Window Active Directory.
1 For a site hosted in Azure, what is the equivalent c# code for this:
WindowsIdentity.GetCurrent().Name;
This articles demonstrates using "OWIN" middleware.
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-aspnet-webapp. Am i on the right track?
2 Since my localhost isn't hosted on Azure (it' running under IIS Express), what's an alternative to using this everywhere:
if (debugMode or localhost) then WindowsIdentity.GetCurrent().Name
else Azure-AD-equivalent-code.
For a site hosted in Azure, what is the equivalent c# code for this: WindowsIdentity.GetCurrent().Name;
It seems that you using the Azure WebApp service, if it is that case, unfortunately, we can't use the Windows Authentication in azure WebApp service.
Maybe Azure Web Sites Azure Actice Directy is the best option. Sync from AD to Azure Actice Directy is also quite easy to setup. Then use Azure Easy Authentication to do that.
If you still want to use the Windows Authentication, I recommand that you could use the Azure VM. You need to join the VM to your AD.
Related
We have a web application that we have hosted as an app service in Azure.In this we are using excel.interop services. Would like to know whether we will we able to retain the same code in the application after hosting it on azure.
As far as I know, if we want to use Microsoft.Office.Interop.Excel, we should install MS office. But it seems that Azure App Service does not support it.
I recommend two workarounds:
Use Azure VM to host the application and install MS office on the Azure VM, you refer to this article.
Instead of excel.interop, use OpenXML to do it, you could refer to this article.
Hope it helpful.
You can "containerize" your application as a container and run it in App Service as a Windows Container App (this feature is still in preview).
https://azure.microsoft.com/en-us/blog/announcing-the-public-preview-of-windows-container-support-in-azure-app-service/
https://azure.microsoft.com/en-us/updates/windows-server-2019-support-added-to-public-preview-of-windows-container-support/
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-get-started-windows-container
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-windows-containers-custom-fonts
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
Because of the limited region availability of deploying Azure Mobile Services, I am investigating deploying the service to Azure Websites. I can deploy the service to a website using the deployment profile easy enough and everything seems to work.
I was just wondering if anyone has had any experience in doing so? Limitations compared to the official Mobile Service hosted deployment? And any specific required changes to typical code?
Having implemented this and using it for the past few months, these are the results I found.
Minimal changes are needed except manually specifying config values as app settings vs the mobile services configuration. I am using Azure AD authentication and the required keys to be configured in Azure websites app settings were
MS_MobileServiceName
MS_MobileServiceDomainSuffix
MS_MasterKey
MS_ApplicationKey
MS_AadClientId
MS_AadTenants
MS_AadAudience
I wrote about the changes here https://pontifex.azurewebsites.net/azure-mobile-services-hosted-in-azure-websites/
Current my company delivers our software to our customers through a Citrix Xenapp Server. As administrators we are able to launch instances of the servers and our customers are only able to launch their specific application
My Question is does Windows Azure also offer this type of environment. I am looking to deploy a new version of our application and I am leaning towards Azure, but if that is the direction we go in I would like to migrate all of our existing system to Azure and not maintain both Azure and Citrix.
Greg,
In principle yes you can do this, but you can't just plug in Azure as a direct replacement for XenApp (with zero/minimal effort). Azure effectively has it's own runtime. While it is Windows based and there is certainly potential to reuse code in an existing app in an Azure equivalent, you would need to re-write your app to make it run in Azure.
Given your app is running on XenApp it is likely it is a fat client app, i.e. most of its logic lives in the main executable that you run on XenApp, with potentially some other back end services being utilised. In comparison you should think of Azure as a platform for providing web apps. So you would re-architect the app as an Azure hosted web app, then you could deploy it via Azure in a multi-tenanted manner to your customers who would then access it through a browser rather than a Citrix Receiver.
Regards,
Donovan
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.