Share via

How To Configure an Operation Service with Federated Bindings

  • Article

This topic contains information to help you setup a secure communication path between a Commerce Foundation operation service used for the routing service on the presentation tier and the SharePoint security token service (STS) using federated bindings.

This topic contains the following sections:

  • Retrieving the SharePoint STS Thumbprints from the Presentation Tier

  • Configuring Federated Bindings on the Operation Service Endpoint

  • Performance Considerations When Using Throttling with Federated Bindings

Prerequisites

  • Procedures in this topic assume that certificates were previously issued to the SharePoint STS. If you are setting up a production environment, the use of certificates signed by a Certificate Authority is assumed.

  • This procedure assumes that you have created a new Commerce Foundation operation service in IIS to be used by the routing service. For more information see How to Create a Commerce Foundation Operation Service.

  • You know the path to the security token service in your Microsoft SharePoint 2010 deployment.

  • Make sure to have the sample configuration file named web.federated.config which is part of the pre-packaged sample. This file already contains the federated bindings and transport security configuration specified below. By using the file as a starting point, you only need to make the necessary modifications, rename the file (to web.config) and make sure to include it in the virtual folder of the appropriate Commerce Foundation operation service to be used for the routing service.

Retrieving the SharePoint STS Thumbprints from the Presentation Tier

The use of transport security between the Commerce Foundation operation service and the STS implies establishing certificate trust between those services. You establish this trust by retrieving SharePoint STS certificate thumbprints from the presentation tier to subsequently add them in the Commerce Foundation operation service configuration on the application tier.

  1. To retrieve the certificates issued to the SharePoint STS on the presentation tier server, open a Management Console (MMC) snap-in for certificates. For detailed instructions, see https://go.microsoft.com/fwlink/?LinkId=204604.

  2. Expand Certificates, and then expand SharePoint.

  3. Under SharePoint, open the Certificates folder and retrieve the certificates thumbprints issued to the following services

    • SharePoint Security Token Service

    • SharePoint Security Token Service Encryption

    For detailed instructions, see https://go.microsoft.com/fwlink/?LinkId=204606.

    Hh597522.alert_caution(en-us,CS.95).gifImportant Note:

    When you select the certificate thumbprint to copy it onto the clipboard, make sure not to include the leading empty space that precedes the first digit of the thumbprint.

  4. When the thumbprints are available on the clipboard, you are ready to proceed with the following procedure for configuring the operation service endpoints on the application tier.

Configuring Federated Binding on the Operation Service Endpoint

On the application tier, configure the path to the STS to use federated bindings with transport security. The following configuration example is taken from the prepackaged sample web.federated.config, which you can use as a starting point.

  1. Make sure the Web.config file contains the following configuration section. This is required to interact with the Windows Identity Foundation.

    <configSections>
    <section name="microsoft.identityModel" type="Microsoft.IdentityModel.Configuration.MicrosoftIdentityModelSection, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=<KeyValue>" />
...
</configSections>

  2. Make sure the <bindings> section contains the following ws2007FederationHttpBinding configuration. This is the binding configuration required to establish a connection between the Commerce Foundation and the SharePoint STS. The secure URL of the SharePoint STS that is being used for authentication by the commerce application must be added to the issuer and issuer metadata fields in the federated binding configuration for the Commerce Foundation service. The following is an example of this configuration for an environment where the SharePoint STS server address (in the presentation tier) is https://mySTS.mycompany.com. The example assumes the https port binding for the STS is 32844. The example also contains an <identity> section where the identity of the service called by the client endpoint is configured to use a Domain Name Service (DNS). For information about WCF service identity and authentication, see https://go.microsoft.com/fwlink/?LinkId=204651.

    <system.serviceModel>
    <bindings>
             <ws2007FederationHttpBinding>
        <binding name="ws2007FederationHttpBinding_IOperationService">
          <security mode="TransportWithMessageCredential">
            <message issuedTokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1" negotiateServiceCredential="true" issuedKeyType="SymmetricKey">
              <issuerMetadata address="https://mySTS.mycompany.com:32844/SecurityTokenServiceApplication/securitytoken.svc?wsdl" />
              <issuer address="https://mySTS.mycompany.com:32844/SecurityTokenServiceApplication/securitytoken.svc/actas" binding="ws2007HttpBinding" bindingConfiguration="ws2007HttpBinding_IWSTrust13SyncContract" />
            </message>
          </security>
        </binding>
      </ws2007FederationHttpBinding>

   </bindings>
  <services>
    <service behaviorConfiguration="OperationServiceClaimsAwareBehavior"
    name="Microsoft.Commerce.Server.OperationService">
      <endpoint address="" binding="ws2007FederationHttpBinding"
      bindingConfiguration="ws2007FederationHttpBinding_IOperationService"
      contract="Microsoft.Commerce.IOperationService">
        <identity>
          <dns value="machineName" />
        </identity>
      </endpoint>
     </service>
  </services>
…<system.serviceModel>

  3. Make sure that the service behavior and behavior extensions are configured to be claims-aware. Following is an example.

        <behaviors>
      <serviceBehaviors>
        <behavior name="OperationServiceClaimsAwareBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
          <federatedServiceHostConfiguration />
        </behavior>
      </serviceBehaviors>
    </behaviors>
<!--The behavior defined above needs the following extensions-->
    <extensions>
      <behaviorExtensions>
        <!--This behavior extension will enable the service host to be Claims aware-->
        <add name="federatedServiceHostConfiguration" type="Microsoft.IdentityModel.Configuration.ConfigureServiceHostBehaviorExtensionElement, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="errorHandlingBehavior" type="Microsoft.Commerce.Server.OperationErrorHandler, Microsoft.Commerce.Server, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
        <add name="commerceWebClientFaultBehavior" type="Microsoft.Commerce.CommerceWebClientFaultBehavior, Microsoft.Commerce, Version=9.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      </behaviorExtensions>
    </extensions>
</system.serviceModel>

  4. The issuer name registry must be updated in the federated Commerce Foundation service web.config with the thumbprints from the certificates from the SharePoint STS Service and STS Encryption Service. Add the two STS thumbprints previously retrieved from the presentation tier (in Retrieving the SharePoint STS Thumbprints) to the <trustedIssuers> section of the web.config file for the federated Commerce Foundation service.

    <microsoft.identityModel>
    <service>
      <audienceUris>
        <add value="urn:schemas-microsoft-com:sharepoint:service" />
      </audienceUris>
      <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=<KeyValue>">
        <trustedIssuers>
          <add thumbprint="83474d0236f7c0f3d4f6841f6f52a246e1bff21e" name="SharePoint Security Token Service Encryption" />
          <add thumbprint="39e4247a240b9a944e5dffb7fa4d8558f33a7a15" name="SharePoint Security Token Service" />
        </trustedIssuers>
      </issuerNameRegistry>
   <certificateValidation certificateValidationMode="None"/>
    </service>
  </microsoft.identityModel>

Performance Considerations When Using Throttling with Federated Bindings

In a three-tier deployment, the routing service impersonates (acts as) the identity of the user, thus delegating the ClaimsIdentity of the user that initiated the request. In doing so, the routing service communicates with the security token service using ws2007Federated bindings. This scenario applies, for example, when a business user uses a RIA, such as the Silverlight-based Commerce Server Business Administration Ribbon, to request product properties.

When the routing service forwards a message on behalf of a user, the WCF channel must be created for each message sent to the Commerce Foundation; this is necessary in order to have the correct security context associated with each request. As a result, proxy caching must be disabled for the connection from the routing service to the federated operation service.

In scenarios where the routing service must handle a large volume of requests, make use of WCF throttling parameters, such as maxConcurrentCalls, maxConcurrentSessions and maxConcurrentInstances, in the federated operation service configuration to tune WCF messaging performance. For detailed information about how to configure these parameters with an operation service which uses ws2007Federated binding, at https://go.microsoft.com/fwlink/?LinkId=213933

See Also

Other Resources

Configuring a SharePoint Routing Service in a Three-Tier Deployment