I'm currently looking into using WCF to communicate between a server and a program that acts as a facade for a legacy system.
Quick overview: user <-> ASP .NET web pages <-> WCF <-> facade program <-> legacy system
I don't want to run IIS with the rights required to run the facade program so I was thinking about using WCF to communicate between the two pieces of software.
Is this possible? Should I be using something other than WCF to communicate between the two .NET projects?
I would do a socket connection. Frontend listening to a port, the .NET web page connect to it and trade data... no worries about user level at all.
I don't see any immediate issues with this approach - WCF is generally the best choice for inter-process / inter-machine communication in .NET due to the vast array of options it supports via configuration.
In terms of authenticating IIS -> WCF service, you could just start with default Windows authentication provided by the WCF client proxy. IIS will connect to the WCF service using Network Service credentials, which should authenticate automatically on the same machine.
If you are hosting the WCF service on a different machine you will need to map the Network Service account on the IIS machine to the machine where the service is hosted using the computer account name which is in the form DOMAIN\COMPUTERNAME$.
Alternatively, you can initialize your own NetworkCredentials instance on the client proxy for a specific domain account. This is less secure as you have to include the password in your code, but it tends to be easier to use in practice.
The WCF service host process can run using a different process identity, and use that process identity for executing downstream components.