none
WCF Interoperability problem - Timestamp is required to be signed

    Question

  • Hi,

    I'm creating simple WCF (CTP February) service & Java (JWSDP 2.0) client  interoperability sample with WS-Security (XWSS 2.0). WCF throws following error: Security header element 'Timestamp' with id 'xxxx' is required to be signed, but was not, although timestam IS signed. Below is the request message sent to WCF service:

    Does anybody know what's wrong with the request? Can I somehow disable the check for signed timestamp? Any other ideas to solve the problem?

    Thanx for help.

    Marko


     

    <?xml version="1.0" encoding="UTF-8"?>

    <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

    <SOAP-ENV:Header>

    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" SOAP-ENV:mustUnderstand="1">

    <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">

    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>

    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <wsse:SecurityTokenReference>

    <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">h3Spnha6kM9R0SXxlGerM5gm364=</wsse:KeyIdentifier>

    </wsse:SecurityTokenReference>

    </ds:KeyInfo>

    <xenc:CipherData>

    <xenc:CipherValue>slSzc/8CSImsGU3Nea22H7zL1cNZIKNDLljMNjYEUoJB0f/32WUSiw6e2KaKdQHIF9eENubp1CJFbHCBzxL3ygQFcc4xb6vO+wJgwCw3PhcOotyo51p00nrGQoYOONMI2PbHlm91mfhTyhafveD9mSB153BAir/2hIzxVqTk58fYw/kvI+qq5poVFi5JApFe4KWGUXrFbIgBBzUX+YQuWZgvhHaeudGrtS1gNxxRUYrcca3wR6mOF2BQ8VuWkqeKRzoOhb2Qa0yP3fzjpNhPsOQUS5VSjSpjeKwzi9iLQRPeXN+ukN52qDX9xF5nqbEMzP3yMBofsR6FdM03uizdSA==</xenc:CipherValue>

    </xenc:CipherData>

    <xenc:ReferenceList>

    <xenc:DataReference URI="#XWSSGID-1147796708117-134232920"/>

    </xenc:ReferenceList>

    </xenc:EncryptedKey>

    <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-11477967065831226673930">MIIEujCCA6KgAwIBAgIBCjANBgkqhkiG9w0BAQUFADB3MS0wKwYDVQQDEyRMYWJvcmF0b3JpaiB6YSBpbmZvcm1hY2lqc2tlIHNpc3RlbWUxCzAJBgNVBAYTAlNJMQ0wCwYDVQQKEwRGRVJJMQwwCgYDVQQLEwNMSVMxHDAaBgkqhkiG9w0BCQEWDWxpc0B1bmktbWIuc2kwHhcNMDYwNDE1MTYyMjAzWhcNMTEwNDE0MTYyMjAzWjCBjTEUMBIGA1UEAxMLTWFya29UZWthdmMxCzAJBgNVBAYTAlNJMRAwDgYDVQQHEwdNYXJpYm9yMRIwEAYDVQQIEwlTdGFqZXJza2ExDTALBgNVBAoTBEZFUkkxDDAKBgNVBAsTA0xJUzElMCMGCSqGSIb3DQEJARYWbWFya28udGVrYXZjQHVuaS1tYi5zaTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMgyY9RFnW5xyDfrSC9JEAjU+7jVCihFnWCHkbqvnk9E7NeAycLGKFIilhC092EdYJywkOJoGeC/AYAACjk94sTTVl8ta0fQPC31HRWjsWFVmT6WJXIWHMJuWyv5MEUSjexUGfljfb184gQmC9QWHg7b4BLl/8JM3uQWz6FyfW/Xco9vrEjfqYBysr3pDMl7x7/Vj6S3hlYkJPwV4Hhk/L4lGAPudPNE4jJhlDQFxerViJGzFKIAvf6oTAv1XEt6vMDPigWolvbzqzfyEa1sybhUPhccj431pYguIY2cXk+w+ew3UodhTNVxvle9VRYs3uT+iSSJi4SZiRu+hmLHe/cCAwEAAaOCATgwggE0MAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFOVmBIoSEVIPyoljscvyfv6LDyWMMIGhBgNVHSMEgZkwgZaAFG0wdIFFYYItVn47oRFtgb/EHAJtoXukeTB3MS0wKwYDVQQDEyRMYWJvcmF0b3JpaiB6YSBpbmZvcm1hY2lqc2tlIHNpc3RlbWUxCzAJBgNVBAYTAlNJMQ0wCwYDVQQKEwRGRVJJMQwwCgYDVQQLEwNMSVMxHDAaBgkqhkiG9w0BCQEWDWxpc0B1bmktbWIuc2mCAQEwCwYDVR0PBAQDAgSwMCEGA1UdEQQaMBiBFm1hcmtvLnRla2F2Y0B1bmktbWIuc2kwEQYJYIZIAYb4QgEBBAQDAgWgMB4GCWCGSAGG+EIBDQQRFg94Y2EgY2VydGlmaWNhdGUwDQYJKoZIhvcNAQEFBQADggEBAE3hfaMHNy0/8H6PqC4tUkbn0QpugrW/xjkb5UXZqy+k2GX5Ea4WyTxyNbKim2i0/xBshaWUgSP0mb9BK0zF08rlP8AH+MItkKsO87tRmhk8e1iSuwy53iGBJYHUe1jlmZR7NCCoEQZgzzGGwoqUL2bN+YWtKR61PBMCoVvoXGeDnjXLuBXM7nUZcUh+9+hiamuKiMZeIbO7uM8Eh8mo0uWiT+reSbXlCR+wJrd7I1YYB63GJKCSTfNY22kPKS60KtAvCyVepFqBT2SouCVwUwkt5HeWIjD6//YIHWPSpJqc9SSAqu6xtjbIvBu43+lZkbrRA3OH3EbTYx/f4b+0AlY=</wsse:BinarySecurityToken>

    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

    <ds:SignedInfo>

    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

    <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse SOAP-ENV"/>

    </ds:CanonicalizationMethod>

    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

    <ds:Reference URI="#XWSSGID-11477967073851115499696">

    <ds:Transforms>

    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

    <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsu wsse SOAP-ENV"/>

    </ds:Transform>

    </ds:Transforms>

    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

    <ds:DigestValue>nrXip4qVKVOu0Pb6UJ+wHoTDFgU=</ds:DigestValue>

    </ds:Reference>

    <ds:Reference URI="#XWSSGID-11477967073951019474954">

    <ds:Transforms>

    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

    <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"

    PrefixList="SOAP-ENV"/>

    </ds:Transform>

    </ds:Transforms>

    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

    <ds:DigestValue>rOL1wF3XGXKQFbc1imdbZidsCls=</ds:DigestValue>

    </ds:Reference>

    </ds:SignedInfo>

    <ds:SignatureValue>Fy7YhAhHMxx1x/GiPtzaM6Vwa7g9bjaFcAwbre34j/IfJiLP9ikUwtutmACtjiqPWfES6Y8LDulswCsmlmDbiUyoVQfJ5Dvz1CnvWXNZMqaPrLfXjmyJNWx9PIQSZzFTetoghKhZGQdhe7dJI8Zesji9nzTHa9tE22RDQ4Tqfm6rCEZHBWo+1CRE+Do/H/tZ3pxd6Hls8hPDMyboy/JwYPNiQsHoD0hhBVOD+3eD+y2vOm+mEJvZYVy8uuxhYzcGG2F/Ihs2D5fD6Ce5Q1LD26SrC7SO54R7NcjUnfNIjmoevJQHfeQ2Qz0cVaDj1sGFt2MSg35uMrCzJ3plERjEIw==</ds:SignatureValue>

    <ds:KeyInfo>

    <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1147796707295-382244904">

    <wsse:Reference URI="#XWSSGID-11477967065831226673930" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>

    </wsse:SecurityTokenReference>

    </ds:KeyInfo>

    </ds:Signature>

    <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-11477967073851115499696">

    <wsu:Created>2006-05-16T16:25:07Z</wsu:Created>

    <wsu:Expires>2006-05-16T16:30:07Z</wsu:Expires>

    </wsu:Timestamp>

    </wsse:Security>

    </SOAP-ENV:Header>

    <SOAP-ENV:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-11477967073951019474954">

    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="XWSSGID-1147796708117-134232920" Type="http://www.w3.org/2001/04/xmlenc#Content">

    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>

    <xenc:CipherData>

    <xenc:CipherValue>PR8AEl2OnoU7kDVgjZVZ8Sgrov7dCu+zMzu/8N5IUllf0EHTmle3AbowPwrms9EKOOVvwFbvgqk20O/et3+IF9MPGak8lFFb5gYgyxQ+TIutmeGX7nuT3NppkeEvoipDT6ZlAQ/0S2Ym0EOCJlTtO/O/l8eWkLALHBm67H0O9VN2IkGcE+o8VWclxJO9sReWgHfYANkEp+rdXTV+qE01qq4bF6gEb70kAfxinzeFMvo5/rGZIQC0OMYUHP7CjLMlbE5etBHLl5c4cm3KJv/JdDSn5Hj3zRQfcs0LdlGpngc=</xenc:CipherValue>

    </xenc:CipherData>

    </xenc:EncryptedData>

    </SOAP-ENV:Body>

    </SOAP-ENV:Envelope>

     

    Wednesday, May 17, 2006 7:34 AM

Answers

  • WCF by default strips certain content from the logged messages because it can potentialy contain a PII piece in it. The certificates are one such potential source.

    However, there is a way how to disable this feature but you need to have access to the machine.config in the .NET framework config directory. Here are the steps to disable PII stripping. Please note that this does not work in WCF releases prior to Feb CTP. There is no way how to enable PII logging in older releases.

    machine.config:

    machine.config is ACL'd so that it can only be edited by machine administrators. An administrator can grant or deny applications permission to log known PII data by setting enableLoggingKnownPII to true or false. If this entry is missing from machine.config, permission to log PII info will be denied (see “preventing a person from overriding machineSettings” section below).

    <configuration>
      <system.serviceModel>
        <machineSettings enableLoggingKnownPii=“true”/>
      </system.serviceModel>
    </configuration> 


    - app.config:

    If an administrator has granted machine-wide permission to trace/log known PII information as shown above, an application deployer can enable tracing/logging of PII info with the following entry in app.config

      <system.diagnostics>
          <source name="System.ServiceModel.MessageLogging" switchValue="Verbose, ActivityTracing" logPii ="true" >
            <listeners>
              …
            </listeners>
          </source>
        </sources>
      <system.diagnostics>

    The logPii attribute is renamed to logKnownPii in the future versions (after Feb CTP)

    Saturday, May 20, 2006 8:19 PM
  •  

    Thanks Jan for the correction.

    I had tried that out - among other things - but got errors everytime.

    To be specific for anyone else reading this the insert has to go after the </configSections - makes sense to me now.

    It will produce an error in the config file (if reading it in Visual Studio) as will the  logKnownPii="true" in the App.config or Web.config.  The intellisense will say attribute not declared.  You will not know until you run the application that it is OK.

     

    Friday, January 19, 2007 8:44 AM

All replies

  • Hi Marko,

    it seems that you are hitting an issue that is caused by incorrect ordering of elements inside the security header. By default WCF enforces that wsu:Timestamp is the first element that appears in the security header and throws if it is not.

    One of the rules about elements ordering in the security header is that the wsu:TimeStamp element must appear as the first element in the security header. Because the security header is processed by the receiver in the direction from the first element to the last element this allows detection of messages with invalid timestamp early in the message processing.

    However, if you cannot make your client to generate security header with the right element order, WCF provides a switch that allows you to relax this ordering requirement. You will need to use a custom binding in this case though. The element ordering requirement is controlled by securityHeaderLayout attribute on the security binding element. You can change it to "lax" in which case WCF will not strictly enforce the element ordering in the message. From your example is seems that you are using X.509 certificates to authenticate both client and the service. The custom binding section of the configuration would look similarly to this in this case:

    <customBinding>

      <binding name="MutualCertificateBinding">

        <security authenticationMode="MutualCertificate" securityHeaderLayout="Lax"/>

        <httpTransport/>

      </binding>

    </customBinding>

    Regards,

    --Jan

    Wednesday, May 17, 2006 9:13 PM
  • Thanks, that was helpfull. But I've hit the wall with another problem. Now I've created custom binding:

    <customBinding>
            <binding name="wsMutualCertificateBinding">
              <security authenticationMode="MutualCertificate"
                requireDerivedKeys="false" securityHeaderLayout="Lax">
              </security>
              <textMessageEncoding messageVersion="Soap11WSAddressing10" />
              <httpTransport mappingMode="Soap" />
            </binding>
    </customBinding>

    and i get the following error:

    System.ServiceModel.Security.MessageSecurityException: Unable to resolve KeyInfo for verifying signature: KeyInfo 'SecurityKeyIdentifier ( IsReadOnly = False, Count = 1, Clause[0] = LocalIdKeyIdentifierClause(LocalId = 'XWSSGID-11480656220002061852348', Owner = 'System.IdentityModel.Tokens.X509SecurityToken') ) ', available tokens 'SecurityTokenResolver ( TokenCount = 0, )

    I have no idea what this means. Here is the part of message with KeyInfo:

    <ds:KeyInfo>
    <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1148065622781-442903871">
      <wsse:Reference URI="#XWSSGID-11480656220002061852348" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>

    I would appreciate any help.

    Marko

    Friday, May 19, 2006 7:29 PM
  • It seems that there is a missing BinarySecurityToken element containing the X.509 certificate with the wsu:Id attribute that would have the value that used in the signature ds:KeyInfo security token reference - XWSSGID-11480656220002061852348

     

    Friday, May 19, 2006 7:44 PM
  • Yes, it's missing. I've traced the message with svcTraceViewer and it seems that WCF removed the token. Instead of BinarySecurityToken as seen in my first post (message in first post is as sent from Java client) the message in svcTraceViewer shows:

    <wsse:BinarySecurityToken>
    <!-- Removed --> 
    </wsse:BinarySecurityToken>

    Am I missing something?

     

     

    Friday, May 19, 2006 10:22 PM
  • WCF by default strips certain content from the logged messages because it can potentialy contain a PII piece in it. The certificates are one such potential source.

    However, there is a way how to disable this feature but you need to have access to the machine.config in the .NET framework config directory. Here are the steps to disable PII stripping. Please note that this does not work in WCF releases prior to Feb CTP. There is no way how to enable PII logging in older releases.

    machine.config:

    machine.config is ACL'd so that it can only be edited by machine administrators. An administrator can grant or deny applications permission to log known PII data by setting enableLoggingKnownPII to true or false. If this entry is missing from machine.config, permission to log PII info will be denied (see “preventing a person from overriding machineSettings” section below).

    <configuration>
      <system.serviceModel>
        <machineSettings enableLoggingKnownPii=“true”/>
      </system.serviceModel>
    </configuration> 


    - app.config:

    If an administrator has granted machine-wide permission to trace/log known PII information as shown above, an application deployer can enable tracing/logging of PII info with the following entry in app.config

      <system.diagnostics>
          <source name="System.ServiceModel.MessageLogging" switchValue="Verbose, ActivityTracing" logPii ="true" >
            <listeners>
              …
            </listeners>
          </source>
        </sources>
      <system.diagnostics>

    The logPii attribute is renamed to logKnownPii in the future versions (after Feb CTP)

    Saturday, May 20, 2006 8:19 PM
  • Hello Jan_Alexander,

    I tried to edit the Machine.config as you demonstrated in this thread;

    "machine.config:

    machine.config is ACL'd so that it can only be edited by machine administrators. An administrator can grant or deny applications permission to log known PII data by setting enableLoggingKnownPII to true or false. If this entry is missing from machine.config, permission to log PII info will be denied (see “preventing a person from overriding machineSettings” section below).

    <configuration>
      <system.serviceModel>
        <machineSettings enableLoggingKnownPii=“true”/>
      </system.serviceModel>
    </configuration>  "


    but I keep getting an error "Configuration system failed to initialize".

    Has the structure of the Machine.config changed since this article?

    Thanks,

    Edmund.

    Thursday, January 18, 2007 11:03 PM
  • No the information in the post is still valid. Do you have the following in your machine.config?

        <sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
          <section name="behaviors" type="System.ServiceModel.Configuration.BehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="bindings" type="System.ServiceModel.Configuration.BindingsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="client" type="System.ServiceModel.Configuration.ClientSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="comContracts" type="System.ServiceModel.Configuration.ComContractsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="commonBehaviors" type="System.ServiceModel.Configuration.CommonBehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" />
          <section name="diagnostics" type="System.ServiceModel.Configuration.DiagnosticSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="extensions" type="System.ServiceModel.Configuration.ExtensionsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" />
          <section name="serviceHostingEnvironment" type="System.ServiceModel.Configuration.ServiceHostingEnvironmentSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="services" type="System.ServiceModel.Configuration.ServicesSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </sectionGroup>

    If the elements above are not there, you need to properly install NetFX 3.0 so that the configuration sections are known to the .NET configuration framework.

    --Jan

     

    Friday, January 19, 2007 12:39 AM
  • Hello Jan,

    Yes that looks very like my Machine.config so I assumed that I could add the attribute to the end of the line as below; 

    <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" />

    to make it look like this;

    <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" enableLoggingKnownPii=“true" />

    but I get the same runtime error when I run the application.

    Thanks,

    Edmund.

     

     

     

    Friday, January 19, 2007 12:59 AM
  • This is not how it works. The section element is used to introduce that particular section to the configuration framework. To actually set the parameters through that section, you need to use it explicitly. In other words, you need to add a new <system.serviceModel> element after the <sectionGroup> element, something like this:

        <sectionGroup name="system.serviceModel" type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
          <section name="behaviors" type="System.ServiceModel.Configuration.BehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="bindings" type="System.ServiceModel.Configuration.BindingsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="client" type="System.ServiceModel.Configuration.ClientSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="comContracts" type="System.ServiceModel.Configuration.ComContractsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="commonBehaviors" type="System.ServiceModel.Configuration.CommonBehaviorsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" />
          <section name="diagnostics" type="System.ServiceModel.Configuration.DiagnosticSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="extensions" type="System.ServiceModel.Configuration.ExtensionsSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="machineSettings" type="System.ServiceModel.Configuration.MachineSettingsSection, SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowDefinition="MachineOnly" allowExeDefinition="MachineOnly" />
          <section name="serviceHostingEnvironment" type="System.ServiceModel.Configuration.ServiceHostingEnvironmentSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
          <section name="services" type="System.ServiceModel.Configuration.ServicesSection, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </sectionGroup>

    <system.serviceModel>

      <machineSettings enableLoggingKnownPii="true"/>

    </system.serviceModel>

     

    Friday, January 19, 2007 2:08 AM
  •  

    Thanks Jan for the correction.

    I had tried that out - among other things - but got errors everytime.

    To be specific for anyone else reading this the insert has to go after the </configSections - makes sense to me now.

    It will produce an error in the config file (if reading it in Visual Studio) as will the  logKnownPii="true" in the App.config or Web.config.  The intellisense will say attribute not declared.  You will not know until you run the application that it is OK.

     

    Friday, January 19, 2007 8:44 AM
  • If you are getting this:

     

    Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.ServiceModel.DiagnosticUtility' threw an exception. ---> System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.ServiceModel. (C:\Windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config line 157)
       at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal)
       at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors)
       at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
       at System.Configuration.ClientConfigurationSystem.EnsureInit(String configKey)

     

    it may be because you tried to rely on the MSDN documentation here:

    Security Concerns for Message Logging

    http://msdn2.microsoft.com/en-us/library/ms730318.aspx

     

    The sample code has the wrong case for the <system.serviceModel> element.  It should be "serviceModel", not "ServiceModel".

     

    Here is the correct version:

     

    <system.serviceModel>

      <machineSettings enableLoggingKnownPii="true"/>

    </system.serviceModel>

    Saturday, June 23, 2007 7:23 PM