在 Beta 1 中我弄不明白的另外一件事是将 SecureString 广泛地集成到框架中。迄今为止，我发现唯一使用它的地方是 ProcessStartInfo。该类只有更充分地集成到框架中，它的真正功能才能实现。
例如，我希望看到下面的构造函数：
public SqlConnection(SecureString connStr);
我还希望看到包装 Win32® 函数（如 CredUIPromptForCredentials）的托管类，这样我可以询问用户密码，从而返回 SecureString。集成是该功能成功的关键。
除了 SecureString，该命名空间中还有另一个新类吸引了我的眼球：SecurityContext。在 Beta 1 版本中甚至还有该类的一些文档，这是个功能极其强大的类！它允许您捕捉某个线程的安全性上下文，并将其还原到另一个线程上。这包括代码访问安全 (CAS) 线程标记，如 Assert 和 PermitOnly，还包括非托管线程的模拟标记。
该类还有一些看起来不一致的函数，如 SuppressFlow，该函数控制 CAS 标记是否从一个线程流动到另一个线程（通常是这样）。那么就有一个令人吃惊的结果：SuppressFlowWindowsIdentity。任何在 Windows? 中已经较长时间从事安全性编程的人员都知道，当您开始一个新线程或通过委托执行异步调用时，模拟标记并不流动到新线程。这种不起眼的安全性局限在过去的几年中已经刺痛了不知多少个开发人员。如果 SecurityContext 提供一种可以抑制 WindowsIdentity 在线程间流动的函数，那一定意味着 .NET Framework 现在可以自动地流动模拟标记。
为了测试这一点，我编写了一些称为 LogonUser 的代码并模拟了结果标记。然后，我使用 WindowsIdentity 上 GetCurrent 方法的一种全新重载来确定我是否是在模拟（这一点随后有更多讲述）。我从四个不同的地方调用该函数：主线程，通过 Thread.Start 开始的新线程，通过异步委托开始的辅助线程，以及从我们来自 Win32 的老朋友，CreateThread 开始的线程。对了，我甚至尝试着测试 QueueUserWorkItem，在过去它对流动安全性上下文的处理已经有些不同（特别是对 CAS 标记）。下面是输出结果：
Main thread
Thread 2488 is impersonating V-CAMP-XP\alice
Testing Thread.Start
Thread 2508 is impersonating V-CAMP-XP\alice
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
