I assume you are referring to the client API connection objects.

In a nutshell, it basically it acts as a communication proxy to the K2 server. It talks over TCP sockets which means it uses point to point connections.

A couple of notes here:

1. 
   
2. Traffic is compressed and hashed before it is sent from client to server.
   
3. Authentication is done via windows authentication and impersonation is used.  So in distributed environments, you can utilize kerberos delegation as per the Microsoft security infrastructure.  Authorization is handled by the K2 server side.
   
4. The client side connection object does not handle connection pooling.  However, you can implement your own connection pooling class if needed (There is a sample pattern in the K2 best practices guide http://help.k2.com/en/KB000352.aspx).  On the K2 server side, it has a configurable pool of worker threads (default is 20).  So if all threads are occupied, an incoming connection will normally wait until a thread is free (or the connection times out).  In most cases, the default setting is sufficient as long as your application is well-built and closes the connections as soon as it is done with it.
   

So far the above is based on my own understanding of it.  It might not be 100% right but I assume one of guys will correct me if there is anything incorrect here. :)

Many thanks for your answer i'll keep it open and not verify the answer in order to gat as much commencts on this question as possible

Mr Jonny

can you give more clarification on point 1. since the customer needs to know about the comression and hashing mecanism in k2 for security purposes.

Sorry, it's proprietary and confidential for obvious security reasons.

Is there anything specific the customer is concerned with or are they just asking for purely academic reasons?

In the design phase of our application we need to make sure that the communications with k2 server are highly available and secure. we need to make sure any listener to the communications will not be able to "Extract" data.

Applying the IPSEC is a really heavy cost on the performance.

To recap, i want info about the security of communications between K2 client and K2 server from an architectural point of view.

BasharA,

You said

To recap, i want info about the security of communications between K2 client and K2 server from an architectural point of view.

Can you elaborate on what you are looking for more specifically and I will try to get you somehting?

Thanks

As far as I know, I have not heard of anybody "extracting" data from the K2 communications to the K2 server.  However, that is not too say a talented hacker would not be able to do so.

If security is a big concern, I would say that implementing an additional security layer might still be valid.  IPSEC is just one mechanism, there are other ways to achieve a similar effect.  You could:

1. 
   
2. Isolate the K2 server traffic onto a seperate VLAN.  This prevents public users accessing your application from sniffing backend traffic.
   
3. Use hardware encryption solutions.  This helps to avoid the performance penalty as the encryption is handled in hardware.  If you do a search on google, you probably can find many third party solutions that do this.
   

So overall, I would say it is a tradeoff between security, performance and costs.

Note that this isn't something that just applies to K2.  This applies equally to other server products.  e.g. BizTalk, SQL server, Dynamics, etc.