Longhorn has some exciting improvements in the smart card subsystem. For example, the Smart Card Resource Manager (aka "scardsvr"), or SCRM, has been given a reduced attack surface and been made more scalable.
Disclaimer - as you know, until the product releases, nothing is final.
First, we've moved the SCRM service into a shared "service host" process. The net effect of this is that there's one less process to start when the machine boots. This means that servers can come up faster, and you'll see your desktop faster when you boot up and immediately login to your workstation (there was a separate change which makes smart card logon possible immediately upon boot, rather than having to wait 20 to 30 seconds, but I'll leave that for another post). In the performance game, I feel that every little bit counts ...
Second, the smart card subsystem is no longer using named pipes for communication between client processes (i.e. via winscard.dll) and the SCRM. We're now using local RPC, which is designed to be robust and scalable. In the named pipe based model, we required one thread running in the service for each outstanding client context handle, and threads could not be reused. On a stressed server with smart card-aware applications and multiple active user sessions, it wasn't uncommong to see 30 to 50 threads running in the SCRM. In Longhorn, since RPC uses the threadpool, our service thread usage is optimized. For example, service threads can be reused, multiple threads waiting for calls can be collapsed into a single thread, etc. We're still running some non-RPC threads that we could eventually move to the theadpool as well, but that's a smaller-scale problem. Hopefully, we'll have time to tackle it.
Third, and most significant, a benefit of using L/RPC is that the service no longer must impersonate the client. You may already know that, as of XP, the SCRM runs under the limited LocalService account. However, due to an limitation inherant to the named pipe based design, the service was required to impersonate each client caller in order to exchange a "Cancel" event handle. The cancel event allowed a separate client thread to abort blocking calls into the SCRM, if necessary. However, duplicating the client event handle in the service process required impersonation, since in many scenarios the service is being called by a higher privilege account (e.g. a system process). In other words, the SCRM wouldn't have permission to open the calling process token at the necessary access level without impersonating.
In Longhorn, we don't need a cancel event any more, since, due to the architecture of RPC, there's no longer a 1:1 mapping between client contexts and service threads. In other words, the client can successfully make calls against a given handle even while a previous call on that handle is blocking in the service. This was not the case when using named pipes. The Cancel event can now be created and maintained by the service, on a per client context basis. With no impersonation required, smart card client processes can safely protect themselves from a rogue service by disallowing impersonation via RPC configuration.
As an aside, I believe the default behavior of the RPC client context handles is to be non-serialized. In other words, simultaneous calls can be serviced against a single context. As suggested above, our old named pipe based context behavior was serialized, since a given service thread can obviously only be performing one task at a given time. In order to avoid introducing subtle new bugs in existing smart card applications, we configured our RPC client context handles to be serialized.
I'm proud of the work we've done, and that only scratches the surface. Can't wait until it ships!
