其中认证和授权方案您使用的 - 为什么？ [英] Which authentication and authorization schemes are you using - and why?
问题描述
我们开始设计了一大堆新的服务创造（WCF，ADO.NET数据服务，可能是在某些点云），并弹出一个问题是什么样的身份验证和授权方案使用 - 有相当多的！
We're beginning to design a whole bunch of new services to create (WCF, ADO.NET Data Services, possibly in the cloud at some point) and one question that pops up is what authentication and authorization scheme to use - there are quite a few!
我们基本上需要能够在多种协议的识别用户（实际的人，而虚拟应用程序/服务的用户） - HTTP，HTTPS，TCP - 我们需要给它们分配至少一堆角色/权限查看某些数据和/或做一些操作。
We basically need to be able to identify users (actual people, and "virtual" application/service users) on a wide variety of protocols - HTTP, HTTPS, TCP - and we need to assign them at least a bunch of roles / permission to see certain data and/or do certain operations.
我们绝对不能单独使用Windows组成员 - 我们有很多外部的消费者我们的服务的，我们不希望有设置域帐户在我们为他们每个人内部域
We definitely can't use Windows group membership alone - we have plenty of external consumers of our services and we don't want to have to set up a domain account in our internal domain for everyone of them.
所以，主要有三种选择，我想：
So there's mainly three options, I think:
- 使用ASP.NET会员制度 - 创建用户并分配角色有
- 使用AzMan的（授权管理器），这似乎是一个更精细，更成熟，更复杂的系统（与用户，任务组 - 三个级别，而不仅仅是用户+角色）
- 滚动自己的
首先 - 这三个的建议？任何为什么呢？
First of all - which of these three would you recommend? Any why?
第二 - 是否有更多的选择，我很想念？
Secondly - are there more options that I'm missing?
感谢您的任何提示，指针意见！
Thanks for any hints, pointers, opinions!
马克
PS：看到答案为止，我在乡亲选项＃3的投票量赞叹不已。我本来以为MS将能够设计出可重复使用的东西，可以处理所有这些要求....
PS: seeing the answers so far, I'm amazed at the amount of folks voting for option #3. I would have thought that MS would be able to design something reusable that could handle all of these requirements....
推荐答案
其实，答案很可能是一个1和3的组合。
Actually, the answer is probably a combination of 1 and 3.
您可以采取很多的工具的优势和功能，该框架为你写一个会员，角色或的资料提供商，如果默认选项不太走得太远，因为你想。
You can take advantage of a lot of the tools and features that the framework provides for you by writing a membership, role or profile provider if the default options don't quite go as far as you'd like.
我们已经做到了这一点对一些客户的网站 - 比如我们的一位客户拥有大部分用户的存储为商业服务器的用户，以及使用Commerce Server配置文件系统，所以我们写了一个会员和个人资料提供者跟这些数据存储 - 一个相当简单的锻炼; Tibial
We've done just that on a number of client sites - for example one of our clients has most of their users stored as Commerce Server users, and use the Commerce Server profile system, so we wrote a membership and profile provider to talk to those datastores - a fairly simple excercise.
大多数人都可能将因为需要通过原始TCP验证3 - 这引入了一层超出标准的 ASP.NET 会员提供商
Most people are probably going for 3 because of the need to authenticate over raw TCP - this introduces a layer beyond that of the standard ASP.NET membership providers.
大多数MS什么是产生OK或足够好，但总是会有优势的情况下，你想要做的事不太标准的意味着你最终滚动自己。我想有一些超越基本身份验证或Windows验证，这是简单的为您一般的开发人员了解，他们采取的明智的选择让刚刚建立的这个网络。
Most of what MS produce is "ok" or "good enough", but there will always be edge cases where you want to do something "not quite standard" that mean you end up rolling your own. I guess to have something beyond "Basic Auth" or "Windows Auth" that was simple for your average developer to understand, they took the sensible option of "lets just build this for the web".
如果你看看众多的方法可以对一个WCF服务进行身份验证，你就会明白我的意思 - 这些的是设计用来处理不同的传输机制，并因此更加复杂
If you take a look at the numerous ways you can authenticate against a WCF service, you'll see what I mean - these are designed to handle different transport mechanisms, and are therefore much more complex.
这是说，默认的角色和配置文件提供者相当有限（角色：没有等级之分，所以你需要检查每一个可能的角色，或明确指派每个角色给用户;配置文件：所有存储在一个字段作为逗号分隔价值观 - 不容易发现谁已经有了一个值集所有用户）
That said, the default roles and profile providers are fairly limited (roles: no hierarchy, so you need to check for each possible role, or explicitly assign each role to the user; profiles: all stored in one field as comma seperated values - not easy to find all users who've got a value set).
这篇关于其中认证和授权方案您使用的 - 为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
