You can configure K2 to expose the K2 Workflow REST API through an Azure AD application proxy, and this article explains how to implement this configuration.
The configuration enables access to an on-premise instance of the K2 Workflow REST API where all users are present in Active Directory (AD) and have also had their identities synced to Azure AD (AAD). This allows the AAD app proxy connector service to generate a Kerberos token for an Active Directory user, using a corresponding UPN from their AAD account. The AAD app proxy connector service generates Kerberos tickets and passes them to the K2 REST workflow API. The diagram below shows a high-level overview of the configuration:
The K2 REST API needs to accept Kerberos tickets from the AAD app proxy connector service. Use this section to change the configuration of the K2 REST API virtual directories to accept these. You must do this even if your K2 installation was set to use Kerberos during installation.
The Azure AD application proxy uses a connector service running on an internal server to establish an outbound connection to Azure, and inbound connections to the internal K2 REST broker. Follow these steps to install and configure the AAD app proxy connector.
You need a Kerberos configuration to allow the AAD app proxy to impersonate the logged-in user through to the K2 Workflow REST API web application. The connector service uses the AAD UPN to create a corresponding AD Kerberos ticket to pass to the K2 server. Follow these steps to create the required SPNs and configure delegation between the services.
You need an Azure enterprise app to be able to make authenticated external connections to the internal REST service. Use the following steps to configure an enterprise app to work with the new connector you created in the preceding steps.
You need the following information to request an access token from Azure to call the AAD app proxy URL: