SOAP服务中"On Behalf Of"实现方式咨询：HTTP头还是自定义SOAP头？

Great question! The answer depends on your architecture's consistency goals, existing standards, and the specific needs of your SOAP services—but let's walk through the key best practices here:

1. Prioritize Consistency When Possible #

If your REST services already use the X-On-Behalf-Of HTTP header for passing real user context, extending that same approach to your SOAP services is often the simplest and most maintainable choice. Here's why:

• Reduced cognitive load: Developers, DevOps, and security teams only need to learn and support one mechanism for tracking user context across all services.
• Unified monitoring & logging: You can reuse existing tooling to inspect and log the X-On-Behalf-Of header regardless of whether the request is REST or SOAP.
• Minimal code changes: Shared authentication/authorization middleware can check the same HTTP header for both service types without special SOAP-specific handling.

Example of using the HTTP header with SOAP:

POST /soap/service HTTP/1.1
Host: your-api.com
Content-Type: text/xml
X-On-Behalf-Of: johndoe@example.com

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <!-- Your SOAP request body here -->
  </soap:Body>
</soap:Envelope>

2. Use Custom SOAP Headers for SOAP-Specific Needs #

SOAP was designed with a dedicated <soap:Header> section for passing metadata (like authentication, context, or routing info), so this is the "native" approach for SOAP services. It's the better choice if:

• You need to pass structured user context (e.g., user ID, tenant ID, roles) that doesn't fit neatly into a single HTTP header value.
• Your SOAP services interact with other systems that expect SOAP-compliant header metadata (e.g., systems using WS-Security standards).
• You want to ensure the user context is part of the SOAP message itself (not just the transport layer)—critical if messages are routed through intermediaries that might modify HTTP headers.

Example of a custom SOAP header:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:ctx="http://your-api.com/context">
  <soap:Header>
    <ctx:OnBehalfOf>
      <ctx:UserId>johndoe123</ctx:UserId>
      <ctx:Email>johndoe@example.com</ctx:Email>
    </ctx:OnBehalfOf>
  </soap:Header>
  <soap:Body>
    <!-- Your SOAP request body here -->
  </soap:Body>
</soap:Envelope>

3. Align with Industry Standards for Security #

If your user context is part of a security or authentication flow, lean into established SOAP standards like WS-Security. For example:

• If you're passing a SAML assertion or OAuth token to authenticate the on-behalf-of user, wrapping it in a WS-Security header is a widely accepted best practice (rather than shoving it into an HTTP header).
• WS-Security headers are supported by most SOAP toolkits (e.g., Apache CXF, Microsoft WCF), making it easier to implement secure, interoperable services.

Final Recommendation #

There's no one-size-fits-all answer, but here's a quick decision tree:

• If you want to keep things simple and consistent with your existing REST implementation: Use the X-On-Behalf-Of HTTP header for SOAP.
• If you need structured context, interoperability with SOAP-native systems, or compliance with WS-Security standards: Use a custom SOAP header.

内容的提问来源于stack exchange，提问作者BartCr