WCF、活动目录身份验证|授权和sql组合中的用户配置文件
我正在开发一个 WCF 服务，它将托管应用程序的业务逻辑。该应用程序主要用于内部网，但也可以从互联网访问。我们有一个正在运行的活动目录域，所以我计划根据用户的用户名和所在组对用户进行身份验证和授权。该服务将主要用于 ASP.NET MVC 站点
所以，第一个问题是如何进行身份验证和 授权根据用户的 AD 配置文件授权用户？
其次，我需要存储有关每个用户的附加信息。问题是我无法修改AD方案。添加的字段数量大约是10个左右。
我可以以某种方式使用 SQL Server 进行配置文件存储吗？当然可以，但是如何将其与 AD 身份验证结合起来？
I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为此，您可以使用 WIF。
您可以按照正常方式为 WIF 配置 WCF 服务，然后使用从基本
ClaimsAuthenticationManager派生的自定义ClaimsAuthenticationManager类并重写其Authenticate方法。这是WIF的正常扩展点。 WIF将从传入请求中获取安全令牌，并为每个相关的 AD 属性添加声明。在重写 Authenticate 方法时，您将添加新的声明来表示您的额外属性。
WCF 服务的 WIF 基本用法如下所述：
http://msdn.microsoft .com/en-us/library/ee748476.aspx
要了解如何使用 ClaimsAuthenticationManager，请从这里开始：
http://msdn.microsoft.com/en-us/library/ee748211.aspx
You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom
ClaimsAuthenticationManagerclass deriving from the baseClaimsAuthenticationManagerand overriding itsAuthenticatemethod. This is a normal extensibility point of WIF. WIF willget hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx
好吧，我认为你在这里有几个选择，但你必须仔细考虑实施。
使用活动目录身份验证的主要问题是默认情况下用户的凭据只能在两台计算机之间成功传递。对于 Web 应用程序，这意味着用户的凭据可以在最终用户的计算机和 Web 服务器之间传输，但不能再进一步传输。
然而，这种行为可以通过使用 Kerberos 身份验证来改变，Kerberos 身份验证本质上允许身份验证票证在链中的所有受信任机器之间传递（即，例如从 Web 服务器到应用程序服务器再到数据库）。成功配置 Kerberos 可能非常具有挑战性，特别是如果您之前没有相关经验的话。
我认为最好的选择是将您的网站配置为仅接受 Windows 身份验证。这意味着 IIS 将根据活动目录执行用户验证。在 ASP.Net 应用程序中，您可以从 Request.ServerVariables("logon_user") 中获取授权用户的域名。
例如，此时，您可以使用 FormsAuthentication 登录用户，而无需他们再次登录。
然后，您可以实现 SQL Server 成员资格提供程序或创建自己的数据库接口，以进行进一步的用户验证和额外的信息存储。我们使用了这两种机制，但我更喜欢自建机制，因为它提供了额外的控制，在这种情况下，您不需要会员资格提供商提供的大量功能（密码重置、恢复等） 。
Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.