Establishing a Connection with the K2 Server
A client connection can be made with the K2 Server from many different sources, these include both K2 and non K2 Clients. Some examples of client connection sources are:
- K2 Workspace
- ASP.NET Forms
- InfoPath
- SharePoint
- Custom thick or thin client
When the client connection is attempted, it may be a direct connection or the connection may have been delegated via another machine.
Kerberos Vs K2 Pass-Through
If Kerberos has not been configured, the possibility will always be present that the client credentials will be lost as they are delegated through the application layers especially when the number of physical machines in question increases. The primary reason for this is that the various application layers do not have valid credentials from Active Directory. The most obvious evidence of this is when an Anonymous User Error is generated when a client application on one machine has attempted a connection with an adjacent machine and the connection was refused.
Since the credentials would normally only be lost on the second hop (ie second machine to machine delegation, K2 Pass-Through can be requested)
Connection Pass Through
As described above, the credentials would normally loose context on the second hop i.e. the ISS Server attempts to place a call to the K2 Server, but the logon comes through as anonymous and no valid windows token can be passed.
K2 Pass-Through is only available on the second hop and this is when the K2 Client APIs contact the K2 Server. When this takes place, there is one of two possible outcomes:
- When the connection is made VIA the APIs, they gather valid information relevant to the user. If these credentials are the same as the user on the K2 Server, then the APIs will pass credentials in the same manner as Kerberos or NTLM enabling a logon to take place successfully.
- If however, the information that has been gathered about the user is not the same and this could be owing to an Anonymous error or a Service of some kind this means that delegation has failed. For this scenario, the details of the original user are passed to the K2 Server and they are used instead.
Double Hop
A hop, refers to when credentials are passed from one machine to the next. In most cases the first hop takes place between the Client and service or server of some kind.
In the diagram below this is a single hop, but this only applies to non-distributed installations where passing of credentials is not a problem. In the diagram below NTLM is used and this enabled the credentials to be authenticated
In the second diagram, the credentials are passed twice, from client to the IIS Server and then onto the K2 Server. This is a double hop, and is typical of a scenario where K2 Pass-Through Authentication is useful.
In the first step, NTLM is again used to authenticate between the client and the ISS Server. This could be the K2 Workspace Machine for example. However, when the IIS Server needs to place a request to the K2 Server, this now crosses the physical machine boundary, and the ISS Service does not have the authority to pass these credentials. This would typically result in an Authentication Anonymous error that Kerberos would negotiate. It is also the scenario for which K2 Pass-Through is useful.
Triple Hop
Caution: A virtual machine is still considered as a physical machine since it introduces the logical machine boundary barrier.
The triple hop limitation comes into effect when there are too many machines located either before or after the K2 Server in the sequence of credential passing. If the K2 Server is the third machine in line or web service, SQL Database is the third machine away from the K2 Server this will cause a delegation failure and credentials will not be passed. Also, this is now beyond the scope of K2 Pass-Through Authentication and the need now arises for Kerberos to be installed.
In the above scenario, the hop between the custom Web service and the K2 Server now means that the context of the User has been completely lost and in this instance K2 Pass-Through Authentication cannot be used. This is because the identity of the User and their credentials were lost long before they reached the K2 Server and the K2 Server cannot recover them in this scenario.
The situation below presents a similar situation, where the K2 Server is first in line but now too far away. Credentials can be passed to the Custom Web Service successfully using NTLM, however once the Custom Web Service needs to pass those same credentials onto a 3 part system, for example SQL Server a delegation error takes place.
K2 Pass-Through Authentication will only and always come into effect in relation to the K2 Server and K2 components. The 3 hop limitation is not a limitation of K2 Pass-Through Authentication, but is rather a extent to which K2 Pass-Through can be leveraged to ensure that credentials are passed from machine to machine. Once the 3 hop limitation has been reached, then the requirement is that Kerberos must be configured.
