授权

在上周的专栏文章（英文）中，我们讨论了设计收藏 Web 服务时的用户保密问题。根据对用户保密问题的初步调查，我们决定在收藏服务的初版中集中讨论三个主要的使用方案：

Web 站点（如 msdn.microsoft.com）在每一个页面上均提供一个按钮，用户可以通过单击此按钮将该页面添加至存储在收藏服务的用户收藏夹中。

msdn.microsoft.com 提供一个网页用以显示用户的收藏，这些收藏最初由 msdn.microsoft.com 代表用户存储在收藏服务中。

msdn.microsoft.com 提供一个 Web 应用程序，使用户可以管理最初由 msdn.microsoft.com 代表用户存储在收藏服务中的收藏。
实际上，每个使用收藏服务的 Web 站点都可以获取自己的有关用户收藏的专用存储区。即使在这套有限的方案中，我们仍决定将对服务的访问限定在已知用户范围内，也就是说，我们需要对服务进行授权。

在本期专栏中，我们将详细讨论授权问题：定义 Web 服务的业务模型时需要考虑的问题；如何建立业务模型与授权的关联；选择用于收藏服务的模式及其理由；以及所选模式对设计和实现的影响。

意见反馈

在开始之前，我想就上周专栏中读者提出的几个问题进行说明。

第一，就用户保密问题，有读者询问我们将如何看待欧盟 (EU) 的数据保护条例。如果想知道“什么是欧盟数据保护条例？”，请访问 http://europa.eu.int/comm/internal_market/en/media/dataprot/（英文）。由于我们的项目组服务于 Microsoft，同时我们计划在 Microsoft 拥有的设备上承载收藏服务，所以我们所展开的服务必须符合 Microsoft 在 EU 数据指令方面的政策。

我们的项目组目前正在与 Microsoft 的公司政策小组协同工作，以确保在我们的产品服务器上展开的收藏服务符合 Microsoft 的政策。如果我们最终为满足 EU 的要求而采取了某些“特别”措施，我们一定会通知大家。但是，请注意：我们为符合 Microsoft 的政策而需要采取的措施并不等同于读者为符合其公司的政策而需要采取的措施。这个例子说明了为什么在整个项目周期中您始终需要法律顾问的协助，以确保无论您的客户、员工和服务器位于何处，您的保密政策均符合当前的法律。

第二，有读者询问如果将收藏服务与某些其他功能结合起来并展开一项新的服务，应该如何处理 Logon 组件。简单地说，Logon 组件的方法是通过收藏 Web 服务公开的。客户端应用程序（在此处为新服务）必须先调用 Logon 方法，然后才能使用用户收藏管理方法。下期专栏将讨论身份验证和授权问题，请在下周阅读详细内容。

Web 服务业务模型

大多数与最终用户直接进行交互的 Web 站点都采用几种业务模型。从用户角度考虑，有以下几个选项：

用户可以随意访问站点的全部功能。

用户必须先申请一个免费帐户，才能访问站点的部分或全部功能。

用户必须先支付订阅费，才能访问站点的部分或全部功能。订阅方式通常使用户可以在指定的时间段内无限制地访问某些功能。

用户必须先按次支付使用费用，才能访问某些内容。

业务模型的另一方面是如何收回站点的开发和运行费用：

将开发和运行费用简单地计为业务成本。

用户支付站点访问费。

将站点空间出售给广告商或其他站点。

就现状而言，这些模型并不能真正有效地为 Web 服务效力。通常，最终用户并不直接使用 Web 服务。而且 Web 服务的使用是有规划的，因此不能完全靠广告来获取收益。但是，在定义 Web 服务的业务模型时，用于 Web 站点的模式可以帮助我们确定某些要考虑的因素。这些需要确定的因素包括：客户、定价、付款方式、订阅、通知和付帐、宽限期、身份验证、审核以及客户服务。

客户

您需要了解的第一个问题是：您想与哪些客户建立业务协议。通常，Web 服务提供商会与要在应用中使用 Web 服务的应用程序开发人员建立业务协议。如果 Web 服务用于存储针对用户的数据，那么除了与应用开发人员建立协议之外，Web 服务还可能会与最终用户建立协议（或者不与应用程序开发人员建立协议）。另一种可能是 Web 服务提供商与一个或多个应用提供者 (ASP) 建立业务协议，以驻留服务。而 ASP 又与应用程序开发人员和/或最终用户（如果需要）建立关系。

定价

一旦确定了客户，您便可以开始考虑这些客户对您的服务的价值，以及他们愿意付多少钱来获取服务。有一点您应当考虑，即，是应当根据申请的次数（每次查阅收费模式）来指定价格，还是规定在某一时间段内无限制使用（租用模式）。其他因素包括：是否对各类申请的价格都一样；是否对所有客户的价格都一样；以及对每个用户的价格是否始终不变。

付款方式

如果您打算对服务收费，您需要考虑客户支付服务费用的机制。直接与最终用户进行交互的 Web 站点通常接受信用卡方式。但是，有些访问您的 Web 服务的公司不希望使用信用卡作为付款方式。您可能需要接受支票或电汇的付款方式。

另一个需要考虑的因素是，客户是必须预先付款、现购现付还是事后付款。如果客户可以事后付款，您可能需要设置未付费用的上限。您可能会对所有客户实行标准限制，或针对每个客户设置不同的限制。

订阅

无论您是否对您所提供的服务收取费用，您都需要使用某种方式来确定谁正在调用服务。在这种情况下，每个客户都需要与您建立一个帐户（或订阅）关系。他们如何与您建立这种关系呢？

您需要考虑：是立即为申请帐户的客户授予帐户，还是在授予帐户前先执行一定的审批程序。如果需要审批过程，客户是否可以通过 Web 进行申请，或者需要致电客户服务代表？是否需要指定员工调查和批准新帐户申请？

您还应当考虑在授予帐户前需要哪些信息，以及询问用户哪些可选信息。这些信息可能会归入个人可识别信息类别，需要通过应有的信息条例（如上周的专栏所述）进行保护。

另一个要考虑的因素是，是否允许客户选择自己的帐户标识符和密码（如果有），或者随机生成标识符和密码。如果客户可以选择自己的帐户标识符，您可能需要处理标识符重复的问题。

您还需要考虑用户如何维护自己的帐户信息（包括密码）。客户是否使用您的 Web 站点，以及他们是否能够致电客户服务代表？如果客户忘记了帐户标识符或密码怎么办？

通知和付帐

如果您的订阅有时间限制，您需要定义流程来通知客户其订阅即将到期。如果您对服务收费，而客户并非现购现付，您会遇到同样的问题。您应当考虑用哪种介质来通知客户。例如，可以发电子邮件、打电话或发送发票。您还应当考虑通知客户的次数，以及每次是否使用同一种介质。您计划在订阅到期前预先通知几次？

如果对服务收取费用，尤其是按申请次数收费，则应当考虑要求客户多长时间付一次帐。客户不会希望收到一张有成千上万项独立费用（每次申请服务一项）的帐单。也许您想按天、按周或按月汇总费用，并为需要费用细目的客户提供详细的使用报告。

宽限期

您应当考虑：如果订阅已过期或付款期限已过，是否允许存在宽限期。如果指定宽限期，则需要考虑宽限期的长短，以及宽限期间是否对帐户进行限制。例如，客户只能查询现有信息，而不能保存新信息。另一个需要考虑的因素是，宽限期间是否向客户发送其他通知。

身份验证

从更侧重技术的层次来说，如果客户需要通过帐户来访问您的服务，则您需要考虑当客户申请服务时如何验证他们的身份。目前所使用的身份验证机制有三种基本类型：通信协议身份验证功能、应用级别身份验证功能以及第三方身份验证。最直接的方法是，借助用于与 Web 服务交换消息的通信协议的功能。例如，Microsoft Internet Information Server 5.0 支持几种 HTTP 身份验证机制。另一个选择是在 Web 服务中实行自定义身份验证机制。例如，如果您的 Web 服务可以接受 SOAP 消息，则客户凭据可以在 SOAP 标题中传递或作为 SOAP 正文中的元素传递。最后，您可以使用第三方服务（例如 Microsoft Passport）来解决身份验证问题。

每一种可用的机制都有其优劣之处。某些机制相对其他机制而言更加安全。某些机制不能受到用于创建 Web 服务的开发人员工具的广泛支持。某些机制要求客户从第三方获取证书或帐户。某些机制具有显著的性能额外开销。您需要针对客户权衡这些机制的利弊，以确定哪种机制适合您的 Web 服务。有关当前可用的 Web 服务身份验证选项的进一步信息，请参阅 Web 服务安全性（英文）。

审核

您要考虑的另外一个问题是，收集审核所需的信息。请考虑如果发生帐单或客户保密问题的争端，您需要掌握哪些信息。如果按申请次数收费，则可能会存在大量数据。请考虑每天要收集的数据量以及如何存档数据。是否应当创建标准报表以帮助避免或解决争端？

客户服务

最后，请考虑您需要提供什么样的客户服务。例如，您可能需要提供客户服务以便申请和管理订阅。您很可能需要为客户提供报告问题的途径，以便他们在访问或使用服务遇到问题时使用。您还可能需要为开发人员提供某种途径，以帮助他们编写使用您的服务的程序。

对于每一种客户服务，您都需要考虑提供该服务的方式。客户是否需要使用 Web 站点来获取帮助？客户是否能够发送电子邮件？客户是否可以通过电话进行联系？无论您决定使用哪种选项，您需要准备什么工具和设施，才能提供有效支持？

业务模型和授权

考虑好这九个方面的问题后，您应当对您的 Web 服务采用的业务模型有了一个清晰的概念。如何将这一模型与授权联系起来呢？

当我们使用术语“许可协议”时，我们指的是客户与 Web 服务提供商之间就 Web 服务的使用所达成的协议。除非您的业务模型是匿名的且任何人都可以访问，否则很可能会涉及许可协议。例如，建立帐户或订阅时可能会要求客户接受一定的使用条款。在某些情况下会要求客户先阅读或签署许可协议，才能批准其订阅。在谈到仅允许授权客户访问的 Web 服务时，我们通常使用术语“授权模型”而不是“业务模型”。

收藏授权模型

根据第一版的收藏服务中选定使用的方案，我们已经定义了客户群：打算使用收藏服务的应用开发人员（或更确切地说，开发机构）。下一个要关注的问题是客户在使用服务前是否要先进行订阅。先考虑如果不要求订阅会怎么样。

假设某个应用打算开始使用收藏服务保存收藏。出于用户保密的考虑，我们决定每个调用方都可以获得自己的数据存储区。应当如何识别存储区？如果调用方为存储区指定了名称，则可能两个调用方会指定相同的名称，我们无法将他们区分开来。我们可以提供一种 CreateStore 方法，用于返回唯一的数据存储区标识符。但是，如果唯一标识符丢失或被盗怎么办？由于我们没有将唯一标识符绑定到特定调用方的信息，因此我们无法检索丢失的标识符。对被盗的标识符，我们也将束手无策。事实上，我们甚至无法确认报告标识符被盗的人与创建数据存储区的调用方有任何关系。

总之，我们最好要求客户登录后进行订阅。这样，我们便可以收集足够的联系信息，以处理丢失或被盗的帐户标识符或密码。如果我们检测到某个特定应用使用收藏服务的方法有问题，我们还可以通过这些联系信息与之取得联系。

到此为止，我们可以确定我们的授权模型应该为：为提供了联系信息（并或许已阅读了保密政策或其他声明）的开发机构授予免费、终生无限制的使用许可协议。但是，我们决定将系统设计为能够支持更复杂的业务模型，以便查看对整个系统设计的影响。

在第一阶段中，收藏服务被授权给打算在其应用中使用该服务的开发机构。授权的规则如下：

在指定的时间段内被授权者可以无限制地访问服务。

被授权者必须预先支付服务费用。收费比率将根据授权时间的长短以及被授权者管理其收藏的最终用户的总数量决定。

许可协议到期前一个月，将通过电子邮件通知被授权者。

许可协议到期前一周，将通过电话通知被授权者。

许可协议期满后，将给予被授权者十天的宽限期。

授权流程如下图所示：

图 1：收藏授权流程

开始授权过程时，必须与客户帐户代表取得联系。许可协议生效前，所有费用都将以发票方式通知被授权者，同时必须收到被授权者支付的费用。许可协议生效后，将通过电子邮件将使用收藏服务所需的所有信息通知被授权者的业务联系人。协议生效后，24 小时之内收藏服务可能无法识别新的被授权者。

所有新许可协议的有效期为三个月，收费比例为每位用户 $0.00。三个月期满后，许可协议可以更新为三个月、六个月、一年或两年。费用的收取将根据被授权者管理其收藏的用户数量来决定。功能规格（英文）定义了费用的计算方法。

为了计算续订许可协议的费用，以及在发生付帐纠纷时保护我们的权益，收藏服务会将每一次调用及其结果（成功、客户端错误或服务器错误）都记录到 Web 服务。

请注意，要求 MSDN 公布其实际实现该授权模型所有功能的示例服务是不切实际的。例如，我们没有客户帐户代表（他们答复新的许可协议申请，或在许可协议到期前一周通知被授权者）。我们也并不想对使用示例服务的人收取费用。但是，我们认为设计一个可以支持此授权模型的系统是非常重要的。在实际的实施过程中，我们将作出一些修改，以便尝试已开展的服务，而不必为获取许可协议而争论不休。当然，我们会指出我们在设计和实施上的不同之处。但愿这不会太复杂。

实现收藏中的授权

您可能会想，为支持授权模型，收藏服务的复杂性一定增加了不少。仅仅实现一个 COM 组件并将其发布为 Web 服务，这当然是不够的。我们需要采用某种方式，让潜在的客户申请订阅；让客户维护其帐户信息；还需要某些工具来生成续订通知。我们需要收集每次调用服务的数据，以便计算续订许可协议的费用。我们还需要实现身份验证机制。下图显示了我们的系统结构的高层次视图：

图 2：第一阶段的收藏服务授权体系结构

客户通过收藏 Web 站点申请订阅或更改帐户信息。Web 站点将验证输入的数据，将申请传递到 Licensing 组件，并显示已收到申请的确认信息。一般来说，收藏服务不会立即批准订阅或更改帐户信息，而是将挂起的申请保存起来，由客户帐户代表进行验证。当接受申请后，将向被授权者的联系人发送电子邮件，确认申请已完成。

Licensing 组件实现了授权模型的业务逻辑。每种授权组件方法的基本结构都相同：初始化 Audit 对象以创建审核日志项，验证输入的参数，调用存储的过程以更新相应的数据库，在需要时发送电子邮件通知，用方法的结果更新 Audit 对象，并保存审核日志项。某些业务规则是在存储过程（而不是 Licensing 组件）中强制执行的。电子邮件通过 IIS SMTP 服务发送。

我们的授权模型流程通过存储在 Licensee 和 Notifications 数据库中的一套状态标志来实施。例如，当某个潜在客户申请新许可协议时，新的被授权者记录将写入 Licensees 数据库，其状态设为 pending。同样，发送许可协议续订通知时，该通知也将记录在 Notifications 数据库中。

在业务模型的真实实现过程中，在批准新的许可协议或更改联系人信息之前，客户帐户代表将验证客户的联系信息。“收藏许可协议管理系统 (FLMS)”是基于 Web 的应用，客户帐户代表可以使用该应用查看挂起的申请，并接受或拒绝这些申请。由于没有客户帐户代表，我们仅实现了对几个申请的支持。您可以看看这是如何实现的。与外部客户 Web 站点一样，FLMS 依靠 Licensing 组件完成大部分工作。

在我们展开的 MSDN 服务中不存在任何客户帐户代表，因此我们实施了称为 AutoAdmin 的进程，该进程检查挂起的申请，并使用 Licensing 组件的服务自动批准申请。我们还需要一种自动生成续订通知的方法。这在另一个称为 Renewals 的进程中实现，该进程每天运行一次。

为了计算续订的许可协议费用，以及记录必要的信息以解决付帐或客户保密问题的争端，我们使用前面提到的 Audit 组件，将每次申请收藏 Web 服务和 Web 站点的结果都记录在 Audit Log 数据库中。每个审核日志记录都包含以下信息：提出申请的被授权者、代表其创建申请的用户、申请的操作类型、申请操作的时间、处理申请所需的时间以及申请的结果。这些信息用于计算日常使用统计数字，这些统计数字构成了“报表”服务的核心。一旦计算出日常使用的统计数字，便可以将原始审核日志报表存档。

最后，如果我们没有适当的方法来验证 Web 服务的调用者身份，所有这些支持基础设施将不会给我们带来任何好处。我们为收藏服务选择了实施应用级别的身份验证。要使用收藏服务的应用必须首先调用 Logon 服务以获取密钥。每次申请使用收藏和报表 Web 服务时，都必须提供此密钥。如果密钥有效，才会允许继续操作。否则，访问将被拒绝。

总结

由此可见，Web 服务所使用的业务模型将对系统的整体要求产生重大影响。您应当尽早定义业务模型，以免将来发现需要对系统体系结构作大幅度的修改。另一方面，描述您的客户愿意接受什么样的业务模型可能比较困难。您应当考虑使用灵活的设计，以便顺应业务模型的变化。

下周，我们将继续探讨在实现收藏服务过程中所遇到的设计问题，进一步讨论身份验证和授权问题。