Connecting to WCF from K2 custom service dll with username password

Hi There,

It is my recommendation to manage the calling account using windows integrated authentication to the service, rather than setting credentials at the service configuration layer.

- Set the service object to impersonate mode (therefore will always make the wcf call as the calling user account).

- In your service code you can then manage which user you want to use for the functionallity the WCF service needs. I.e leave the credintials of the calling user or in your code you can revert to the app pool account.

Something like

public static class WindowsPrincipalHelper
    {
        public static WindowsImpersonationContext RevertToServiceAccount()
        {
            //revert to the user context of the service account for this part
            return WindowsIdentity.Impersonate(IntPtr.Zero);
        }

        public static void RevertToImpersonatedUser(WindowsImpersonationContext _serviceAccountContext)
        {
            if (_serviceAccountContext != null)
            {
                _serviceAccountContext.Undo();
            }
        }

        public static void RunWithServiceAccount(CodeToRunElevated secureCode)
        {
            RunWithServiceAccountPrivileges(new WaitCallback(CodeToRunElevatedWrapper), secureCode);
        }

        internal static void RunWithServiceAccountPrivileges(WaitCallback secureCode, object param)
        {
            var _serviceAccountContext = RevertToServiceAccount();
            try
            {
                secureCode(param);
            }
            finally {
                RevertToImpersonatedUser(_serviceAccountContext);
            }
        }

        private static void CodeToRunElevatedWrapper(object codeDelegate)
        {
            // Runs the codeDelegate (which is the elevated code) so that both the wrapper
            // and the codeDelegate will be executed after the usercontext has changed.
            ((CodeToRunElevated)codeDelegate)();
        }
    }

    /// <summary>
    /// Delegate for raised/lowered methods
    /// </summary>
    public delegate void CodeToRunElevated();
    public delegate void WaitCallback(object codeDelegate);

We have resolved the task as follows from your suggestions:
 
1. Modify the custom service dll to use "CredentialCache.DefaultNetworkCredentials;"
    instead of "System.Net.NetworkCredential(ClientUserName, ClientPassword, ClientDomain);"

2. Register the custom service dll instance using smartobject tester with the following setting:
    Authentication Mode: ServiceAccount (Default was Impersonate)

3.  The K2 service account, that runs the K2 blackpearl Server Service, is granted access to calls inside the WCF Service.

4. The custom service dll instance called from K2 blackpearl Server Service connects to the external wcf service using the K2 service account

    credentials with success....thus eliminating the need for hardcoding of username/password or exposing it.

ps.  I have yet to try and set Authentication Mode to SSO/Static option...which allows us to set a username and password in non clear text...which is an alternative to using the K2 service account.