K2Trust (also known as trust.k2.com) is used by K2 to handle claims authentication and Single Sign-On (SSO) with Azure Active Directory (AAD). It is a Relying Party Security Token Service (RP-STS) used to broker authentication requests between K2 servers and AAD STS. The K2Trust URL is registered with Microsoft for use with K2 Apps.
For K2 to provide integration with an Office 365 tenant along with SSO, an AAD application would have to be installed in the tenant’s AAD instance by a Global Administrator. The permission for SSO is set in the application’s manifest as well as the allowed redirect URIs. Since each tenant’s K2 instance would have different URLs for the various sites like Designer, Runtime and View Flow, a single application could not be used unless K2 provided a redirector to manage it. Providing an RP-STS enables K2 to automatically handle the setup and configuration of the authentication and claims infrastructure.
OAuth 2.0 authorization needed the same mechanism for SharePoint applications. This used a slightly different flow but was essentially the same design as AAD in that only one redirect URI could be registered per tenancy.
K2 created K2Trust to handle multiple redirect URIs and to remove the requirement that you install an app directly in your AAD instance (which, in turn, requires an active AAD subscription, which some customers do not elect to purchase).
Over time, the role of K2Trust was expanded beyond a simple RP-STS into a robust and secure authentication and authorization redirector. All communication with K2Trust happens over an encrypted, SSL connection.
There are two servers that currently serve as K2Trust:
Depending on the Azure traffic manager, you may be directed to either one of these based on latency, load, and failover. Most likely you will be routed to the geographically closest server but that is not guaranteed. This means that if you are constraining your K2Trust calls based on the IP address, you must add both of these IPs to your configuration.
K2Trust is an RP-STS that currently supports WS-* (WS-Trust, WS-Federation) standards to issue SAML tokens issued by the IP-STS associated with the RP's realm.
To learn more about RP-STS and IP-STS, please refer to the MSDN article What is an IP-STS and what is a RP-STS
Any RP that uses the Windows Identity Framework (WIF) is able to use K2Trust as its STS and can be setup by consuming the federation metadata document located at the standard location on K2Trust:
WIF is used to generate the sign in and sign out message, depending on the request made, to the appropriate Identity Provider (IdP) STS in order to authenticate the user. The returned token is then issued and posted to the requesting RP.
For SSO with AAD, an AAD application must be installed into a tenant’s AAD environment and trusted for SSO. This application has an AppIdUri which is the value for the realm of the RP that performs the login to AAD.
The application also contains the redirect URIs to which the STS will return the request once authenticated. The request is not honored if the reply URL (wreply) parameter does not exist in the list of redirect URIs of the application.
K2Trust acts as the RP-STS as the authenticated result is posted to K2Trust, which then posts that result to the requesting RP. In order to secure this communication, K2Trust persists its own list of relying parties that are allowed to authenticate to it (and therefore AAD). K2Trust encrypts and persists information to the K2Trust database, including information such as the tenant realm, relying party URLs, and the K2 application. This ensures that the tenant can be validated. No user information or tokens are ever stored in the database. For K2 Cloud & Appit environments, the information is stored during the onboarding process. For K2 Five & K2 blackpearl environments integrated with SharePoint Online, the information is stored when the SharePoint App Registration Wizard executes.
The K2 Trust database is stored in SQL Azure and is only accessible from the K2Trust instance. The tenant admin's realm ID is retrieved from the authenticated SAML token and is unique per tenant. The realm ID is used as a link to secure this flow. This ensures that the instance of the K2 app only redirects to the tenant ID.
The relying party is added once a tenant admin consents to the K2 App. The authenticated result is returned to K2Trust, which at that point trusts that the incoming user is authenticated against a specific realm. This is true because it is using the TenantId claim value and knows the relying party URL is valid. These URLs are bound to the RealmID and only a user that is a member of the specific AAD instance can then continue with the login.
Let's take a look at the K2Trust Authentication flow:
If the K2 App has not been installed in the AAD tenancy, the WS-Fed signin fails as the application does not have the permission to perform SSO.
OpenID Connect is a different standard that combines some of WS-Fed and OAuth 2.0 in order to create a single authentication/authorization experience that allows a single request to retrieve an identity token as well as an OAuth 2.0 (authorization) token.
The K2 platform does not use OpenID Connect requests but rather standard WS-Fed sign in requests. K2Trust, based on the parameters in the request, retrieves the necessary information to build up an OpenID Connect request.
K2Trust then uses the AAD OpenID Connect flow to enable Common Consent (details of which are in Outbound Authorization an OAuth in K2). This allows you to give consent to a K2 App to allow SSO. The result is sent to the callback endpoint which then generates the appropriate SignInResponseMessage, which is then posted to the requesting client web app. K2Trust supports OpenID Connect but the K2-based web properties do not support it. Because of this, K2Trust uses JSON Web Token (JWT) classes to send back a WS-Fed token.
The end result is that the requesting web app uses the standard WS-Fed request but since K2Trust uses OpenID Connect, you are prompted for consent if the K2 App has not been installed in the AAD instance. Ultimately this results in the authentication loop completing successfully.
Let's take a look at the OpenID Connect flow:
The STS refers to the engine that validates and issues the claims token that will be consumed by a RP. This token is used to instantiate the ClaimsPrincipal which essentially authenticates the user with the web site (RP).
The K2Trust STS takes the ClaimsPrincipal received from the IdP-STS and generates a new ClaimsPrincipal. This is used to generate the SignInResponseMessage which is signed with the K2Trust certificate and issued to the RP.
The STS also contains the class that generates the FederationMetdata XML that can be consumed by any WS-Fed compliant RP.
The FederationMetdata XML is also used to update the thumbprint of an RP since the certificate used to sign a token can expire or be revoked. If it does expire or is revoked, the RP needs to be updated and the FederationMetadata XML allows this to happen automatically.
K2Trust supports OAuth 2.0 as an authorization standard. It acts like a redirector for the authorization flows.
K2Trust uses its list of relying parties, tenant realms and K2 client applications to validate the request from a specific K2 server to only allow matching requests to be completed.
As is the case with the AAD application, this requires a set of redirect URIs in order to perform SSO. OAuth requires a specific redirect URI to which it will issue the auth_code and oauth_token. This is done for security and is why K2Trust is required to be the broker between the real authorization server and the client. In order to ensure that K2Trust does not send the token to unsecured clients, it also keeps a list of relying parties to which it is allowed to issue the relevant auth_code and oauth_token.
When a request is made for an access token, K2Trust validates the client_id against the list of configured K2 application and, if a match is found, retrieves the K2 application details that it needs to perform the request, such as the AuthorizationEndpointUrl, TokenEndpointUrl, Client Secret, etc.
After it has been confirmed that the client has been configured for OAuth, it then initiates the correct authorization flow with the authorization server and completes the loop as necessary.
K2Trust does not support issuing Application Only (AppOnly, a Microsoft term) access tokens without an existing access token. The reason for this measure is that any user with the knowledge of another AAD tenant could potentially request an AppOnly token from K2Trust without being a user in that particular tenant as there is no prior request (auth code or refresh token) with which to validate the user. This means that you must first make an authorized request by adding a valid access token to the request for an AppOnly token. Note that an AppOnly token request must be made with a valid user token for that realm.
The secret key for all client applications that have been configured for K2 is only contained on K2Trust and only when a request has been validated will the client secret be used to retrieve the access token.
Let's take a look at what happens when requests are made to trust.k2.com, first by looking at the Authorization Flow and second by looking at the Authorization Flow.
A normal authorization flow when a user requests an authorization code (response_type=code)
When there is a valid client ID and redirect URI:
When there is an invalid client ID:
When there is an invalid redirect URI:
Use this access token flow diagram and explanation to discover how the authorization and authentication flow of a user requesting a K2 object, such as a form, SmartObject data, or a report, goes from the initial request, to the K2 site/server, through K2Trust (when the user is based in the cloud), and then to the auth services in AAD.
HTTP Status Code
An unhandled error has occurred.
Incoming request is not a valid WS-Federation request
Ensure that the request is a valid WS-Federation sign-in request or sign-in response and that it contains all of the required parameters.
An error occurred while processing a WS-Federation sign-in request
Details are in the message
An error occurred while processing a WS-Federation sign-in response
An error occurred while processing a WS-Federation Sign-out request
An error occurred while attempting to generate federation metadata
Requested relying party realm '' is unknown.
There was a mismatch between the AppliesTo given in the token request and the realms configured in K2Trust.
The version of OAuth used is not supported.
Ensure that the request is made for a supported OAuth version. Only OAuth 2.0 is supported.
An error occurred while processing an authorization request
An error occurred while processing an authorization response
An error occurred while processing a token request