Identity Providers Architecture

Essentially, there are two 'flows' that enable Identity Providers in K2 Cloud: a SCIM-based flow that allows you to pass user identities from an Identity Provider (IdP) to the product, and an OAuth-based OpenID flow that allows the product to authenticate users against an Identity Provider. The diagram below illustrates the basic architecture of these flows. In the diagram, notice two different colors: the orange flow represents the SCIM flow where the Identity Provider sends user information to the product, and the blue flow represents the authentication flow when users are authenticated against the Identity Provider when they log into the product.

Identity Providers in K2 Cloud: basic architecture

In this example scenario, there are two sample Identity Providers (IdP): Azure Active Directory (AAD) and Google. Each provider contains a K2 for SCIM App that allows the provider to pass user information to the K2 SCIM v2 REST API. Behind the scenes, a microservice supports the API and pushes user information to a staging database. From there, user information is passed to the environment's database. This 'path' ensures that the product knows about users in the underlying IdP and can quickly look up information such as user names and email addresses. If user information changes in the IdP, the SCIM app should update the cached user information in the environment's database.

When a user authenticates against the product front end (SmartForms Site in this example diagram), the product uses another microservice, called the Login service, to obtain consent for the user to log on using their credentials from the IdP, based on an OAuth2 OIDC implementation. Once the JSON Web Token (JWT) is retrieved from the IdP, the product uses the claim mappings and security label to compare the user information in the JWT token to the user data stored in the K2 Database, to validate that the user is indeed known by the system. (The user information should have been populated by the SCIM flow).

Note that the two paths must both work for the authentication to succeed. For example, even though a user may be able to authenticate successfully against the IdP through the OIDC path, if their user information is not stored in the environment's database via the SCIM path, they will not be able to use that environment. Likewise, even though user data may exist in the environment's database via the SCIM flow, the user still needs to successfully authenticate against the IdP before they will be able to use that environment.

Open ID Connect (OIDC) OAuth Flow

When a user authenticates against a secured interface in the product, it initiates an OAuth 2.0 consent flow to prompt the user to login and obtain an OAuth token. This token is then used as the authentication token for further interaction with the product.

Behind the scenes the product leverages IdentityServer4 (an OpenID Connect and OAuth 2.0 framework for ASP.NET) to implement the OIDC authentication and consent flow. The diagram below illustrates the flow when an OAuth token is obtained.

K2 OIDC Authentication and Consent Flow diagram