这是Web服务安全体系结构系列技术文章中的第二篇。第一部分介绍了一家虚构的公司：因特网字典公司（TIDC）及其客户RegalResearch.com。RegalResearch公司采用了一种Web服务把TIDC的功能集成进它自己的网站。第一篇文章介绍了保证TIDC
Web服务安全的IP阻塞技术。在本文里，我们继续讨论另外两种技术：用户认证和数字证书。
用户认证是一种从数据库到操作系统等各类软件中都很常见的安全防范技术（参看图A）。用户认证从概念上来说是非常简单的：系统的每一位用户都被分配了一个唯一的用户名。对关联该用户名的资源或功能的访问都要接受特定口令的保护。因为大多数用户已经非常习惯这种安全技术，所以普遍存在的用户认证系统对Web服务的部署是非常有益的。不论你的Web服务是否正被其他Web开发人员或者一般公众使用，这种安全机制都很容易得到理解。
图A
给Web服务应用用户认证安全机制非常简单：每一种Web方法调用都要求额外的两个参数即可，这就是用户名和口令。只要调用了Web方法，第一步就是在数据库中检查用户名是否存在。第二步则是保证所提供的口令同指定用户名的口令匹配。如果这些检查都得以通过，那么Web方法的操作也才可以继续进行。如果在这些检查步骤中哪怕只有一步过不去，则Web方法需要给主调函数发送错误消息。
我们可以对这种技术做一点小小的改进，这就是常见的用户识别码，通常的用户识别码就是一个全局唯一标识符（GUID）。在这种情况下，除了标准参数之外Web方法还会接受参数UserID。这种途径同采用用户名/口令组合机制同样有效，这是因为GUID很难复制。在大多数情况下，随机找出用户的GUID比基于字符串的口令要难得多。因为许多数据库都能自动地产生GUID，所以这也是最为流行的安全技术之一。不过，这一技术也不是没有问题，其主要的缺点是用户或者开发人员很难记得GUID，特别容易敲错。
用户认证机制的主要优点是它可以为创造出更复杂的授权方案提供选择。记住，所谓的认证（authentication）是证明用户身份的过程，而授权（authorization）则是标识认证用户可访问资源的过程。由于每一种Web方法都认证提出请求的特定用户，所以，创造出一种复杂的授权方案使得用户只能使用部分Web方法是可能的。在这种情况下，证实用户身份以后，每个Web方法都将检查认证用户是否有权访问给定的Web方法。如果没有相应的授权权限，那么就应该向用户提出第3类错误信息。
当然，缺点也是有的。使用用户认证方案最明显的问题就是用户在每次调用方法的时候必须包括一个或两个附加参数。当服务器端Web应用（例如ASP或JSP）做这个工作时当然不算什么问题。然而，当人们通过WSDL页或类似的前端直接调用Web方法时，这项工作就实在太令人感到乏味了。
另外还有个令人担心的地方，在使用用户认证时需要在Web服务器上存储用户名/口令。由于这些信息通常存放在数据库里，所以需要额外的存储空间和服务请求，这就影响了Web服务的性能。同时，存储这类数据还可能把敏感的客户信息暴露给企业职员和黑客。对那些把数据库用做基本功能组成部分的Web服务而言，这一担心倒还可以通过体系结构和开发的精心设计来解决。而对那些不需要数据库的Web服务来说，仅仅是创造和维护用户认证的代价就够受得了。
