WCF ServiceSecurityContext 存储适合自定义数据吗?

发布于 2024-08-07 09:20:24 字数 649 浏览 11 评论 0原文

我有一个使用 Windows 身份验证的 WCF 应用程序。因此,我将在 System.Threading.Thread.CurrentPrincipal() 属性中找到 Windows 主体对象。这样就一切都好了。但是,我还有一个自定义主体对象,用于更细粒度的授权和审核。这是域用户,而不是 Windows 用户。我确实需要两者,并且正在寻找一个在服务端存储自定义用户的位置,以便在服务上运行的所有代码(通过业务层和数据层)都可以访问该用户。

客户端和服务器之间的通信由自定义行为和消息检查器处理。当从客户端(ASP.NET Web 应用程序)调用服务时,这会从会话中获取当前用户并将其序列化为服务调用上的自定义标头。然后,在服务端,它将主体从标头中剥离出来,并将自定义主体放在这里:

OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties("CurrentDomainUser")

因此,验证此方法的问题

  1. 是:这是在服务上存储自定义主体的有效方法吗?请记住,我希望 Windows 身份验证保持不变。
  2. 这是“最佳实践”吗?或者有更好的方法吗?
  3. 这种方法有什么需要注意的陷阱或陷阱吗?

感谢您的意见。

I have a WCF application that is using Windows Authentication. So a Windows Principal object is what I will find in the System.Threading.Thread.CurrentPrincipal() property. That's is all fine. However, I also have a custom principal object that is used for finer grained authorizations and auditing. This is a domain user, not a windows user. I really need both and am looking for a place to store the custom user on the service side so that all the code that runs on the service, down through Business and Data layers, can access this user.

The communication between client and server is handled by a custom behavior and message inspector. When calling the service from the client (ASP.NET Web Application), this gets the current user from session and serializes it to a custom header on the service call. On the service side it then strips the principal out of the header and puts the custom principal here:

OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties("CurrentDomainUser")

So, questions to validate this approach:

  1. Is this a valid approach to storage of a custom principal on the service. Keeping in mind I want to Windows Authentication to stay in place.
  2. Is this "best practice"? Or is there a better way?
  3. Any traps or pitfalls to watch for with this approach?

Thanks for the input.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

独享拥抱 2024-08-14 09:20:24

我无法具体回答这是否是最佳实践,但您可以在传出消息标头中传递自定义数据。

以下是从客户端调用 WCF 服务的示例

MyAccountService.MyAccountServiceClient client = new MyAccountServiceClient();
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
    MessageHeader customHeader = MessageHeader.CreateHeader("customData", "ns", "My custom data");
    OperationContext.Current.OutgoingMessageHeaders.Add(customHeader);

    List<Bill> list = client.BillHistory("12345", DateTime.Now.AddMonths(-1), DateTime.Now);
}

在服务端,您可以检查传入的消息标头。

public IList<Bill> BillHistory(string accountID, DateTime datefrom, DateTime dateTo)
{
    string customData = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("customData", "ns");
...etc...
}

I can't specifically answer if this is the best practice or not, but you can pass custom data in the outgoing message headers.

Here is an example calling a WCF service from the client

MyAccountService.MyAccountServiceClient client = new MyAccountServiceClient();
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
    MessageHeader customHeader = MessageHeader.CreateHeader("customData", "ns", "My custom data");
    OperationContext.Current.OutgoingMessageHeaders.Add(customHeader);

    List<Bill> list = client.BillHistory("12345", DateTime.Now.AddMonths(-1), DateTime.Now);
}

On the service side, you can inspect the incoming message headers.

public IList<Bill> BillHistory(string accountID, DateTime datefrom, DateTime dateTo)
{
    string customData = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("customData", "ns");
...etc...
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文