K2 Pass-Through Authentication (K2PTA) offers a number of methods for delegating or securely storing a set of user credentials and then delegating them. These options enable K2PTA to be as intuitive as possible yet there may be additional setup and configuration required along with prerequisites and potential limitations.
K2 Delegation Overview
The K2 workflow server, which is a hosted service along with the other services such as the SmartObject server, may at times be required to pass credentials to a line of business (LOB) system. The K2 workflow server, does not independently perform delegation of the credentials, but relies on the K2 platform (the Host Server pictured below, aka the K2 server) to perform the delegation.
When K2PTA is necessary for the credentials to be delegated, only the K2 Server has the information about the user. Furthermore, this identity is only recognized by the K2 server and not by any LOB. This prevents the K2 server from passing any credentials to SharePoint, for example, and in that case the identity of the K2 service account is used as if there is no pass-through. If Kerberos were configured, the credentials would be passed through the chain all the way to SharePoint.
The options that are available for Delegation are as follow:
Single Sign-OnSingle Sign-On is a feature that has been primarily used in conjunction with LOB systems where a secondary set of credentials are cached against a security label for that LOB. This allows K2 to authenticate a client user for LOB systems that have their own login, for example SAP and SalesForce.
Single Sign-On only comes into play with K2PTA if K2PTA is called first. What this means is that if the K2 server does not receive a K2PTA call, or does not determine that a K2PTA requirement exists, then SSO would not be used.
Single Sign-On works in conjunction with K2PTA so that Active Directory credentials can also be cached in a similar way. This enables the system to check for cached credentials when calling an external system for the current user. All Active Directory passwords are stored securely within the K2 database using K2 symmetric key to ensure security.
Once credentials have been cached and they are available, K2 can login and impersonate the user when calling the LOB system. This method is equivalent to using Kerberos.
The image below illustrates a number of steps that K2 server follows when utilizing SSO with K2PTA:
Enforce ImpersonationIn scenarios where SharePoint Impersonation or Dynamic SQL Service Impersonation are being used, if the Enforce Impersonation flag on the service instance setup page is set to True the native impersonation functionality of the SharePoint Server and the SQL Server, respectively, will reject the connection attempt. See the relevant section for further information.
Enforce Impersonation: This is a K2PTA option. If Enforce Impersonation is NOT checked, and K2PTA fails for the impersonated user, the service reverts to the identity of the K2 service account and retries the connection. When Enforce Impersonation IS checked, the service does NOT revert to the K2 service account if the connection fails with the impersonated user.
If K2PTA is called by a service instance and there are no cached credentials for Single Sign-On to be used, then there would be no user credentials available. In certain instances, it would be acceptable that the identity of the K2 service account be used to impersonate the K2PTA user. There are scenarios where setting this flag to true to enforce the impersonation would be unacceptable, for example for auditing purposes, where the user credentials should be used to record user access.
By default the Enforce Impersonation flag is set to FALSE (unchecked).
If Kerberos were configured and functioning or K2PTA had taken place, this setting would be redundant as the K2 Server would be executing as the user and there is no reason to prevent the connection.
Dynamic SQL Server ServiceObject ImpersonationSQL Server includes native impersonation capabilities which can be leveraged when Kerberos has not been configured and credentials need to be passed between machines to authenticate the K2 user.
Service Instance Configuration
From within K2 Workspace, the service instance is configured and the Enforce Impersonation flag for the SQL service is set to false. If the impersonation flag is set to true, the authentication attempt is blocked by SQL and results in an anonymous user error and authentication fails. The event is logged by K2.
How it Works
K2PTA uses the K2 Dynamic SQL Server Service to impersonate the pass-through user. This allows the K2 server (via the service instance) to impersonate the user to access secure data sources without creating a security risk. This is in spite of only having the K2 service account where no Kerberos has been configured and SSO credentials are not available.
The Dynamic SQL Server Service is able to pass the credentials of the pass-through user by using SQL Server’s User Impersonation capability. SQL Server has an EXECUTE AS LOGON connection string property which K2 uses in this case, and is specific to SQL Server but must be setup and configured using the steps below.
Setup Requirements
The following configuration prerequisites are required:
- The K2 server must run under the account: [Domain Name]\K2Service account.
- Within Active Directory there is an user group called ‘Domain\SqlUsers’ which must contain the names of the users who want access to the specific databases.
- Active Directory user ‘Domain\SqlUser1’ which makes the delegated call.
SQL Server Instance Configuration
These scripts need to be run once per SQL Server instance.
Map Login
For each SQL Server Instance, the following mappings need to be created:
- The SqlServer LOGIN needs to be mapped to [Domain\SqlUsers].
- The LOGIN needs to be mapped to the K2 server service account.
The above configuration enables the SQL Server to resolve the AD group or user by associating the Windows SID to a SQL SID.
Both AD Groups and AD Users can be added that you can set up a whole AD Group as a LOGIN, it needn’t just be an AD User.
--Associate Windows SID to SQL SID
USE [master];
--Represent caller SID within SQL
CREATE LOGIN [Domain\SqlUsers] FROM WINDOWS;
--Represent service account SID within SQL
CREATE LOGIN [Domain\K2Service] FROM WINDOWS;
GO
Grant Impersonation Rights
The Grant IMPERSONATION rights on the K2 server service account script enables the following actions:
- This allows the service account to impersonate as the specific LOGIN.
- This is unnecessary if the service account LOGIN has high enough privileges (e.g. sysadmin).
USE [master];
--Allow one SID to impersonate as the other
GRANT IMPERSONATE ON LOGIN::[Domain\SqlUsers] TO [Domain\K2Service];
GO
Map Server Login to the Local Database Principle
The Impersonation rights granted above must be mapped to a database user:
- In the specific database (e.g. SalesDB), make sure the LOGIN above is mapped to a database USER.
- Since LOGINs operate at the SQL Server level, you need a USER principle in each database that is tied to the LOGIN.
- Either use an existing USER (such as dbo) or create a brand new database USER as per below.
USE [SalesDB];
--Map server LOGIN to a local database principle, in this case using
--the same name for convenience (can also use a different USER name)
CREATE USER [Domain\SqlUsers] FOR LOGIN [Domain\SqlUsers];
GO
Grant User Rights
Running this script would not normally be required, but if it is required then only once per SQL Server Instance.
- Ensure that the USER specified above has rights to execute / read / write / delete all appropriate objects
- If the LOGIN was mapped to dbo or assigned dbowner (or similar) permissions to the USER then nothing further is required.
- If not, then the following script must be run for the specific database.
USE [SalesDB];
GRANT EXECUTE ON [dbo].[MyProcOrTable] TO [Domain\SqlUsers];
GO