How to use WCF NetNamedPipesBinding for communication between processes only in same users' logon session?

I'd like to have two processes running within the same use开发者_运维百科r's logon session communicate via WCF. NetNamedPipesBinding seems the most appropriate for this. BUT there could be multiple users logged in and running these processes, so I want a way to ensure each process only talks to other processes in the same user's logon session. Also each user could in theory be logged in to the same machine more than once - again here the processes in different logon sessions should not talk to each other.

I'm not particularly concerned with security (unlike this question), it's just a matter of having a way so each process only talks to the other process within the same user session.

One solution would be to add a unique logon session id to the endpoint address, but I'm not sure how to get a unique logon session (see my question on this here). I thought there might be some way baked into WCF for this, or a standard way of approaching this.

---

If you can be sure that:

1. the processes are never run with elevated privileges (Run As Administrator); and
2. You'll always be running on Vista/Win7 or later

then you will get what you want by default using WCF.

This is because the shared memory mechanism by used by NetNamedPipeBinding to publish the actual pipe name (which is based on a GUID) is automatically scoped by logon session if the process hosting the WCF service does not have sufficient privilege (SeCreateGlobalPrivilege) to make it globally visible: the named shared memory region is put in the "Global" kernel namespace only if the process has this privilege, otherwise it is put in the "Local" kernel namespace related to the user session.

Unfortunately, WCF doesn't provide any way to specify that you don't want it even to consider publishing the pipe via the "Global" namespace. So if these conditions 1 and 2 above can't be guaranteed, the only way I can think of is to name your endpoints with names based on the unique logon session ID, as you've suggested. Getting the Logon SID is a bit of an effort, requiring non trivial P/Invoke of Win32 APIs, but I see you've already found an answer on SO which shows how to do it.