N层应用程序中的WCF和Silverlight 4.0：安全服务调用（无SSL，无信息安全，否x.509）

Question

我们的架构是一个简单的N层模型，它由坐在IIS7中的ASP.Net应用程序（在DiscountASP中托管），这暴露了WCF服务的方法。这些方法使用EF4与数据库交谈。客户端在Silverlight 4.0中。

三个要点：

• 认证和Authurazation是不是一个问题 - 到 服务调用匿名，我们不关心 呼叫者的身份。

• 传入方法调用的数据在不敏感。

• 我们只是想确保任何人都无法拨打电话。

纠正我，如果在错误的：
信息安全是不是一种选择，因为它不支持Silverlight。
传输安全（HTTPS和X.509/SSL证书），也不能在Silverlight

所以我们采取的强制安全的一些级别的步骤来完成的：

• 一个密钥硬编码到XAP的dll中。

• 这个DLL是混乱的，所以它不能被重新设计。

• 密钥作为参数发送到所有服务方法 调用。

• 在每种方法开始时，检查数据库中原始坐标的 密钥。

• 从服务中删除MetaDataExchange端点。

考虑这个最小的设置和它的许多缺陷，最大的缺陷可能是一个事实，即传送不保证（HTTP），和秘密密钥被暴露。所以问题是：

如果恶意用户想要伤害我们的系统，他需要付出多少努力才能提取密钥，找到暴露的方法并开始调用它们？

是否有其他的WCFcombiantion可以在每次调用时提供基本的凭证保护（无HTTPS或证书）？

Answer 1

好吧不，它变得更加清晰你的意思是在你的合同previous question合同的安全。安全包括several aspects。

• 认证和Authurazation是不是一个问题 - 到 服务电话是匿名的，我们不关心 呼叫者的身份。

• 我们只是想确保任何人都无法拨打电话。

这是一个矛盾。如果您希望确保所有您希望验证的用户都无法拨打电话。

• 在方法调用中传输的数据不灵敏。

考虑到这个最小的设置和它的许多缺陷，最大的缺陷可能是传输不安全（HTTP），并且密钥被暴露。

另一个矛盾 - 你显然想发送敏感数据。

信息安全不是Silverlight的一个选项 - 如果我们谈论的消息加密和签名是真实的，但你仍然可以在消息中传递用户名和密码，如果您使用HTTPS提供安全通道= TransportWithMessageCredential

找到一个密钥需要多少努力？

• 如果你不使用HTTPS会发现每个人都与基本技能，并获得网络TRAFIC
• 如果你把在组件的钥匙，它可能会需要更多的技巧，但仍是重点会在那里（混淆难以对逻辑进行反向工程，但常数必须保持不变）。

如果你想确保你的传输并建立安全的解决方案，你必须使用HTTPS。通过HTTPS公开的服务可以被Silverlight使用。您还可以使用用户名和密码来识别您的客户。客户将负责保密用户名和密码，因为如果他们不会，你会看到谁的帐户伤害了你的应用程序。