Share via


Activity Tracing in Message Security

This topic describes activity tracing for security processing, which happens in the following three phases.

  • Negotiation/SCT exchange. This can happen at the transport later (through binary data exchange) or message layer (through SOAP message exchanges).

  • Message encryption/decryption, with signature verification and authentication. Traces appear in the ambient activity, typically "Process Action."

  • Authorization and verification. This can happen locally or when communicating between endpoints.

Negotiation/SCT exchange

In the negotiation/SCT exchange phase, two activity types are created on the client: "Set up Secure Session" and "Close Secure Session." "Set up Secure Session" encompasses traces for the RST/RSTR/SCT message exchanges, while "Close Secure Session" includes traces for the Cancel message.

On the server, each request/reply for the RST/RSTR/SCT appears in its own activity. If propagateActivity=true on both the server and client, activities on the server have the same ID, and appear together in the "Setup Secure Session" when viewed through Service Trace Viewer.

This activity tracing model is valid for user name/password authentication, certificate authentication, and NTLM authentication.

The following table lists the activities and traces for negotiation and SCT exchange.

Time when Negotiation/SCT exchange happens Activities Traces

Secure Transport

(HTTPS, SSL)

On first message received.

Traces are emitted in the ambient activity.

  • Exchange traces

  • Secure channel established

  • Share secrets obtained.

Secure Message Layer

(WSHTTP)

On first message received.

On the client:

  • "Setup Secure Session" out of "Process Action" of that first message, for each request/reply for RST/RSTR/SCT.

  • "Close Secure Session" for the CANCEL exchange, out of the "Close Proxy activity." This activity may happen out of some other ambient activity, depending on when the secure session is closed.

On the server:

  • One "Process Action" activity for each request/reply for RST/SCT/Cancel on the server. If propagateActivity=true, RST/RSTR/SCT activities are merged with "Set up Security Session", and Cancel is merged with the "Close" activity from the client.

There are two stages for "Set up Secure Session":

  1. Authentication negotiation. This is optional if the client already has the proper credentials. This phase can be done through secure transport, or through message exchanges. In the latter case, 1 or 2 RST/RSTR exchanges can happen. For these exchanges, traces are emitted in new request/reply activities as previously designed.

  2. Secure session establishment (SCT), in which one RST/RSTR exchange happens here. This has the same ambient activities as described previously.

  • Exchange traces

  • Secure channel established

  • Share secrets obtained.

Aa738609.note(en-us,VS.85).gifNote:
In mixed security mode, negotiation authentication happens in binary exchanges, but SCT happens in message exchange. In pure transport mode, negotiation happens only in transport with no additional activities.

Message Encryption and Decryption

The following table lists the activities and traces for message encryption/decryption, as well as signature authentication.

Secure Transport (HTTPS, SSL) and Secure Message Layer (WSHTTP)

Time when message encryption/decryption, as well as signature authentication happens

On message received

Activities

Traces are emitted in the ProcessAction activity on the client and server.

Traces

  • sendSecurityHeader (sender):

  • Sign message

  • Encrypt request data

  • receiveSecurityHeader (receiver):

  • Verify signature

  • Decrypt response data

  • Authentication

Aa738609.note(en-us,VS.85).gifNote:
In pure transport mode, message encryption/decryption happens only in transport with no additional activities.

Authorization and Verification

The following table lists the activities and traces for authorization.

Time when authorization happens Activities Traces

Local (default)

After the message is decrypted on the server

Traces are emitted in the ProcessAction activity at the server.

User authorized.

Remote

After the message is decrypted on the server

Traces are emitted in a new activity invoked by the ProcessAction activity.

User authorized.