Can a user of my web application access the executable of my Azure WebJob by any means in order to steal code or any other such information in files that were deployed alongside with the WebJob?
No, that is not possible. Only the owner/contributors of the containing Web App have access to the files (the same people who can publish).
Related
I need two applications hosted on two Azure App Services to access one specific file(.xml). What is my best option? What are my options?
I am trying to implement: Share authentication cookies among ASP.NET apps.
Both apps have to access the COMMON KEY RING FOLDER with the key file.
One of the applications is ASP.NET MVC, the second one is ASP.NET Core, both run on .NET472
Edit:
I need a file to be accessible for two .net applications running as appservices. I will use C#/F# to read/write the file. The file must be on Azure.
I recomend you to use an Azure Blob Storage and read the xml from there.
https://learn.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-dotnet
We use a app builder to create our applications, download them as .zip, and then just click "Add Application" on IIS, point to the application folder and it would be working.
Our applications require no server logic or database, they are self contained, the database is external and acessed via REST on javascript.
I can't seem to find the equivalent of the above procedure on Azure, it has options like Python/Node/Java/.NET but I'm not sure which of these fit our application needs.
How can I just easily upload a web app on Azure without any backend required?
If I'm understanding your question correctly, you can drag/drop a zip file into the "kudu" console of an Azure webapp to upload the file. Azure takes care of unzipping the file and putting the files in the web app.
To get to that portal, change your web app url to contain ".scm." and append /ZipDeploy to the end of the url:
https://yourwebapp.scm.azurewebsites.net/zipdeploy
Then drag/drop your file onto the web page.
From the main kudu page (remove zipdeploy from your url) you can upload entire directories of files if you need to. I regularly deploy webapps this way and it works great.
One of the easiest approaches is to make use of Azure App Services. This is Azure's Platform as a Service (Paas) offering that allows you to get a web site up fairly quickly whether that be a static site that is mostly client side logic or your more traditional apps such as asp.net\php\etc. You can deploy your app through various means from CI\CD, Github, FTP, etc. You can find more details and a 5 minute quickstart at https://learn.microsoft.com/en-us/azure/app-service/.
More recently Azure has offered the ability to host static web sites right in Azure's Blob storage. It doesn't come with all the features of Azure App Services and does not have any server side execution but has the advantage of price and simplicity and when used in concert with some CDN networks it can be attractive for static client side only sites. More details at https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website
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.
I work for a network management company and I want to write a .Net application (MVC 4) that will allow us to service Active Directory users from a cloud-based application.
As I have never written a cloud-based app, I don't know if I'm using that term correctly or not. I am in the requirements gathering stage. Basically, I'd like to provide our customers with the ability, for example, to change their own password using our cloud-based application.
is this an application that should be written specifically using Azure? If not, what tools and platform(s) should I take into consideration?
What tutorials or other resources are available ?
Actually, I don't even know enough about Active Directory and Cloud computing to ask the right questions. But, I hope someone will point me in the right direction
Read How to Authenticate Web Users with Windows Azure Active Directory Access Control. There are great walk-throughs there. There is more reading and code samples here - Access Control Service 2.0.
That's using ACS.
You could go direct to Azure Active Directory if you wished?
Refer: Adding Sign-On to Your Web Application Using Windows Azure AD.
If you use Office 365, you already have an AAD tenant.
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.