WCF DataPortal - SecurityNegotiationException

WCF DataPortal - SecurityNegotiationException

Old forum URL: forums.lhotka.net/forums/t/12152.aspx


SMILEMan posted on Friday, September 13, 2013

I'm getting a SecurityNegotiationException when I access the WCF DataPortal from a WPF application (currently only WPF applications needs access to this DataPortal).

All of my business objects reference Csla.Web.dll and the DLL is in the bin folder of the DataPortal as Rocky indicated in earlier discussions on this forum.

I am able to ?wsdl the service and get the xml displayed in the browser.   I have setup by config files like the Project Tracker as much as possible - see below.

Server is Windows Server 2008 R2 with IIS 7.5 with .NET Framework 4.5 loaded.

App.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
  </configSections>
  <appSettings>
    <add key="CslaAuthentication" value="Csla" />
    <add key="ServerName" value="Stiles-SMILE3"/>
    <add key="TestMode" value = "true"/>
    <add key="SuppressWhatsNew" value = "false" />
    <add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy, Csla"/>
    <add key="CslaDataPortalUrl" value="http://Stiles-SMILE3/DataPortalHostWCF/WcfPortal.svc"/>
    <add key="AppType" value="SmartClient"/>
  </appSettings>
  
  <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Caliburn.Micro" publicKeyToken="8e5891231f2ed21f" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.5.2.0" newVersion="1.5.2.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Web.config:

<?xml version="1.0"?>

<configuration>
  <appSettings>
    <add key="CslaAuthentication" value="Csla" />
    <add key="DalManagerType" value="SMILE4.DataAccess.SqlServer.DalManager,SMILE4.DataAccess.SqlServer" />
    <add key="CslaWriter" value="Csla.Serialization.Mobile.CslaBinaryWriter, Csla" />
    <add key="CslaReader" value="Csla.Serialization.Mobile.CslaBinaryReader, Csla" />
    <add key="AppType" value="DataPortal"/>
  </appSettings>

  <connectionStrings>
      <add name="Security"
                 connectionString="data source=Stiles-SMILE3;initial catalog=SMILESec;user=xxxx;password=xxxx;MultipleActiveResultSets=True"
                 providerName="System.Data.SqlClient" />
      <add name="TEST"
                 connectionString="data source=Stiles-SMILE3;initial catalog=TEST;user=xxxx;password=xxxx;MultipleActiveResultSets=True"
                 providerName="System.Data.SqlClient" />
      <add name="TRAIN"
                 connectionString="data source=Stiles-SMILE3;initial catalog=TRAIN;user=xxxx;password=xxxx;MultipleActiveResultSets=True"
                 providerName="System.Data.SqlClient" />
      <add name="STILES"
                 connectionString="data source=Stiles-SMILE3;initial catalog=STILES2;user=xxxx;password=xxxx;MultipleActiveResultSets=True"
                 providerName="System.Data.SqlClient" />
    </connectionStrings>

  <system.web>
    <!--
            Set compilation debug="true" to insert debugging
            symbols into the compiled page. Because this
            affects performance, set this value to true only
            during development.
        -->
    <compilation debug="false" targetFramework="4.5"/>
    <!--
            The <authentication> section enables configuration
            of the security authentication mode used by
            ASP.NET to identify an incoming user.
        -->
    <authentication mode="Windows"/>
    <!--
            The <customErrors> section enables configuration
            of what to do if/when an unhandled error occurs
            during the execution of a request. Specifically,
            it enables developers to configure html error pages
            to be displayed in place of a error stack trace.

        <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
            <error statusCode="403" redirect="NoAccess.htm" />
            <error statusCode="404" redirect="FileNotFound.htm" />
        </customErrors>
        -->
    <pages controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID"/>
  </system.web>
  <!--
        The system.webServer section is required for running ASP.NET AJAX under Internet
        Information Services 7.0.  It is not necessary for previous version of IIS.
    -->
  <system.serviceModel>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true"/>
    <services>
      <service name="Csla.Server.Hosts.WcfPortal" behaviorConfiguration="WcfPortalBehavior">
        <endpoint contract="Csla.Server.Hosts.IWcfPortal" binding="wsHttpBinding"
  />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
      <service behaviorConfiguration="WcfPortalBehavior" name="Csla.Server.Hosts.Mobile.WcfPortal">
        <endpoint address="" binding="basicHttpBinding" contract="Csla.Server.Hosts.Mobile.IWcfPortal" bindingConfiguration="basicHttpBinding_IWcfPortal">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <bindings>
      <basicHttpBinding>
        <binding name="basicHttpBinding_IWcfPortal" maxReceivedMessageSize="2147483647">
          <readerQuotas maxBytesPerRead="2147483647" maxArrayLength="2147483647" maxStringContentLength="2147483647" maxDepth="1024"/>
        </binding>
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="returnFaults">
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
        <behavior name="WcfPortalBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

JonnyBee replied on Sunday, September 15, 2013

Ïs the IIS configured to allow Anonymous access? 

If still a problem use Fiddler or a network trace tool (like Network Monitor) to capture the communication between client and server. Then analyze the communication.

SMILEMan replied on Monday, September 16, 2013

 

 

 

Anonymous Authentication is Enabled.

I'll have to download and learn to us Fiddler sometime if necessary - don't know if I will understand its output or not.

Just wish the configuring the DataPortal wasn't so problematic - seems every time the environment changes, setting up the DataPortal becomes an issue.   The last time I had the WCF portal working, I was using CSLA 4.0 and Windows 2008 (vs. CSLA 4.5 on Windows 2008 R2 now).

P.S. Production DataPortal is CSLA 3.0 using Remoting which is running just fine on the same server.   If it would be easier to set up CSLA 4.5 to use Remoting that would be fine with me as all my use is internal.

SMILEMan replied on Wednesday, September 18, 2013

Anonymous Authentication is Enabled as the only a authentication method.

Fiddler just logged the first call to the Dataportal (the Fetch for the BusinessIdentity).   The following are the inner exceptions from the SecurityNegotiationException (let me know if you would like to see the full message with call stacks):

first inner exception:

Message=Secure channel cannot be opened because security negotiation with the remote endpoint has failed. This may be due to absent or incorrectly specified EndpointIdentity in the EndpointAddress used to create the channel. Please verify the EndpointIdentity specified or implied by the EndpointAddress correctly identifies the remote endpoint.

 

second inner exception:

Message=The message with Action 'http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

 

PS: I spent 2 weeks on a cruise to Norway in June with 8 port stops - You have a very beautiful country!

 

Ray Klaassen

 

Copyright (c) Marimer LLC