Legacy Nintex K2 for SharePoint Architecture

From Nintex K2 Cloud Update 21 onwards there are two different apps for SharePoint Online. The legacy Nintex K2 Cloud for SharePoint app: used for SharePoint upgraded tenants, and the Nintex K2 Cloud (SPFx) app: used for new tenants.
This topic describes the legacy K2 for SharePoint app. For more information and differences between the legacy K2 for SharePoint app and the SharePoint Online (SPFx) app, see SharePoint Online (SPFx) app overview.

K2 for SharePoint is an app that runs in the Provider-Hosted App model. This means that all artifacts execute on the server and the product only integrates with SharePoint through APIs that SharePoint exposes. As a result, there is a very minimal footprint of product-installed items on the SharePoint servers, and the majority of all execution happens on the product environment. Most of the user interface elements that appear in SharePoint are actually iFrames that point back to the product environment.

The product uses SmartObjects to integrate back to the SharePoint site, and uses the same technology to expose other systems, like SQL and AD, as SmartObjects. In turn, external applications can use SmartObjects to interact with SharePoint through the product.

The product makes use of Remote Event Receivers (RERs) to listen for events that occur on the SharePoint environment. For example, if you were to configure a workflow to start when an item is added to a SharePoint List, the product registers a Remote Event Receiver for that list when the workflow is deployed. When an item is added to the list, the RER instructs the product to start the workflow.

For examples of environment topologies when using K2 for SharePoint, see SharePoint 2013, SharePoint 2016 and SharePoint Online.

The diagram below conceptually illustrates the integration between the product and SharePoint. Notice that the K2 for SharePoint app resides in the App Catalog, from where it is deployed to a SharePoint Site Collection. This creates some artifacts on the targeted SharePoint Site Collection, but all execution and operation occurs in the connected product environment. The product in turn, uses SmartObjects to interact with SharePoint items such as lists, libraries, sites and groups.

Conceptual Diagram: SharePoint and K2 for SharePoint integration

Microsoft Azure Active Directory is now Microsoft Entra ID

Authentication

The authentication from K2 to SharePoint uses Claims-Based Authentication (CBA) and OAuth. OAuth is configured when you register the app in a SharePoint site. Under the covers, the product and SharePoint would usually use the same authentication mechanism and therefore user credentials are seamlessly passed from one system to the other. Since CBA is used, Kerberos and Pass-Through Authentication are no longer required as was the case with many SharePoint 2010 and earlier environments.

The product is a relying party (along with SharePoint, online or on-premises) that trusts SAML2.0 Claims tokens that were issued by a trusted claims issuer (also known as a Secure Token Service or STS), such as Access Control Service for Azure Active Directory or Active Directory Federation Service (ADFS) for Active Directory, and those Claims Tokens were retrieved from a Claims Provider (also known as an Identity Provider), which is most often Azure Active Directory or Active Directory.