我们开始设计一大堆要创建的新服务(WCF、ADO.NET数据服务，可能在某个时候在云中)，弹出的一个问题是使用哪种身份验证和授权方案-有相当多！
我们基本上需要能够识别各种协议(HTTP、HTTPS、TCP)上的用户(实际用户和"虚拟"应用程序/服务用户)，我们需要为他们分配至少一组角色/权限，以查看特定数据和/或执行特定操作.
我们绝对不能单独使用Windows组成员资格-我们的服务有很多外部消费者，我们不想在内部域中为他们中的每个人设置一个域帐户.
我认为主要有三种 Select :
首先，你会推荐这三个中的哪一个？有什么原因吗？
第二，我还缺少更多的 Select 吗？
感谢您的任何提示、指点和意见！
MARC
PS:看到到目前为止的答案，我对投票给选项3的人的数量感到惊讶.我本以为微软能够设计出可以处理所有这些需求的可重用的东西.
实际上，答案可能是1和3的组合.
如果默认选项没有达到您想要的程度，您可以通过编写membership、role或profile提供程序来利用框架为您提供的许多工具和功能.
我们在很多客户端网站上都这么做了——例如，我们的一个客户端将其大多数用户存储为Commerce Server用户，并使用Commerce Server配置文件系统，因此我们编写了一个成员资格和配置文件提供器来与这些数据存储进行对话——这是一个相当简单的练习.
大多数人可能会 Select 3，因为需要通过原始TCP进行身份验证——这引入了一个超出标准ASP.NET成员资格提供者的层.
微软生产的大多数产品都是"ok"或"足够好"，但总会有一些边缘 case ，你想做一些"不太标准"的事情，这意味着你最终会自己动手.我想除了"基本授权"或"Windows授权"之外，还有一些东西对普通开发者来说很容易理解，他们 Select 了"让我们为web构建这个"的明智 Select .
如果你看一看可以针对WCF服务进行身份验证的多种方法，你就会明白我的意思——这are种方法设计用于处理不同的传输机制，因此要复杂得多.
也就是说，默认角色和配置文件提供程序相当有限(角色:没有层次 struct ，所以需要判断每个可能的角色，或者显式地将每个角色分配给用户；配置文件:所有角色都以逗号分隔的值存储在一个字段中——不容易找到所有具有值集的用户).