12

我正在构建一个在用户的 Exchange Server 帐户（支持版本 2007-2013）和应用程序之间同步数据的应用程序。

该应用程序不能使用模拟（至少在典型情况下不是），因为用户可以在任意数量的域和交换服务器上。

我知道我最初将不得不询问他们的用户名/电子邮件地址和密码。但是，如果我不需要的话，我真的不想负责存储这些凭据（即使它们是加密的，我也不愿意）。

我不知道要问什么问题，所以我会用这些：

Exchange Server 如何进行身份验证？用户的凭据是按原样直接发送到服务器，还是在通过网络发送之前经过哈希处理？如果它们被散列，我如何获取/生成此散列以在连续身份验证中重复使用？

Exchange Server 是否发送某种身份验证令牌，以后可以重复使用（并且永远重复使用，直到密码更改或失效）？

如果您知道问题的解决方案，但这些问题的答案无法解决，请务必提供。

4

5 回答 5

5

Active Directory 联合服务正是针对此类任务的。你可以在那里阅读它。

于 2013-02-04T20:50:24.623 回答
1

正如 Kirill 所说，ADFS 2.0 是完成任务的最佳解决方案之一。您还可以查看其他 SSO 实现。虽然 SSO 实现的主要目标是为多个应用程序维护单个登录状态（从而减少每个应用程序的多个登录提示），但您的一些应用程序目标似乎是相关的。在进行 sso 实现之前，请对所有权衡进行彻底的研究，因为在实现过程中涉及到一定程度的复杂性。如果您正在考虑将来将多个应用程序与交换服务器集成，那么 SSO 最适合。

要回答您的一些问题（以相同的顺序 - 考虑使用 ADFS 2.0 的 SSO 场景）：

  1. 交换服务器的身份验证将通过 ADFS 2.0 完成（它提供安全令牌（STS 服务）-在使用 AD/主目录服务进行身份验证后向您的应用程序提供）。所有通信都经过加密，令牌签名证书用于完整性和机密性。
  2. ADFS 2.0 发送的安全令牌的生命周期可以根据需要进行配置和重用。有关详细信息，请参阅此博客文章。

您还可以将 ADFS 2.0（联合服务）配置为仅将相关声明值（如用户名和电子邮件地址）发送到应用程序，从而提高数据安全性。

于 2013-02-11T03:06:01.750 回答
0

底线

如果您无法在服务器上配置任何内容，则没有自动生成的令牌可供使用。不幸的是，您面临着与网络浏览器相同的普遍问题——保存密码。值得注意的是，任何身份验证都需要通过 SSL（https连接）来防止第三方监听身份验证。

密码存储思路：

我的建议是在存储密码时要有点创意。您可以使用密钥加密算法，然后使用散列生成密钥，让您任意选择进入密钥的内容。您至少需要 3 条信息：设备独有的信息、应用程序独有的信息以及交换服务器独有的信息。

例如：

  • 设备提供的唯一 ID（此值是否特定于应用程序并不重要，只要它是一致的）
  • 编译到应用程序中的（长）信息字符串，可能与安装特定值相关，例如首次使用应用程序的时间
  • 目的地独有的东西，比如 DNS 名称，也许还有一些更具体的服务器信息

如果您愿意为用户提供选项，您可以拥有某种类型的授权 PIN，该 PIN 也将添加到数据中。

所有这些数据都放在一个字节数组中并进行哈希处理。然后将散列（或其中的一部分，或两次，取决于散列大小与密钥长度）用作密码加密的密钥。

您还可以在密码中包含一些检查信息，以便能够检查客户端密码是否被正确解密。（如果对错误的数据进行哈希处理，就会生成错误的密钥，错误的结果来自于解密）。

值得注意的是，用于放入哈希的所有信息都需要存储在设备上，这就是为什么我建议使用 Pin 来授权帐户的使用。

于 2013-02-11T15:34:25.617 回答
0

也许您应该看一下通过使用 EWS 托管 API 连接到 EWS 的链接，连接到 Exchange - 入门教程？希望它会给你一个新的想法来解决你的问题:)

因为如果我正确理解信息，您可能会过度思考问题，但我没有任何经验，所以我也可能绝对错误

于 2013-02-11T13:40:51.000 回答
0

System.Net.CredentialCache应该可以满足您的需求。WebCredentials是System.Net.NetworkCredential. _ 根据连接类型/域等，您应该能够使用System.Net.CredentialCache.DefaultNetworkCredentials或System.Net.CredentialCache.DefaultCredentials

于 2013-02-04T20:44:34.773 回答