We have an Azure function with html UI right inside the function. The Azure function app has VNET access to servers inside our firewall. Possible to build an Azure Function that authenticates into the server/file share and allows a browser user to download a secure network file?
If so, Possible without creating new files?
If your Azure Function is configured to be on a VNET that gets you the network access you need to the servers behind your firewall then it's possible, but the question is what protocol are you expecting to use to access those files? Azure Functions run inside the App Service "Sandbox" which has restricted outbound network port access which would prevent the standard file sharing protocols from working. If you exposed the on-prem files over HTTP in some way, then you'd be in business.
One dirt simple way might be to mount the file share as an IIS virtual directory. You do still have to consider security though. You won't be able to use Windows Authentication, but you could change the IIS virtual directory to use something like Basic Authentication and then your function would be configured with the necessary credentials to access it. Then you get into transport level security and realize you'll want to use HTTPS which implies setting up some certificates as well.
Another solution would actually be to look into using Azure Files to actually synchronize the on-prem files into the cloud as a completely separate integration and then systems like your functions app here actually only worry about accessing the files via Azure Files and don't even have to necessarily be bound to the VNET at all at that point.
I'm not sure what you mean by "possible without creating new files" though. Can you elaborate on your scenario a little more? You would probably need other functions in your app to perform the individual responsibilities of file transfers (e.g. handle POSTs, GETs, etc) if that's what you mean.
Related
If a particular computer is making tons of accounts or flooding my server with other requests, could parse-server automatically check this behaviour and block the specified IP address?
Built-in rate limiting would also be a nice alternative, although it doesn't really solve the problem if the person continues to spam.
I am hosting on google app engine by the way.
I don't know about Parse itself, but from App Engine side you have DoS protection service controlled via dos.yaml file in your project that lets you blacklist IP blocks—sounds like that may help. It's not "automatic", though; you still need to manually update this file and issue appcfg.py update_dos <PROJECT_DIR> for changes to take effect.
I don't believe that this is a feature out of the box - see advanced options here: https://github.com/ParsePlatform/parse-server.
You'd need to look at controlling access to the Google App Engine (or another host - such as Microsoft Azure Web App) using a firewall (you can easily do this with Azure. I'm not familiar with Google App Engine, but imagine similar functionality is available.
However, I don't believe that a firewall is necessary - just better app security. Disable anonymous users - Parse Server Security
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
Is it possible to create a google app engine program that would route http requests to a server on a local network?
What would be the best way to build a program like this?
I am trying to get away from buying a server from a hosting provider and simply use a local network server instead, and use google apps as a sort of proxy. The firewall would be configured to allow access to the server from the google app engine servers only.
If this has been done before in an open source project that would be excellent, but I have not been able to find one.
If all you want is a domain name that points to your dynamic IP address, you could give Dynamic DNS a try. It's designed for your use case, and you won't need to write any code; you just need either a router that supports it or a server with cron. There are lots of providers, but I've had good experiences with Dyn DNS, specifically their Remote Access plan.
The design of the current app I'm working on calls for a WCF Service, hosted in a Windows Service, that pulls data and stores it on the hard drive. It pairs with a windows forms application that will interact with the WCF Service. One of the requirements is that the end user be able to restart the windows service through the Forms app.
So, I'm guessing this can be done using the ServiceController class... but what about permissions? I don't think we can (or should) guarantee that the windows app runs as admin, and the service is running as a Network Service.
The only thing I've seen that reasonably seems to cover the situation is having another windows service running, which could then be installed under an account with higher permissions, which you could call to restart the target service.
BUT I don't want to add that much complexity to the project, especially since it was supposed to be in beta last week.
So is there a way I can just give the Forms app the necessary permissions to restart it's specific companion service?
The follow-up question is down the line we might make it so the service runs on a server rather than the same machine as the app. Would this make it impractical to allow a Forms app to restart the service? If so I may advocate cutting the feature...
Oh, and should note that the target platforms are WinXP and Win7 with .NET4.
Instead of giving permissions to the app, you can assign permissions to the service to be started and stopped.
Every windows service has a security descriptor that is assigned a permissions what you are allowed to do on the service. By default service has permissions for authenticated users to read services state, and for admins to control the service, as well as delete it.
You can set service security descriptor using command sc sdset <serviceName>. For example this command will allow any user to control service (but only admins and Local system are allowed to delete service or change security on the service):
sd sdset <myservice> "D:(A;;CCLCSWRPWPDTLOCRSDRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)"
You might want to tweak the security descriptor a bit if you want to allow only a specific account to be used to control the service. This would work remotely as well, as long as the remote account is authenticated by the machine.
How about making the service responsible for restarting itself? It could expose a method, Restart(string userId, string password) or something similar.
On being called by an authorised user, it could use the approach outlined in this answer. That is:
Set the service to restart on failure
Call Environment.Exit(1)
OS restarts the service for you.
You would call Environment.Exit(0) if didn't want to restart.
I've got a Silverlight application that will be running out on the open internet, available to basically everyone who has ever lived.
The application makes use of RIA Services to manipulate data in a database on the server.
The application creates, reads, updates, and deletes data of different varieties, however I only want these operations to occur from within the application.
This brings about two questions:
Is there a particular recommendation for what type of Authentication to use? Forms or Windows?
Is there a way to prevent someone from "linking" to the application? That is to say, copying the HTML from the containing page, pasting it in their own HTML page on their local machine and running it? The end goal would be to only allow the application to be run when it is embedded in a page requested directly from my server and my server alone?
If your application is being used on an internal network, then Windows authentication is best. Otherwise (as is your case) use Forms authentication.
Silverlight automatically prevents applications (unless they're running with elevated trust) from accessing resources on the Internet (web services, HTML, etc) that are not from the domain that the application originated from, unless that domain has a cross-domain policy file in its root. The Silverlight runtime prevents this (not the server), so this a client based security feature - not server based. By not having a cross-domain policy file in place on your server, your application will only be able to communicate with your domain services when it is run from your server (as you are after). The application will run, but calls to those services will fail.
You could always do a check for what domain the application originated from in code, and match it to a hard-coded domain name if you want to prevent the application running at all from other domains.
Hope this helps...
Chris