I am converting an ASP.Net site from Windows Authentication to OWIN / Cookie / Claims based authentication.
We are using K2 5.2 version of the SourceCode.Workflow.Client (and all the other) dlls to make a connection to K2.
I am making the connection using a connection string *with a user name / password* - i.e. I am NOT trying to do a kerberos style connection to K2.
I have my app all set with all of the OWIN dlls, and a "startup" function, and fully anonymous authentication and my call to:
var connection = new Connection();
connection.Open(Config.K2.ServerName, Config.K2.K2AdminConnectionString);
...works fine.
As soon as I add the code to actually authenticate (with a 3rd party provider), my HttpContext.Current.User changes from a WindowsPrincipal to a ClaimsPrincipal, and at this point, the connection to K2 fails with the error:
Value cannot be null. Parameter name: BootstrapContext
Stack Trace:
at SourceCode.Workflow.Client.InternalConnection.Call(ArchiveX ar, MessageType msgtype)
at SourceCode.Workflow.Client.InternalConnection.AuthenticateIIdentity()
at SourceCode.Workflow.Client.Connection.Open(String Server)
Doing a bit of detective work with .Net Reflector, I see that it's putting Thread.CurrentPrincipal.Identity into an "ArchiveX" object, and then doing something with it, and it seems like this is where it's breaking down.
This all seems odd to me, since I'm sending all of the credentials for the connection in with the connection string, so the thread user shouldn't matter.
Will I need to wrap all of my calls to the API in a windows principal (with the old kernal32.dll impersonation context trick) to get my API calls to work?