1

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

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

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

因此，验证这种方法的问题：

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

感谢您的输入。

4

1 回答 1

2

我无法具体回答这是否是最佳做法，但您可以在传出邮件标题中传递自定义数据。

这是一个从客户端调用 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...
}
于 2009-12-14T16:15:07.783 回答