我是否可以避免存储MS Exchange凭据，同时仍能进行身份验证（针对EWS）？

Question

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

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

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

我不确定要问什么问题，所以我会选择这些：

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

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

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

Answer 1

Active Directory联合服务完全适用于此类任务。你可以阅读它there。

Answer 2

如Kirill所述，ADFS 2.0是您的任务的最佳解决方案之一。您还可以查看其他SSO实现。虽然SSO实现的主要目标是为多个应用程序维护单个登录状态（从而减少每个应用程序的多个登录提示），但您的一些应用程序目标似乎是相关的。因为在实施过程中涉及的程度很小，所以请在进入sso实施之前对所有权衡做一个深入的研究。如果您考虑将来将多个应用程序与Exchange服务器集成，则SSO最适合。

回答一些问题（按照相同的顺序 - 考虑使用ADFS 2.0的SSO方案）：

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

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

Answer 3

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

Answer 4

也许你应该看看这个链接Connecting to EWS by using the EWS Managed API，Connect to Exchange - Getting Started Tutorial?，它会给你一个新的想法，如何解决你的问题：）

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

Answer 5

底线

如果您无法在服务器上配置任何内容，则不会使用自动生成的令牌。这很不幸，但是您面临着与Web浏览器相同的一般问题 - 保存密码。 值得注意的是，任何身份验证都需要通过SSL（https连接）来防止第三方收听身份验证。

密码存储想法：

我的建议是在存储密码时有点创意。您可以使用密钥加密算法，然后使用哈希生成密钥，让您随意选择密钥中的内容。您至少需要3条信息：设备独有的东西，应用程序独有的东西，以及Exchange服务器独有的东西。

例如：

• 设备给出的唯一ID（此值是否与应用程序无关，只是它是一致的）
• 编译到应用程序中的（长）信息串，可能键入特定于安装的值，例如首次使用该应用程序的时间
• 目的地独有的东西，例如DNS名称和可能更具体的服务器信息

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

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

您还可以包含一些检查信息以及密码，以便能够检查客户端是否正确解密了密码。 （如果对错误的数据进行哈希处理，则会生成错误的密钥，并且解密会产生错误的结果。）

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