如何使用基本身份验证将用户名/密码之外的更多数据传递到 WCF 4.0 RESTful 服务中的服务方法
要求：
WCF 4.0 IIS主机 使用自定义源进行基本身份验证 RESTful
有很多如何实现基本身份验证的示例和方法，使用 用户名密码验证器，通过ServiceAuthorizationManager 和 IDispatchMessageInspector 等。
我面临的问题是，验证实际上会从身份验证后端获取比是/否答案更多的信息。我想以某种方式将此信息传递给调用的服务方法（即它将是完整的 User 对象，具有许多属性来控制服务行为）。我想避免再次调用用户存储来根据用户名检索数据，我可以从安全上下文访问该数据。
到目前为止，我发现的最接近的是 此解决方案，它使用 < a href="http://aspnet.codeplex.com/releases/view/24644" rel="nofollow noreferrer">WCF REST Starter Kit 的 RequestInterceptor，我可以在其中注入 ServiceSecurityContext 的子类来处理我的数据，并将 ServiceSecurityContext.Current 强制转换回服务方法中。
上面的问题是，它是为 WCF 3.5 编写的，我想避免使用入门工具包。
问题：知道在链中最合适的位置是什么，这样我就可以将数据从验证逻辑传递到服务。或者换句话说，我可以用我的自定义安全上下文替换安全上下文来承担负载？或者有其他的载体机制吗？
我所追求的是这种行为：
客户端（可能是浏览器）尝试使用该服务： GET https://myservcer /服务/数据 服务器响应“需要基本身份验证” 客户端提供基本身份验证标头并再次发送请求 服务器根据标头中的用户/密码从数据库中提取用户对象。 如果找不到用户，则重新请求认证 如果找到用户，则 User 对象会以某种方式传递给服务方法 所有这一切都应该在不进行第二次往返数据库的情况下发生。
到目前为止，我的理解是， UserNamePasswordValidator 不会这样做 - 如果我在那里检索 User 对象，则无法传递它。
我可以创建一个自定义 IAuthorizationPolicy 或 SecurityToken（哪一个），然后将 User 对象放入其中。但是......这应该发生在哪里。我可以使用 UserNameSecurityTokenAuthenticator 来实现此目的吗？它会返回正确的 HTTP 错误代码来请求凭据吗？如何/在哪里修改 web.config 以使用我的自定义内容？到目前为止，我了解了如何设置仅使用自定义 UserNamePasswordAuthenticator。
编辑：请检查我自己对我的方法的回答。不过这个问题很好，我得到的答案也很有价值。
The requirements:
WCF 4.0
IIS host
Basic authentication with custom source
RESTful
There are plenty of examples and ways how to implement the basic authentication, from using UserNamePasswordValidator, trough ServiceAuthorizationManager and IDispatchMessageInspector, etc.
The problem I'm facing is, that the validation actually will fetch much more information from the authentication backend, than yes/no answer. And I want to pass this information somehow to the invoked service methods (i.e. it'll be full blown User object, with many properties to control the service behavior). I want to avoid a second call to the user store to retrieve the data based on the username, which I can access from the security context.
So far, the closest thing I found is this solution, which uses the WCF REST Starter Kit's RequestInterceptor, in which I can inject a subclass of ServiceSecurityContext to carry on my data, and cast ServiceSecurityContext.Current back in the service method.
The problem with the above is, that it's written for WCF 3.5, and that I would like to avoid using the Starter Kit.
The question: any idea what would be the most appropriate place to hook into in the chain, so I can pass a data from the validation logic to the service. Or to put it another way, where I would be able to replace the security context with my custom one to carry on the load? Or any other carrier mechanism?
What I'm after is that behavior:
Client (could be a browser) tries to use the service: GET https://myservcer/service/data
The server responds with "Basic Authentication Needed"
The client supplies Basic Authentication Header and sends the request again
The server, based on the user/pass in the header, pulls out a User object out of database.
If the user is not found, request authentication again
If the user is found, the User object is somehow passed the service method
All this should happen without making second roundtrip to the database
So far, what I understand is, that UserNamePasswordValidator will not do - there's no way to pass the User object if I retrieve it there.
I can create a custom IAuthorizationPolicy or SecurityToken (which one), and put the User object in. But ... where this should happen. Can I go with UserNameSecurityTokenAuthenticator for this? Is it going to return the right HTTP error code to ask for credentials? How/where I modify the web.config to use my custom stuff? So far I see how set to use a custom UserNamePasswordAuthenticator only.
EDIT: pls check my own answer for my approach. Nevertheless the question was good, and the answers I got were valuable.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们实现了自己的身份验证 HTTP 模块。该模块挂钩 HttpApplication 的“根据请求进行身份验证”事件，并对后端运行身份验证。后端可以自由地返回它想要的任何内容（在我们的例子中，它返回的不仅仅是是/否。返回的对象实现了 System.Security.Principal.IIdentity 接口。一旦身份验证成功，我们就附加身份（由auth) 到 HttpContext.User 中携带的主体。
在管道中，您可以随时访问当前上下文的 User 并获取您的所有身份信息。
这种方法的唯一显着缺点是它需要 ASP.net。兼容性，但如果您已经像这样运行 Rest 服务，那么这应该不是问题。
We implemented our own authentication HTTP module. The module hooks into the "on request authenticate" event of the HttpApplication and runs the authentication against the backend. The backend is free to return anything it wants (and in our case it returns more than yes/no. The object that gets returned implements the System.Security.Principal.IIdentity interface. Once the authentication succeeds we attach the identity (object returned by auth) to the principal that gets carried in the HttpContext.User.
Down the pipeline you can access the current context's User at any point and get all of your identity's info.
The only significant drawback of this approach is that it requires ASP.net compatibility, but if you are already running your Rest services like that then it shouldn't be a problem.
您可以创建 IAuthorizationPolicy 的实现，并将主要身份替换为您在身份验证期间获得的身份。查看这些链接，其中显示了如何避免两次访问数据库：
WCF 自定义验证器：如何从自定义验证器初始化“用户”对象
何时以及在实现自定义身份验证时在哪里设置自定义 IIdentity
You can create an implementation of IAuthorizationPolicy and replace the primary identity with the one you get during authentication. Have a look at these links which show how to avoid hitting database twice:
WCF Custom Validator: How to initialize a “User” object from custom validator
When and where to set custom IIdentity when implementing custom authentication
我最终根本没有使用 WCF。 Nancy 更容易创建和测试 RESTFull API，并且使用 最新更改（它将在0.8版本中）我问的问题非常简单。
I ended up not using WCF at all. Nancy was much easier to create and test RESTFull API, and with the latest changes (it'll be in 0.8 ver) what I was asking about is very easy.