Okay, so it's been a lot longer between the last post and this one than I had planned. Life does that to you sometimes. I'm afraid that I'll also be even more sporatic over the next several weeks as I have (a) vacation, (b) business trip and (c) NIWeek 2006...
But, let's talk now about the issue of security when using ASP.NET and LabVIEW via the ActiveX interface.
The previous post covered getting to the DCOM configuration screen, so I'll assume you're there now, with the LabVIEW Application property page up. You'll notice that the last tab on the property window is the Identity tab. Click on this and you'll see you have three choices.
- The interactive user
- The launching user
- This user
The first one is really only useful when you are only going to call the ActiveX interface when you're logged into the machine. If you aren't logged in, there is no interactive user and so the attempt fails. However, if you want to have a copy of LabVIEW running in front of you and want to access it via the ASP.NET page, this is the option you want to pick. Kinda a special case for ASP.NET systems.
The second option is launching user, which is the default selection. This means that whatever process was used to launch LabVIEW via the ActiveX interface is going to share it's user setting. In the case of ASP.NET, which runs under the ASPNET user account, LabVIEW is going to be launched under the ASPNET user account.
The last choice allows you to select any user account in the system (as long as you have the password). This is the best choice for good security, as I'll explain, but is a bit more complicated to set up.
So, what should you pick? Well, you should think defensibly whenever dealing with a web application. Start by assuming that it is going to get hacked. Thus some evil-doer is going to break in through your website and attempt to do things on your computer...how much authority should they have? Well, the ASPNET account is a pretty limited account by default, so it's actually not a bad account choice. This means leaving the DCOM Identity setting as default.
However, you'll probably find that the ASPNET account doesn't have enough security privileges to do everything that you need it to do in your LabVIEW code. In this case, do NOT give ASPNET more permissions! Again, that is simply giving your eventual hacker more privileges. You also don't want to switch to interactive user. Not only does this require that you are logged into the machine (and why should you be if it's a website?), but it also means that the hacker becomes you inside your network. Not a pretty thought, eh?
So that leaves the "This user" choice. So, which user do you pick?
The right answer is "the one you create". A common technique for server applications is to create a custom Windows user account for the sole use of the application - in this case, LabVIEW running on behalf of ActiveX clients. Now you can use standard Windows security to restrict the user account to only the things it must have in order to do its job. Start by creating a basic user account and restricting its ability to access anything on the file system (even read permission) to just the LabVIEW directory and the Windows directory. These should be read-only accesses. Anything that it needs to write to should be carefully isolated from the rest of the files and write-permission given only to that directory.
What else should you grant? That's a hard thing to say up front - you're creating a program that can do just about anything, so it really depends on what you need. Unfortunately, it requires a bit of trial-n-error and an understanding of Windows access rights. If your application is going to be in a high threat area (re: accessible from the internet), I strongly recommend talking to your IT department for their help in locking down your application and the associated user account.
If you have any questions, please feel free to post them or email them. I can't claim I'm an expert in all things Windows security, but I can hopefully handle many of your questions.
Comments