When you build the solution, ePortal Developer modifies the Web.config file. This file specifies the service, endpoints, bindings and behaviors of the WCF service. You can view or edit this xml file by using the

You can generate the Web.config file only when no Web.config file already exists.

You can use the Web.config file to configure parameters which limit your throughput.  These parameters default to small values to reduce the likelihood of a “denial of service” type attack.  However, in some cases the default values may be too small for your needs.  Some key parameters include:

Search Microsoft documentation at http://msdn.microsoft.com for more information on these parameters.

Service

The generated Web.config file specifies the following service element, which contains two endpoints and references a behavior named ServiceBehavior:

<service behaviorConfiguration="ServiceBehavior" name="WcfServiceLibrary1.Service">

Endpoints

The generated Web.config file specifies the following endpoint for metadata exchange:

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

For a service that does not require a session, the generated Web.config file specifies the following endpoint:

<endpoint name="ServiceBinding" contract="WcfServiceLibrary1.IService" binding="basicHttpBinding" bindingConfiguration="SessionlessBinding" />

In this endpoint the binding named SessionlessBinding indicates that the endpoint uses a basicHttpBinding.

For a service that requires a session, the generated Web.config file specifies the following endpoint:

<endpoint name="ServiceBinding" contract="WcfServiceLibrary1.IService" binding="wsHttpBinding" bindingConfiguration="TestBinding" />

In this endpoint the binding named TestBinding indicates that the endpoint uses a wsHttpBinding.

Bindings

The generated Web.config file specifies three bindings.

For a Service That Does Not Require a Session

For this service, the generated Web.config file specifies the following binding, which uses a basicHttpBinding and is called SessionlessBinding.

<basicHttpBinding>
     <binding name="SessionlessBinding">
        <security mode="None"/>
     </binding>
 </basicHttpBinding>

You can use this binding to test the service locally and to test the service Web site deployed to ePortal.

For a Service That Requires a Session

For this service, the generated Web.config file specifies the following two bindings, which use a wsHttpBinding and are called TestBinding and ReleaseBinding:

<wsHttpBinding>
   <binding name="TestBinding">
     <security mode="Message"/>
   </binding>
   <binding name="ReleaseBinding">
     <security mode="TransportWithMessageCredential">
       <transport clientCredentialType="None" />
       <message clientCredentialType="UserName" />
     </security>
   </binding>
 </wsHttpBinding>

You can use the first binding, TestBinding, to test the service locally. This binding uses Message security, with the clientCredentialType property Windows. This security enables you to test the service without using another authentication, such as X.509 certificates.

You can use the second binding, ReleaseBinding, to test the service Web site deployed to ePortal.

ReleaseBinding uses TransportWithMessageCredential security. This security requires the server to have an X.509 certificate because an application must use HTTPS to access the service.

For ReleaseBinding, the message-level clientCredentialType property is UserName, which requires the service to implement a UserName validator. The default validator is provided in the App_Code directory. This validator accepts all usernames and passwords, but you can edit the validator.

Behavior

The generated Web.config file specifies the following service behavior, ServiceBehavior:

<serviceBehaviors>
   <behavior name="ServiceBehavior">
     <serviceMetadata httpGetEnabled="true" />
     <serviceDebug includeExceptionDetailInFaults="false" />
     <serviceCredentials>
       <userNameAuthentication userNamePasswordValidationMode="Custom"
              includeWindowsGroups="false"
           customUserNamePasswordValidatorType=
                    "CustomUserNameValidator.CustomUserNameValidator,App_Code" />
     </serviceCredentials>
   </behavior>
 </serviceBehaviors>

This behavior enables clients to access the metadata by using the HTTP Get request. The behavior specifies the name and location of the custom username-password validator.

Starting with .NET 4, a RESTful web service can have an automatically generated help page. To access the help page, open a browser and enter the URL for the Service.svc, appended with /Help. For a RESTful web service, the Web.config file for .NET 4 includes the following behavior to configure the help page:

<endpointBehaviors>
   <behavior name="RestBehavior">
     <webHttp helpEnabled="true" />
   </behavior>
 </endpointBehaviors>

If you wish to disable the help page, simply remove helpEnabled="true" from the endpointBehaviors. For more information, search for the term "helpEnabled" in the MSDN online documentation.

Security

In the Web.config file, you can add or modify the parameters for the HTTP Content-Security-Policy and Access-Control-Allow-Origin response headers to enhance security. Additionally, you can enable the Secure and HttpOnly flags of the Set-Cookies HTTP response header to enhance the security of the cookies.

This topic describes the following sub topics:

HTTP Response Headers

When you create an ePortal Presentation project, the HTTP Content-Security-Policy (CSP) and Access-Control-Allow-Origin response headers are available with default settings under the <system.webServer> element in the Web.config file. The HTTP CSP response header provides an additional layer of security that detects and reduces the web attacks. You can modify the values for the HTTP CSP response header in the Web.config file according to your application requirements.

The Access-Control-Allow-Origin response header indicates if the response can be shared with the requesting code from a specific origin. You can provide the origin according to your application requirements. In the Web.config file, the browser allows code from any origin to access a resource by default.

For the existing presentation projects, you must add the following <system.webServer> element in the Web.config file. After adding the element, restage and redeploy the application.

<system.webServer>
   <httpProtocol>
      <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*"/>
         <add name="Content-Security-Policy" value="script-src 'self' 'unsafe-inline' 
         'unsafe-eval' "/>
      </customHeaders>
   </httpProtocol>
</system.webServer>

Secure Flag

By default, the cookies are sent using both HTTP and HTTPS requests. If the traffic is not encrypted using HTTPS connection, an attacker can switch to HTTP connection and access the same cookie.

When you enable the Secure flag in the Set-Cookies HTTP header, the server informs the browser that the cookies are allowed to transmit only using secure connection. By default, the Secure flag is disabled in the Set-Cookies http header. To enable the Secure flag for your application, uncomment the following lines in the Web.config file:

<!--<rewrite>
<outboundRules>
    <rule name="Use only secure cookies" preCondition="Unsecured cookie">
    <match serverVariable="RESPONSE_SET_COOKIE" pattern=".*" negate="false" />
    <action type="Rewrite" value="{R:0}; secure" />
    </rule>
    <preConditions>
      <preCondition name="Unsecured cookie">
      <add input="{RESPONSE_SET_COOKIE}" pattern="." />
      <add input="{RESPONSE_SET_COOKIE}" pattern="; secure" negate="true" />
    </preCondition>
    </preConditions>
</outboundRules>
</rewrite>-->

HttpOnly Flag

A cookie can be set and used over HTTP communication between a web server and a web browser. Cookies can also be accessed using JavaScript files loaded on a web browser page. This exposes the page to cross-site scripting (XSS) attack.

To restrict such attacks, enable the HttpOnly flag in the Set-Cookies HTTP header so that the cookies are sent only using HTTP or HTTPS connection and cannot be accessed using client side script. By default, the HttpOnly flag is disabled in the Web.config file. To enable the HttpOnly flag for your application, uncomment the following line in the Web.config file:

<!--<httpCookies httpOnlyCookies="true" requireSSL="true" />-->

X- Frame-Options Flag

You can use the X-Frame-Options HTTP response header to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>.

Web sites can use this flag to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites. By default, this is not added as a part of ePortal Runtime for the application deployed on ePortal Web Cluster.

To configure IIS to send the X-Frame-Options header, add this to your application's Web.config file followed by the <system.webServer> element. You can provide the value according to your application requirements. After adding the element, restage and redeploy the application.

<system.webServer>

    ...
    <httpProtocol>
       <customHeaders>
         <add name="X-Frame-Options" value="SAMEORIGIN" />
       </customHeaders>
     </httpProtocol>

     ...
</system.webServer>