使用 IIS7、WCF Rest、自定义身份验证模块进行模拟
所以我正在努力建立一个 WCF 服务，托管在 iis7 中。该服务是 REST 服务。
到目前为止，我们对身份验证的要求是只有域帐户才能连接到该服务。我们使用基本身份验证并使用模拟通过业务层向数据库进行调用。
这一切都运作良好。
现在我们需要允许非域帐户使用我们的服务。由于 IIS 的原因，我实现了这个（http://custombasicauth.codeplex.com/）和一个自定义成员资格提供程序，该提供程序将（取决于传入的用户名）尝试针对 Active Directory 或针对 asp.net 成员身份进行身份验证提供者。这部分工作正常。
我现在遇到的问题是模仿不起作用（这是可以理解的）。现在，这就是我迷失的地方，需要帮助来指导或清除所有迷雾。我想要做的（我不知道这是否可能）是这样的：
如果用户是域用户，则模拟他们的帐户。 如果不是域用户，则模拟“通用用户域帐户”。 作为奖励，我希望这发生在“幕后”，这样我们的每个方法就不需要添加特殊的逻辑来处理这个问题。
我读过很多关于身份、政策提供者、角色提供者的东西……现在我完全困惑了。
有人对此有一些见解吗？
So I am working on setting up a WCF service, hosted in iis7. The service is a REST service.
Up till now our requirements for authentication were that only domain accounts were going to connect to the service. We are using basic authentication and using impersonation for making calls through our business layer to our DB.
This is all working well.
Now we have the need to allow non-domain accounts to use our service. Due to somethings with IIS I implemented this (http://custombasicauth.codeplex.com/) and a custom membership provider that will (depending on the username passed in) either attempt to Auth against Active Directory, or against a asp.net membership provider. This part is working correctly.
The issue now that I have is that impersonation is not working (which is understandable.) Now, this is where I am lost and need help with direction or clearing of all the fog. What I want to do (and I don't know if this is possible) is this:
IF a user is a domain user THEN impersonate their account.
IF NOT a domain user THEN impersonate the "generic user domain account".
As a bonus I would like to this to happen "behind the scene" so that each method we have doesn't need special logic added to handle this.
I have read a bunch of stuff about identities, policy providers, role providers...and now I am thoroughly confused.
Anyone have some insight into this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，在网上查找有关 IIS 模拟工作的更多信息后，我找不到太多有用的信息。所以我开始更多地研究“破解”它。
我使用这个（http://custombasicauth.codeplex.com/）来允许我们使用 WCF 进行自定义基本身份验证。
该模块的流程是LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.OnEnter()
当连接建立时被调用。这又调用
LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.AuthenticateUser() 最终调用
LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.SetPrincipal(string username)
我将 SetPrincipal 更改为也接受密码
private static void SetPrincipal(string username, string password)
在这里，我对用户名做了一个简单的 if （检查我们的域前缀）来确定用户是否是域帐户。如果它是域帐户，我使用他们的用户名/密码创建一个WindowsIdentity（我使用http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx，进行一些重构即可获取WindowsIdentity）。如果用户不是域帐户，我会为其使用已知的硬编码域帐户。
然后，我使用此 WindowsIdentity 并创建一个 WindowsPrincipal 并将其设置为 HttpContext.Current.User
所以这对我们有用。模仿正在发挥作用。这样做的副作用是，我们不需要使用 [OperationBehavior(Impersonation = ImpersonationOption.Required)] 属性来修饰 WCF 方法。我不知道这是否是“正确”的做法，但我认为它非常接近。我认为 IIS 检测到当前用户中有一个 WindowsPrincipal 并自动模拟该帐户。
So after a lot of looking online for more information on impersonation works with IIS, I couldn't find much helpful info. So I began to look more into "hacking" it in.
I was using this (http://custombasicauth.codeplex.com/) to allow us to have custom basic authentication with WCF.
how this module flows is LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.OnEnter()
is called when a connection is established. This in turn calls
LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.AuthenticateUser() which, eventually calls
LeastPrivilege.CustomBasicAuthentication.CustomBasicAuthenticationModule.SetPrincipal(string username)
I changed SetPrincipal to accept a password also
private static void SetPrincipal(string username, string password)
In here I do a simple if on the username (checking for a our domain prefix) to determine if the user is a domain account or not. If it is a domain account I use their username/password to create a WindowsIdentity (I used http://www.codeproject.com/KB/dotnet/UserImpersonationInNET.aspx with a little refactoring to get just the WindowsIdentity). If the user wasn't a domain account I use a known hardcoded domain account for them.
I then take this WindowsIdentity and create a WindowsPrincipal and I set that to HttpContext.Current.User
So this works for us. Impersonation is working. As a side effect of this we don't need to decorate our WCF methods with the [OperationBehavior(Impersonation = ImpersonationOption.Required)] attribute. I don't know if this is the "Correct" way of doing it, but I think it is pretty close. I think IIS detects that there is a WindowsPrincipal in Current User and automatically impersonates that account.