我是否可以避免存储 MS Exchange 凭据，同时仍然能够进行身份验证(针对 EWS)
本文关键字：身份验证 EWS 针对 MS 存储 可以避免 是否 Exchange 凭据 | 更新日期: 2023-09-27 17:56:56
我正在构建一个应用程序，用于在用户的 Exchange Server 帐户（支持版本 2007-2013）和应用程序之间同步数据。
应用程序不能使用模拟（至少在典型情况下不能），因为用户可能位于任意数量的域和 Exchange 服务器上。
我知道我最初将不得不询问他们的用户名/电子邮件地址和密码。但是，如果没有必要，我真的不想负责存储这些凭据（即使它们是加密的，我宁愿不这样做）。
我不确定要问什么问题，所以我要问这些：
Exchange Server 如何进行身份验证？用户的凭据是按原样直接发送到服务器，还是在通过网络发送之前将哈希处理在一起？如果它们经过哈希处理，如何获取/生成此哈希以在后续身份验证中重复使用？
Exchange Server 是否发送某种可以在以后重复使用的身份验证令牌（并且永远可以重复使用，直到密码更改或失效）？
如果您知道问题的解决方案，但这些问题的答案无法解决，请提供它。
Active Directory 联合身份验证服务正是针对此类任务的。你可以在那里阅读它。
正如Kirill所提到的，ADFS 2.0是完成您任务的最佳解决方案之一。您还可以查看其他 SSO 实现。尽管 SSO 实现的主要目标是维护多个应用程序的单个登录状态（从而减少每个应用程序的多个登录提示），但某些应用程序目标似乎是相关的。在进行 SSO 实施之前，请对所有权衡进行彻底的研究，因为在实施过程中涉及少量的复杂性。如果您正在考虑将来将多个应用程序与 Exchange 服务器集成，则 SSO 最适合。
要回答您的一些问题（按相同的顺序 - 考虑使用 ADFS 2.0 的 SSO 方案）：
- 对交换服务器的身份验证将通过 ADFS 2.0 完成（在使用 AD/主目录服务进行身份验证后，向应用程序提供安全令牌（STS 服务）。所有通信都经过加密，令牌签名证书用于完整性和机密性。
- 可以根据需要配置 ADFS 2.0 发送的安全令牌的生存期并重复使用。有关更多详细信息，请参阅此博客文章。
还可以将 ADFS 2.0（联合身份验证服务）配置为仅将相关的声明值（如用户名和电子邮件地址）发送到应用程序，从而提高数据安全性。
System.Net.CredentialCache应该可以满足您的需求。 WebCredentials是System.Net.NetworkCredential的包装器。 根据连接类型/域等，您应该能够使用System.Net.CredentialCache.DefaultNetworkCredentials或System.Net.CredentialCache.DefaultCredentials
也许您应该看看这个 链接 使用 EWS 托管 API 连接到 EWS ， 连接到 Exchange - 入门教程？ 希望它能给你一个新的想法，如何解决你的问题:)
因为如果我正确理解信息，您可能会过度思考问题，但我没有任何经验，所以我也可能绝对错误
底线
如果无法在服务器上配置任何内容，则不会自动生成要使用的令牌。这很不幸，但您面临着与Web浏览器相同的一般问题 - 保存密码。值得注意的是，任何身份验证都需要通过SSL（https连接）进行，以防止第三方监听身份验证。
密码存储的想法：
我的建议是在存储密码时要有一点创意。您可以使用密钥加密算法，然后使用哈希生成密钥，让您任意选择密钥的内容。您需要至少 3 条信息：设备独有的信息、应用程序独有的信息以及 Exchange 服务器独有的信息。
例如：
- 设备给出的唯一 ID（此值是否特定于应用并不重要，只需保持一致即可）
- 编译到应用程序中的（长）信息字符串，可能与安装特定值有关，例如首次使用应用程序的时间
- 目标特有的内容，例如 DNS 名称，也许还有一些更具体的服务器信息
如果您愿意向用户提供该选项，则可以拥有某种授权 PIN，该 PIN 也会添加到数据中。
所有这些数据都放在一个字节数组中并进行哈希处理。然后，哈希（或其中的一部分，或两次，取决于哈希大小与密钥长度）用作密码加密的密钥。
您还可以在密码中包含一些检查信息，以便能够检查客户端密码是否正确解密。（如果对错误的数据进行哈希处理，则会生成错误的密钥，并且解密会产生错误的结果）。
值得注意的是，用于放入哈希的所有信息都需要存储在设备上，这就是为什么我建议使用 Pin 来授权使用该帐户的原因。