我正在开发一个 WCF 服务,该服务将通过 net.tcp 与客户端应用程序的 n 个实例进行通信(由我办公室的另一位程序员开发)。
目前我正在使用 net.tcp 没有任何安全性,因为我觉得在这个阶段设置它是没有必要的,至少在我们接近推出之前不需要。
在开发 WCF 应用程序的过程中,使用没有安全性的标准绑定(在我的例子中是 net.tcp)有什么害处,那么一旦业务逻辑完成,实现所有的安全性要求?我需要注意哪些在实施安全性后可能无法正常工作的事情?
我正在开发一个 WCF 服务,该服务将通过 net.tcp 与客户端应用程序的 n 个实例进行通信(由我办公室的另一位程序员开发)。
目前我正在使用 net.tcp 没有任何安全性,因为我觉得在这个阶段设置它是没有必要的,至少在我们接近推出之前不需要。
在开发 WCF 应用程序的过程中,使用没有安全性的标准绑定(在我的例子中是 net.tcp)有什么害处,那么一旦业务逻辑完成,实现所有的安全性要求?我需要注意哪些在实施安全性后可能无法正常工作的事情?
虽然您的整体设计应该从一开始就考虑安全性,但我认为将您的组件与任何特定的安全策略结合起来并不是一个好主意。您可能非常希望以非安全方式或跨提供不同安全选项的不同协议使用某些组件。
所以我的回答是肯定的和否定的。是的,您需要从一开始就考虑它,但不,您不应该将组件与您的安全需求结合起来。
也就是说,既然您知道您将使用 net.tcp,您应该知道默认情况下此绑定的传输安全性已打开。
有关更多信息,请参阅 Juval Lowy 出色的Programming WCF Services第 10 章。Lowy 在他的 ServiceModelEx 库(在书中详细讨论)提供了一个非常好的框架,您可以在创建组件后插入该框架。即使它不是您正在寻找的东西,您也可以对其进行定制以满足您的需求。
应该从一开始就考虑安全性,而不是在最后添加。
为您的安全制定一个计划,并在您进行时实施,而不是在最后实施。
参考:Microsoft .NET:为企业构建应用程序
http://www.amazon.com/Microsoft®-NET-Architecting-Applications-PRO-Developer/dp/073562609X _
你有两个选择,从一开始就烤,或者在最后打上它。一般来说,我会说它在结冰时确实不起作用,所以你必须把你的蛋糕弄得一团糟才能把它放进去。
However, the way I see your question is you already know you need to do something to solve a security issue, you just have not decided what to do. In that case I would agree with Terry that you should then design around an abstraction that allows you to plugin the eventual solution.
If I were you I would probably do a threat model and use it to consider the inputs and risks presented by your service. This will help you decide what you should do eventually and if your abstraction covers all bases.