Share via


Handling of authentication for LOB Activities

The LOB Activities need to authenticate with the LOB before they can perform any operations. The Send activity in Windows Workflow Foundation 4.0, which is how a workflow can invoke a WCF service operation, presently does not support authentication. Since the LOB activities are built on top of Send activity, they also have this limitation. Below are a few options that can be used to authenticate with the LOB. The WCF Oracle Apps adapter is covered separately in a different blog. This blog addresses the other adapters, i.e. WCF SQL, WCF SAP, WCF Oracle DB and WCF Siebel.

Using Windows credentials

If the WCF LOB Adapter supports windows integrated authentication, that mechanism can be used and the windows credentials of the logged in account will be used to authenticate. This can be used for WCF SQL and WCF OracleDB adapters.

 
Using mapped credentials

If the WCF LOB Adapter supports a mechanism to map windows credentials to LOB credentials, that approach can be used. This can be used for WCF SAP adapter that supports Secure Network Communications.

Using custom endpoint behavior

A custom endpoint behavior can be written up which will pull the credentials from a secure store and then populate the ClientCredentials behavior with that information. This is a flexible approach that can be used with SQL, Oracle DB, SAP and Siebel adapters. The below set of steps explain how to go about it.

         class MyEndpointBehavior : BehaviorExtensionElement, IEndpointBehavior
    {
        public override Type BehaviorType
        {
        get { return typeof(MyEndpointBehavior); }
}

        protected override object CreateBehavior()
        {
            return new MyEndpointBehavior();
}

        public void
            AddBindingParameters(
                ServiceEndpoint endpoint,
                BindingParameterCollection bindingParameters
            )
        {
        }

        public void
            ApplyClientBehavior(
                ServiceEndpoint endpoint,
                ClientRuntime clientRuntime
            )
        {
            ClientCredentials clientCredentials = endpoint.Behaviors.Find<ClientCredentials>();
            Debug.Assert(clientCredentials != null, "ClientCredentials behavior not present");

            // TODO: Add your code to retrieve the credentials from a secure
            // store. For illustration purpose, the values are hard-coded
            clientCredentials.UserName.UserName = "Foo";
            clientCredentials.UserName.Password = "Bar";
        }

        public void
            ApplyDispatchBehavior(
                ServiceEndpoint endpoint,
                EndpointDispatcher endpointDispatcher
            )
        {
        }

        public void Validate(ServiceEndpoint endpoint)
        {
        }
    }

Make changes to the configuration file to add this endpoint behavior to the endpoints used by the relevant LOB Activities. Note the “type” in behavior extension should be set to typeof(MyEndpointBehavior).AssemblyQualifiedName.

<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="lobActivityBehavior">
          <lobActivityEndpointBehavior />
<myCredentialsBehavior />
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<sqlBinding>
<binding name="SqlAdapterBinding" … />
      </sqlBinding>
</bindings>
<client>
<endpoint address="mssql://localhost//mytestdb?" … />
    </client>
<extensions>
<behaviorExtensions>
<add name="myCredentialsBehavior"
             type="WorkflowConsoleApplication3.MyEndpointBehavior, WorkflowConsoleApplication3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
      </behaviorExtensions>
</extensions>
</system.serviceModel>

Passing the authentication information as part of the URI

The SQL, Oracle DB, SAP and Siebel adapters, all support passing of username/password in the URI. The binding property “AcceptCredentialsInUri” needs to be set to true to enable this support. Note that this poses a security risk since the credentials are now stored in clear text in the config file. You need to ACL that file properly.

Sandeep Prabhu,
BizTalk Server Team